Documentation changelog

2.0.0 current

2026-09-01

Rebuilt as a complete protocol documentation site. The previous version described the ordering experience only; this version specifies the protocol itself, including the reader rules that decide validity.

Added

• A normative specification with stable numbered rules covering the carrier and envelope, the strict payload grammar, identity and number rules, deploy, mint, transfer, ordering, invalidity conditions, reorganization, and conformance.
• The full mint anchor derivation as a seven step sequence, with the active-chain resolution, deploy bound, reveal bound, and freshness window stated as separate rules.
• A client-side mint anchor verifier that reproduces the payload grammar and the whole derivation in the browser, explains each step, and states plainly which input it cannot obtain without chain data.
• A test vector page with valid and invalid cases across grammar, anchor boundaries, supply, transfer settlement, within-block ordering, and reorganization.
• Indexer semantics in the reference: confirmation counting, finality depth, coverage reporting, mempool limitations, and reorganization handling.
• An implementation checklist, security considerations, and an explicit limitations list.
• The reader event lifecycle alongside the existing order lifecycle.
• Client-side search, a theme toggle, llms.txt, sitemap.xml, robots.txt, and a helpful 404 page.

Corrected

• The site previously described the mint hash only as a captured tip value. It is that, but the writer's choice is not what makes a mint valid. Validity is decided by the reader resolving the hash against the active chain and checking three distances. That distinction is now the centre of the documentation.
• Stated plainly that no Bitcoin Universe marketplace path exists for BLOCK-20. The capability registry records no marketplace entry for this protocol at all. Previous pages did not say this either way, which left room to assume a market existed.
• Replaced product-led framing with protocol facts. Support claims are now limited to surfaces recorded in the capability registry: discovery in Core, view, send, and receive in the Wallet, and deploy, mint, and transfer in Inscribe.
• Documented that the writer performs no token validation. It will inscribe a mint above the limit or for a ticker that does not exist, and the Bitcoin fees are spent regardless.
• Documented that ticker identity is case-insensitive and that the first valid deploy wins permanently.
• Documented zero decimals, the 2048 byte content ceiling, the 2¹²⁸ minus 1 amount ceiling, and the strict rejection of duplicate keys, non-string values, and trailing content.
• Documented partial final mints and that a mint after supply exhaustion produces no event rather than a failed one.
• Documented that burning reduces total and circulating supply but never reduces minted supply, so burnt capacity is not reopened.
• Documented that order expiry is monitor behavior rather than a hard gate, and that a late reveal can therefore still fail the freshness rule.

Compatibility impact

None to the wire format. Nothing in this version changes what a writer emits or what a reader accepts. It documents behavior that already existed.

1.0.0

Superseded

The first public BLOCK-20 site. It covered the ordering experience: choosing an action, reviewing the payload before payment, funding one dedicated output, following the order statuses, and the meaning of the fields in each payload. Its factual content about the order lifecycle, the payload field names, payment safety, and the origin of the mint hash is preserved in this version, on the lifecycle, guide, and mint anchor pages.

It did not state the reader rules, so it could not explain why a well formed mint might credit nothing.

Because emitted payloads carry no profile version, a change to field names, default values, serialization, the anchor rule, receiver behavior, or lifecycle semantics must update all of the following together:

1. the specification, keeping existing rule identifiers stable and adding new ones rather than renumbering;
2. every affected page and llms.txt;
3. the test vectors, including a vector for the changed behavior;
4. this changelog, with the compatibility impact stated explicitly;
5. docs.manifest.json, including lastVerified.