There is no BRC-20
Ethereum has a well-known token standard called ERC-20, and people arriving from that world assume there must be a BRC-20 to match. There is not, and this document exists to say so plainly and stop the confusion spreading further.
34 standards
An output is just coins until a protocol says otherwise. Standards here define those protocols: how a token is identified, how a transfer is recognised, and what a wallet has to check before it believes a balance.
Also searched as token protocol, token protocols, BSV-21, fungible token, Mandala Token, token exchange, non-fungible.
An output of a past transaction that has not yet been spent. A wallet's balance is the sum of the UTXOs it can unlock, and several standards here treat a UTXO as a token rather than as loose change.
Open in the glossary34 standards, spread across 7 of the 12 topics.
Wallets that handle plain bitcoin payments have no built-in idea of a custom token such as a loyalty point or a share. Without shared rules for finding, verifying, spending and tracking such tokens, every app would reinvent issuance, transfers and swaps from scratch, and wallets could not interoperate on the same asset. This lets a wallet manage fungible tokens with the same safety, automatic input selection, and consent prompts it already gives ordinary payments.
Filed under Wallet
Token rulebooks is the main subject of these 19.
Ethereum has a well-known token standard called ERC-20, and people arriving from that world assume there must be a BRC-20 to match. There is not, and this document exists to say so plainly and stop the confusion spreading further.
Building tokens on Bitcoin tempts people to copy account-based designs from other chains, which fits badly. This argues that an unspent output is already the natural unit of ownership and should be treated as the token itself.
Attaching data to an output normally makes it unspendable, so the data and the ownership cannot travel together. This describes a script that carries arbitrary data and leaves the output spendable, letting a token hold its own details.
Swapping a token for payment with a stranger requires one of you to go first, which neither party wants to do. This describes an exchange between two parties where neither has to trust the other to complete their side.
Token schemes tend to accumulate rules until they are hard to implement twice the same way. This keeps issuing, transferring, recovering and redeeming a token as small as it can reasonably be.
A minimal token protocol leaves amounts as plain numbers, which anyone in the chain could quietly alter. This adds a cryptographic commitment so tampering is detectable, without abandoning the minimal design.
Tokens that must respect real-world rules, such as who is allowed to hold them, have no way to carry that requirement. This attaches identity credentials so the rules travel with the token.
Checking whether a token is genuine usually means trusting an indexing service to have followed its history. This makes validity provable from block headers and proofs alone, so no service has to be trusted.
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.
Typing a name into a send box only works safely if that name provably belongs to one person and cannot be hijacked, forged, or silently reassigned by whoever runs the lookup service. Before this, uniqueness and identity for human-readable names depended on trusting a registrar or domain operator rather than on something a client could check for itself. This makes it possible to resolve a name to a payment-ready identity key and know the answer is correct without trusting whoever served it.
Selling something once on Bitcoin is easy, but selling it over and over from the same listing without the seller babysitting every sale is hard. Normally you would need the seller online to approve each purchase and each payout to collaborators, which breaks down once there are multiple recipients sharing revenue or the seller wants to walk away. This makes it possible to run a listing that buyers can purchase repeatedly, that pays out to a fixed set of recipients automatically, and that anyone can wind down or settle after a deadline even if the seller disappears.
Wallets that handle plain bitcoin payments have no built-in idea of a custom token such as a loyalty point or a share. Without shared rules for finding, verifying, spending and tracking such tokens, every app would reinvent issuance, transfers and swaps from scratch, and wallets could not interoperate on the same asset. This lets a wallet manage fungible tokens with the same safety, automatic input selection, and consent prompts it already gives ordinary payments.
Some apps want a wallet to track and move a named digital item, like a ticket or a badge, without the wallet pretending to guarantee how many exist, who issued them, or whether one is the "real" one. Before this, a wallet either had to apply full token rules it didn't need, or drop structure entirely and lose any way to recognize the item at all. This gives apps a lightweight way to say "sign this thing and identify it" without any false promises about scarcity or ownership history.
A wallet balance just shows a number. It does not tell you whether the asset behind that number can be frozen, blocked, or reversed by someone other than the person holding it. Developers end up guessing, or reading custom code, to find out whether a token truly belongs to its holder or is secretly on a leash held by its issuer. This gives a clear, checkable way to tell those two kinds of token apart just by looking at the script.
Some digital assets, like stablecoins, tickets or handles, only have value because an issuer stands behind them and can refuse a bad transfer or freeze a bad actor. Before this, that kind of control lived outside the transaction itself, in some separate system a wallet had to check, which made it unclear whether a payment was really final or could still be reversed later.
Right now, if you want to let someone sell a digital item or token from their wallet without being online when it sells, you either trust a central listing service to enforce the price and fee, or you risk a buyer taking the item for free by reusing a badly-signed listing. This describes a way to make an offer that can only ever be completed by paying exactly what the seller asked, with no index holding any keys and no way to skip the agreed fee.
Some token designs on Bitcoin require a recipient to check every past transfer back to the very first issuance of the token before trusting a payment, and each of those historical records repeats a long identifying code plus a full public key for every step. That repetition makes the proof a recipient has to check grow large and expensive with every hop, and makes combining several received amounts pull in even more history. A smaller way to write the same kind of token lets wallets and recipients do that same trustless checking with far less data moving around.
A token can change hands hundreds of times, and each new holder is expected to check the token's full history back to its creation to be sure it is real. For a long-lived token that check gets slower and more expensive every time it trades, to the point where a wallet on a laptop simply cannot do it fast enough. This makes it possible to hand a newcomer a single small proof instead of the whole history, while still letting them verify it themselves rather than trust whoever gave it to them.
These are about something else, and deal with token rulebooks on the way.
Attaching data to an unspendable output means the coins attached to it are gone for good, which some argue is the wrong way to think about Bitcoin. This offers a way to carry data on an output that can still be spent afterwards.
A payment protocol with no actual payment method defined does nothing. This adds a flexible mode to the direct payment protocol, covering ordinary Bitcoin as well as other kinds of token.
When a token carries compliance rules, two wallets checking it must reach the same answer or transfers will be accepted by one and refused by the other. This pins the check down step by step so the outcome is never in doubt.
Distributing a new token fairly means finding work worth doing rather than work that only burns electricity. This ties minting to proof that real indexing work was performed.
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.
Fungible tokens on BSV live as special one-satoshi outputs, but nothing told wallets where to keep them, how to tell them apart from ordinary payment coins or collectibles, or what information to pass along when sending them to another wallet. Without agreement, one wallet's token transfer could arrive at another wallet looking like junk, with no amount, symbol, or icon attached, and apps could not reliably list a user's token balances. This standard gives wallets a shared box and labeling convention so tokens move between them cleanly.
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.
Paying someone with a digital token normally means checking in with an online service at the exact moment of payment, which fails in a shop with bad signal, on a train, or at a market stall. Cash does not have this problem. This describes a way for a payment to be handed over and trusted on the spot, with the online check happening later instead of during the handoff.
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.
Letting people into a group chat or forum usually means keeping a list of names someone approved, and whoever approves them isn't the one who pays if a bad actor gets in or a good one gets shut out. Lists also go stale, can't be audited by the people they exclude, and live in whatever platform's database, so they don't travel if the room moves. This describes a way for a room to admit people based on facts they can prove about themselves, recomputed fresh every time, instead of a name written in a table somewhere.
A wallet can hold many different kinds of value, like Bitcoin, other coins, collectable items, and tokens, but there has been no shared rule for keeping them separate when an app asks to see or spend them. Without that, an app given permission to spend a small amount of Bitcoin could end up able to grab an item or token it was never meant to touch, and apps have no clean way to ask a wallet what kinds of value it even holds before trying.
Audio and video on chain is usually a single large file that cannot be edited, reused in part, or owned by more than one person. This describes it as a short timing document referencing separately owned pieces instead.
A creator's cut on resale only holds while the marketplace chooses to honour it. This builds the rule into the coin itself, so any transfer that skips the payment is rejected by the network rather than by a platform.
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.
Proving that a token transfer is legitimate normally means checking its entire history back to the moment the token was created, and that history gets longer every time the token changes hands. For a token that has traded thousands of times, a wallet would have to download and verify thousands of past transactions just to accept one payment. This makes long-lived, actively traded tokens slow and expensive to receive, no matter how simple the actual transfer is.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic