BRC-20 is a metaprotocol: rules for interpreting data stored in Bitcoin. Its basic deploy, mint and transfer operations create a token, issue its units and move them between holders. These are not additional BTC or a new part of Bitcoin consensus.
The author known as domo explored whether Ordinals could support fungible tokens: units of the same token that play the same role in its accounting. The original text describes an experiment and warns against treating it as a definitive solution. BRC-20 rules are an agreement among its participants, not a change to Bitcoin’s rules. [1]
An inscription is content placed in witness data when a Taproot output is spent. For BRC-20 it carries JSON, text with named fields such as p, op and tick. A Bitcoin node validates the Bitcoin transaction but does not execute that text as token accounting. An indexer interprets its meaning. [5]
The first valid deploy claims a ticker, the token’s identifier, without distinguishing upper and lower case. It sets the supply max and optionally the issuance limit lim and precision dec. The basic rules allow at most 18 decimal places. Alongside the original 4-byte tickers, IP1 introduced 5-byte tickers associated with self_mint. These lengths count UTF-8 bytes, not letters; the variants are not freely interchangeable. [2] [3] [6]
The owner first creates a transfer inscription specifying amt. This reserves the amount from the available balance without yet changing the overall balance. Only the inscription’s first movement transfers units to a recipient. Moving it back to oneself releases the reservation. A transfer inscription works only once; selling the same record again does not transfer those tokens again. [1] [3]
Indexers must interpret event order, limits and the first transfer identically. They track the balance owner by scriptPubKey, the output’s locking script, rather than just its displayed address. A reorganization can change event order and the resulting ledger. Confirmation of a Bitcoin transaction therefore does not, by itself, prove its BRC-20 operation was valid. [3]
The basic rules accept the content type text/plain or application/json and valid JSON. Required fields and operation names use lower case; required values, including numbers, are quoted strings. The dec field limits decimal places and uint64_max bounds the numeric range. An unquoted number or an extra comma can invalidate an operation even if a person can read it easily. [3]
If a service first creates a mint at its own address, it may receive the token balance. Later handing over the mint inscription itself does not transfer that balance. Accidentally spending the relevant UTXO can also have an unexpected result. Sending an inscription as a mining fee and destroying tokens have their own rules; an ordinary BTC transfer is not a universal guide to BRC-20. [1] [6]
Check the first valid deploy, max, lim, dec and any self_mint setting, then follow events in block and transaction order. OPI lets users compare hashes of each block’s events and a cumulative hash for the history. The rule version must match: newer programmable modules extend the original model. This entry explains that foundation, not every extension. [4]
For the clearest picture, read this entry together with Ordinals Inscriptions, Runes, UTXO, Taproot, Bitcoin Script, Fee Rate.
01Do Bitcoin Full Nodes validate BRC-20?+
They validate Bitcoin transactions and their scripts, but do not calculate BRC-20 token balances. An indexer reconstructs those under the metaprotocol’s rules. A Bitcoin node alone is therefore insufficient to verify the token ledger.
02Is BRC-20 the same as Runes?+
No. Basic BRC-20 uses text Ordinals Inscriptions and a two-step transfer. Runes records binary runestone messages in an OP_RETURN output and assigns tokens to UTXOs differently. The two systems’ rules cannot be interchanged.