BRC-20 Tokens Explained: Verify the Inscription and the Indexed Balance
BRC-20 began as a way to represent fungible token balances using inscriptions on Bitcoin. The original model records operations that indexers interpret to calculate who holds a token. A confirmed Bitcoin transaction and a valid BRC-20 balance are therefore different facts. This lesson explains the classic inscription workflow and how to check it. The ecosystem has also added extensions, including programmable functionality, so an old tutorial is not a complete description of every current implementation.
Your task: inspect a token’s deployment, rules and indexed transfer state without minting or buying anything. Separate the Bitcoin transaction evidence from the token ledger and the wallet interface.
Three layers behind a BRC-20 balance
Bitcoin transactions and inscriptions
Bitcoin provides the underlying transaction record. Ordinals-aware software tracks inscribed satoshis and their movement. A wallet must handle those inscriptions deliberately; an ordinary Bitcoin balance display is not enough to explain the token you think you own. The Ordinal Theory Handbook distinguishes the node’s chain view from wallet tools that perform sat control when constructing transfers.
The token protocol and its rules
In the classic model, deployment defines a token, valid mints credit balances, and a transfer uses an inscription followed by its first qualifying movement. Sending an old mint inscription does not transfer the balance minted from it. A reused transfer inscription is not a reusable payment voucher. Rules about limits, ordering and available balance determine which operations count, beyond whether their Bitcoin transaction is confirmed.
Indexers, versions and extensions
An indexer replays relevant events and exposes the resulting token ledger. Open Protocol Indexer documents event histories, reorganization handling and comparisons between indexed states, as well as programmable BRC-20 extensions. Check the implementation and rules accepted by the wallet or marketplace you intend to use. A service lagging behind the chain or applying different rules can display a different result; a ticker alone does not resolve that disagreement.
Inspect a token record without making a transaction
Identify the deployment and network
Start from a verified project source and record the Bitcoin network, ticker, deployment inscription identifier, maximum supply and mint conditions. Match these to the indexer’s deployment record. Do not confuse a similarly named ERC-20 token or a wrapped version on another chain with the Bitcoin inscription asset. A deployment establishes protocol parameters, not a guarantee of the issuer’s identity or market value.
Check both chain status and token status
Open the relevant Bitcoin transaction to inspect confirmation and then examine the BRC-20 operation in a compatible indexer. Record the indexer’s processed height, operation result and the address credited. If a service first inscribes to its own address, its handling of the subsequent delivery matters. Do not assume a transaction marked confirmed proves that your wallet received a valid mint or a transferable balance.
Read the transfer state before trusting the display
Distinguish total, available and already prepared transfer amounts. Check the recipient, token quantity, inscription identifier and the network fee in BTC as separate fields. Use a wallet that explicitly supports the relevant inscription protocol and protects the outputs it tracks. Keep recovery material private. For this learning exercise, inspect a documented example rather than signing a transaction or connecting to an unfamiliar minting site.
Worked example: total balance is not all available twice
Suppose a fictional token ledger shows 800 units in total and you prepare a valid transfer inscription for 250 units. Under the classic balance model, 550 remain available and 250 are assigned to that prepared transfer; the recipient has not yet received them. A new attempt to prepare 600 units would exceed the 550 available, even though the total still displays 800. When the first transfer is completed correctly, the recipient’s credited balance changes according to the protocol. These numbers are an example, not a live token offer.
Mistakes that confuse the record with the asset
Treating confirmation as successful token issuance
Bitcoin can confirm a transaction containing an operation that does not create a valid token balance under the relevant protocol. Check the operation result, supply and mint conditions rather than only the transaction badge. Paying a network fee does not guarantee issuance, a listing, resale demand or a refund if the operation fails the token rules.
Using an ordinary send flow for inscription outputs
Bitcoin uses spendable outputs, and inscription-aware handling matters when choosing which ones a transaction spends. A wallet that shows a BTC total may not protect or explain the inscriptions attached to those outputs. Do not experiment with consolidation or automated sends using assets you have not identified. Check the wallet’s current documentation and its explicit support for the operation first.
Repeating a 2023 description as a complete 2026 specification
The original BRC-20 document describes an experiment. Later rule changes and programmable extensions mean that claims such as every token always has a four-character ticker or the ecosystem can only ever perform three operations are too broad. State which workflow you are using and verify the current rules at the relevant block height. A new extension also does not make every old wallet compatible.
Try it: does the confirmed mint prove a balance?
A fictional public-mint token has already reached its supply cap. A later mint inscription is included in a confirmed Bitcoin transaction, and a website says confirmation guarantees that you received 100 tokens. Is the transaction badge sufficient evidence?
Reveal the explanation
No. Confirmation proves inclusion in the Bitcoin transaction history, not acceptance of the mint under BRC-20 rules. Inspect the deployment, event ordering, supply state and the compatible indexer’s result. An operation after supply is exhausted cannot establish the claimed new balance in this scenario. Do not pay another fee merely because a website promises it will repair an invalid mint.
