Beered by 1 person
13 standards · 5 topics
When an app asks a wallet to build a transaction, the wallet hands back a temporary token needed to finish or cancel that transaction later. If the app crashes, loses memory, or the signing process gets interrupted before that token is used, there was previously no standard way to get it back, leaving the transaction stuck half-finished with no way to complete or cancel it.
Wallet apps often need to find one specific coin they are holding again later, for example after a restart, or to spend exactly that one and not another, but the usual way to look through a wallet's holdings means scanning everything and hoping the details still match. There was no agreed, simple way to give a single held item a durable nickname that a lookup could search for directly.
Sometimes you need to prove something about one specific piece of a transaction, like a single stamped token, rather than the whole transaction. Existing proof formats bundle everything needed to trust a transaction, but they assume the thing you care about is the transaction itself, not one output buried inside it. Without a way to say "prove this particular output," you either send far more data than needed or leave out the odd extra transactions a token proof actually depends on.
Some BSV transaction bundles need to say 'here is everything about this one transaction' without being limited to only its ancestor history. Before this, a format that pinned down a single subject transaction, Atomic BEEF, forced the bundle to contain only ancestors and nothing else, which breaks when a protocol needs sibling or related transactions included too. Without a way to say 'this bag is about transaction X, and it can contain whatever a given use case requires,' a developer had no clean way to hand over a flexible, well-identified bundle.
A single satoshi, the smallest unit of bitcoin, can be moved around like any other coin, but there was no agreed way to treat one specific satoshi as a unique, trackable item that keeps its identity as it passes from wallet to wallet. Without that, you cannot build things like collectibles or one-of-a-kind tokens directly on bitcoin transactions, because every coin looks fungible and interchangeable. This gives that single satoshi a permanent name and a way to prove where it has been, so it can act like a non-fungible token.
A tiny on-chain token can prove it is unique and traceable, but on its own it carries no real content, it cannot hold a picture, a document, or app data. Developers needed a standard way to attach that content directly to the token so wallets and apps can find and display it without inventing their own format.
Issuing a fungible token, like a points balance or stablecoin unit, on Bitcoin used to mean inventing your own tracking scheme or relying on a global name registry that anyone could squat or collide with. There was no agreed way to say "this balance belongs to this token, forever" without a central ledger, and no standard way for an issuer to mint more supply later without rewriting the rules each time. This standard fixes the token's identity to the transaction output that created it and lets ordinary wallet transactions carry and mint balances.
Different fungible token systems on Bitcoin SV have each invented their own way of writing an amount and a token identifier onto a transaction output, so wallets and contracts have had to support multiple incompatible formats just to move the same kind of balance. That means extra parsing code, extra bugs, and scripts that cannot easily inspect a token output the way they can a plain payment. A shared, script-readable layout means any wallet or contract can check and build these outputs the same way, every time.
Apps that want to show or move collectable items (like NFTs) in a wallet face a bad choice: either dump everything into one basket where any app that gets access sees the user's whole collection, or invent a separate storage bucket for every collection, creator, or app. There was also no clean way to ask a wallet "let me spend this one specific item" without accidentally granting access to spend anything in the collectables basket. This leaves users exposing more than intended, or developers building fragile one-off storage schemes.
When someone sends you a token on Bitcoin, you cannot just trust the number they tell you: you need to check it came from a real issuance and was never double-counted through splits or merges, without running a full blockchain indexer. Existing proof formats either strip out the very transaction history token math depends on, or only work for simple single-path assets, leaving no safe way to check a token tip you just received while offline.
If you know a domain runs some kind of overlay service, there was no standard place to find out where to actually send requests for it. You'd end up guessing at conventions like an api. subdomain, or asking around, with no way to be sure you weren't just hitting the wrong host. This gives a domain one clear file where it states, service by service, which URL to use.
If your app sends messages between users and those messages contain binary data, like signatures or encrypted blobs, encoding everything as JSON text makes the payload bigger than it needs to be, and that waste gets worse the more binary content you pack in. This matters once you care about bandwidth or are sending a lot of small messages. It makes it possible to send and receive the exact same messages more compactly.
Sending someone bitcoin, a token, or a digital asset usually means they have to be online and ask for it first, or you need some separate side channel to tell them a payment is coming and how to claim it. This makes it hard to just drop an asset into someone's account the way you'd send an email, especially when the asset involves extra rules about colors, authority, or expiry that both sides need to agree on and check independently.
Search standards by number, title, author or topic