BLOCK-20 reference

1. Terminology

2. Indexer semantics

2.1 Confirmation

• An event's confirmation count is tip height - block height + 1. An event in the tip block has one confirmation.
• A confirmed event carries complete block placement: height, block hash, transaction index, and event index. A reader that cannot supply all four must not mark the event confirmed.
• The finalized height is tip height - finality depth, with a default depth of 6. It never moves backward.
• Coverage is reported as complete only while the reader has processed through the current tip. While catching up it reports partial, and consumers should treat balances as provisional.

2.2 Mempool and pending events

The event model has a pending confirmation state for unconfirmed activity. A pending event carries no block height, no block hash, no transaction index, no event index, and zero confirmations, and it may never transition back to pending once confirmed.

A mint has an additional reason to distrust the mempool: the anchor rule compares the anchor height against the reveal height. Until the reveal is mined, the reveal height does not exist, so the freshness check cannot be evaluated at all.

2.3 Reorganization

• The reader compares the block at its checkpoint height against the node. A hash mismatch starts reconciliation.
• The scan depth for a recoverable fork defaults to 144 blocks.
• Events are invalidated newest first, by descending height, transaction index, then event index.
• Invalidation reverses the exact recorded wallet and supply deltas of each event, restores reservations that were settled on the replaced branch, and removes reservations created on it.
• Invalidating a deploy deactivates the ticker. Leaving an applied mint or transfer attached to an inactive deployment is a fatal condition.
• An event at or below the finalized height cannot be invalidated. The reader stops rather than produce a state it cannot justify.
• Because anchors are resolved against the active chain during replay, a mint whose anchor block was orphaned does not survive the replay even though its bytes are unchanged.

3. State model

A reader tracks four supply figures per ticker plus per-holder balances.

Invariants a reader must maintain: total = minted - burned, circulating = total, and minted <= max. Minted supply never decreases, so burning does not reopen minting capacity.

4. Fees and size

• Payload sizes are small. A transfer is 57 bytes, a deploy 73 bytes, a deploy with a 26 character description 108 bytes, and a mint 128 bytes because of the 64 character anchor hash. The hard ceiling on inscription content is 2048 bytes.
• A mint is always the largest of the three operations. The anchor costs roughly 70 bytes of witness data on every mint, which is the price of the proof.
• Publishing an inscription takes two transactions: a commit that funds a dedicated address, and a reveal that spends it and exposes the inscription. Both pay fees.
• A transfer costs two inscriptions worth of activity in practice: the transfer inscription itself, then a further transaction to move it. Budget for both before starting.
• The Bitcoin Universe writer computes the required commit amount from the estimated reveal fee, the inscription output value, and a fixed service fee of 1500 satoshis.
• The writer accepts exactly one eligible output at the commit address, prefers a confirmed one, and chooses the largest eligible output. It does not aggregate several smaller payments.
• The selected commit output is spent in full by the reveal. After fees, residual value is sent to the configured receiver, so overfunding is not lost but does change the economics of that single reveal.
• Inscription output values below 330 satoshis are treated as zero by the writer. A typical value is 546 satoshis.

5. Trading and market access

This documentation makes no claim about third-party venues. If you are told a BLOCK-20 market exists somewhere, verify independently which reader profile that venue applies, because a venue that skips the anchor check will value balances this profile does not recognize.

6. Limitations

1. No version field. A payload carries no profile version, so any change to field names, defaults, serialization, or the anchor rule is compatibility sensitive by construction.
2. The freshness window is a reader setting. The default is 144 blocks but any value from 1 to 10000 is configurable. Two readers can legitimately disagree about a mint near the boundary.
3. The writer validates nothing about tokens. It will inscribe a mint above the limit, a mint for a ticker that does not exist, or a deploy of a taken ticker. Bitcoin fees are spent either way.
4. Anchor validity depends on chain history. The same inscription bytes can be valid on one chain history and invalid after a reorganization that orphans the anchor block.
5. No pending view. Coverage is partial. Unconfirmed BLOCK-20 activity is not reliably represented, and a mint cannot even be evaluated before its reveal is mined.
6. Transfers need two transactions. There is no single-transaction send.
7. Burning does not free supply. Minted supply never decreases, so a burnt token is gone and its mint capacity is not returned.
8. Zero decimals. There is no subdivision. A ticker that needs fractional units cannot express them.
9. Five character tickers, ASCII only. No Unicode, which removes confusable-character attacks but also removes expressiveness.
10. Order expiry is monitor behavior, not a gate. A qualifying payment found after the window can still be revealed, which means a late reveal can still fail the freshness rule.
11. Repeat count is not multi-mint. In a direct order it multiplies the funding amount without creating multiple inscriptions. It must not be presented to users as a bulk mint feature.
12. No marketplace. See section 5.

7. Security considerations

1. Reject an empty receiver address. A writer that falls back to its own server-generated commit address when the receiver is empty will deliver the inscription to key material you do not control. A client must require a valid user-controlled address before creating an order.
2. Server-held reveal keys. A hosted writer holds the key that signs the reveal. Between commit funding and reveal, the service can complete or fail the operation. Prefer short windows and verify the reveal destination afterward.
3. Ticker squatting is permanent. First valid deploy wins, identity is case-insensitive, and metadata is immutable. There is no dispute mechanism in the protocol.
4. Do not trust a reader that skips the anchor check. Balances computed without rules R6.5 through R6.8 will be higher than this profile's, and the difference is exactly the set of mints this profile rejects.
5. Wait for finality before treating a mint as settled. Reorganizations reverse events above the finalized height, and an orphaned anchor invalidates a mint that previously looked valid.
6. Strict parsing is a security property. Duplicate keys, non-string values, and trailing content are rejected rather than recovered, so two conforming readers cannot be made to disagree by a crafted payload. A reader that adds lenient recovery reintroduces that attack.
7. Payload content is untrusted text. A description can contain any printable UTF-8 up to 256 bytes. Escape it before rendering, and never treat it as markup or as an instruction.
8. Fail closed on source disagreement. A reader that cannot obtain a contiguous block range, that sees a network mismatch, or that would have to invalidate a finalized event must stop rather than guess.
9. Do not pay an order twice. A slow status is not a request for a second payment. Preserve the order record and the wallet transaction ID instead.
10. Report vulnerabilities privately through this repository's security policy. Do not open a public issue for a security defect.

8. Implementation checklist

For anyone writing a BLOCK-20 reader that claims the bitcoin-universe-block20-v1 profile.

Verify the result against the test vectors, including every boundary case in the anchor derivation.