Mandala Token Protocol (Withdrawn)
Token schemes tend to accumulate rules until they are hard to implement twice the same way. This keeps issuing, transferring, recovering and redeeming a token as small as it can reasonably be.
About Token rulebooks, the rules for treating an output as a thing somebody owns.
Reference for an AI
Everything an assistant needs to answer questions about BRC-92 accurately, including what it depends on.
Summary
- Why
- Token issuers needed a minimal way to tag an output as belonging to a specific asset with a specific amount, distinct from ordinary coins.
- What
- BRC-92 was a withdrawn minimalist token protocol that prefixed outputs with a marker byte, an asset id tied to a genesis outpoint, and an amount, ahead of an arbitrary locking script.
- How
- An output began with the push 0x21 ("!"), then a genesis-outpoint-derived asset id and an amount, all dropped from the stack before the real locking script ran, with issuance and redemption tracked through a chain of issuer-authorized outpoints.
What this lets you do
- Recognize legacy BRC-92 outputs by their leading 0x21 marker byte
- Understand why BRC-92 outputs are not valid BRC-162 (1Color) tokens
- Trace how BRC-92's push-and-drop prefix carried forward into BRC-162
- Know to issue new fungible tokens under BRC-162 instead
- Look up BRC-107 to see what built on BRC-92's original format
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
The specification
Withdrawal notice
This standard has been withdrawn and its normative content removed. It defined a minimalist token protocol: outputs prefixed with ! (0x21), followed by a genesis-outpoint assetId and an amount, all dropped before an arbitrary locking script. Issuance, redemption and recovery were managed through a chain of issuer-authorized outpoints.
The author withdrew it in favor of a single fungible token specification. Its binary successor is 1Color (BRC-162), which keeps this protocol's push-and-drop prefix and uses the BSV-21 token model. New fungible tokens SHOULD be issued under BRC-162.
The formats are not compatible on-chain. A BRC-92 output's first push is the 1-byte ! marker, which is not a valid BRC-162 token id, so BRC-92 outputs are not BRC-162 outputs. The NFT and BoundKey constructions described here are not carried forward.
BRC-107 and the documents that extend it build on the format defined here. The last version of this document with its full content is available in the repository history.