ZRC-20, and its two readings
You will get from this page: what ZRC-20 is, why two honest explorers can print different numbers for the same token, and how this product handles that without picking a winner.
Plain language
Section titled “Plain language”ZRC-20 is the token standard carried inside legacy Zerdinals inscriptions. A token is deployed, minted, and moved by writing small JSON documents into Zcash transactions. Nothing about it is a separate chain, a bridge, or a wrapper: every balance is reconstructable from Zcash blocks alone.
Open Tokens in the product’s navigation to browse every deployed ticker, or search a ticker in ZordiScan.
What a token page shows you
Section titled “What a token page shows you”- Max supply and per-mint limit, as the deploy declared them.
- Minted, as an exact percentage of the whole supply.
- Circulating, burned, and shielded, kept apart rather than summed.
- Holders, and the balance each one holds.
- Origin: the deploy transaction, the deploy inscription, the block, and the deployer address.
- Activity: mints, transfers, burns, and the operations that did not count.
Why some figures come with a second opinion
Section titled “Why some figures come with a second opinion”Two independent readers project ZRC-20 from the same Zcash blocks, and they do not always agree. Where they differ, one will tell you a token has 435 holders and the other will tell you it has 408. Both are reading the same chain. They disagree about the rules, not about the blocks.
ZRC-20 was defined by its implementations rather than by a specification, and the implementations differ in two places that can be settled from a transaction:
| Reading | Ticker rule | Mint amount rule |
|---|---|---|
| zord | lowercased, 4 to 5 bytes | a mint may claim up to the per-mint limit |
| zecscriptions | lowercased, any length | a mint must claim exactly the limit |
That is enough to change real numbers. A partial mint counts under one reading and not under the other, so supply, holders, and mint progress can all move. A ticker longer than five bytes exists under one reading and does not exist at all under the other.
Most explorers pick one reader and print its number without saying so. This one prints both. Every figure names the reading it came from; every row in the token list says whether the two readings agree about that token; and on a token’s page a table shows both readings side by side with the differing rows marked. You can switch the active reading at the top of the Tokens page and on any token page, and what you see changes with it.
Differences nobody here has decided
Section titled “Differences nobody here has decided”Some documented differences cannot be settled without inventing a fact, so they are not applied at all. They are listed on each token page with the reason. Two of them:
- One reader’s version 2 protocol requires a mint to pay three specific outputs. No activation height for that version is on record, so applying the rule would mean guessing when it started. Neither reading applies it.
- A transfer settled into the shielded pool is a permanent burn in one accounting. Rather than choosing, shielded amounts are counted in their own column beside burned, so either accounting can be worked out exactly from what is shown.
Operations that did not count
Section titled “Operations that did not count”Not every ZRC-20 document in a block does something. A mint after the supply ran out, a transfer larger than the balance behind it, a second deploy of a ticker that already exists: these are written to the chain, and they change nothing.
Most explorers simply omit them, which leaves you with a transaction that appears to have vanished. Turn on Include operations that did not count in a token’s activity, and each one says plainly why it did not: the whole supply had already been minted, the holder did not have enough available balance, the ticker was already deployed.
Available and committed balances
Section titled “Available and committed balances”A transfer happens in two steps. First you inscribe the transfer, which sets the amount aside. Then you spend that inscription’s output, which delivers it. Between the two steps the amount is committed: still yours, but not available to move again. A holder’s balance is shown split, so an attempted transfer that fails for insufficient balance has a visible explanation.
Reading numbers while the chain is being read
Section titled “Reading numbers while the chain is being read”The explorer only knows about blocks it has read. Whenever the scan is incomplete, an empty result says so rather than reporting nothing found, and the figures shown are the figures from the blocks read so far. An absence is never presented as proof that something does not exist. What an empty result means.