Beered by 1 person
9 standards · 3 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.
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 token that behaves like money on Bitcoin used to mean either racing to grab a unique ticker name or building a custom system for tracking who owns how much. There was no simple, shared way to say "this transaction output holds 500 units of token X" that wallets and marketplaces could all read the same way, and no clean way to let an issuer keep minting more supply later without breaking that shared format.
Fungible tokens on Bitcoin SV have needed either a global ticker (which causes naming collisions) or a JSON inscription that scripts can't easily read or build. Without a way to encode token identity and balance directly in script, wallets and covenants can't compose token logic with ordinary spend conditions like multisig or P2PKH. This makes it possible to carry a token balance in a UTXO using plain script pushes, so contracts can check and build token outputs without parsing any inscription format.
Apps that manage digital collectables inside a wallet need to show a user's items and occasionally spend one of them, but a wallet basket only offers all-or-nothing access: either an app sees everything in a person's collection or nothing at all. That is either too invasive for an app that only cares about one collection, or too weak to let an app safely ask to move a single specific item without also getting blanket spending rights over the whole stash.
Someone hands you a token payment, maybe several outputs from one transaction, and you need to be sure it's genuinely the token it claims to be, for the right amount, without querying a central index you have to trust. Because these tokens can be split and merged from many parent transactions, the history behind a single payment can branch in ways a simple chain of receipts can't capture. Without a defined way to package and check that branching history, a receiver either trusts a claim blindly or has no practical way to verify it offline.
Search standards by number, title, author or topic