BSV-21 Fungible Tokens (Binary)

Abstract

BSV-21 (binary) is a fungible token protocol for Bitcoin SV. Balances live in UTXOs. Each token is identified by the outpoint of its deploy output. Token data is a fixed script prefix of data pushes — readable and constructible in Bitcoin script without parsing JSON.

Two supply models:

1. Fixed supply — the entire supply is created in one deploy output.
2. Authority — deploy creates minting authority; later authority spends mint new supply.

This document is the binary encoding of BSV-21. The JSON inscription encoding of the same protocol is BRC-161. Token id, supply models, and balance/authority economics are the same; only the on-output encoding differs.

Motivation

Issuers need fungible tokens that:

• have a stable id that is not a global ticker race,
• move as UTXOs (split, merge, parallel spends), and
• support both fixed supply and issuer-controlled minting.

BSV-21 identifies each token by its deploy outpoint and carries balances on outputs. The token fields are a prefix on the locking script: they do not replace the spend condition. Any script can follow — P2PKH, multisig, covenants, marketplace templates, and other contract locks — so token value and Bitcoin script stay composable. Indexers enforce per-token supply and authority rules; consensus does not run a separate token VM.

This document defines a binary prefix: tag, token id, amount, and optional payload as fixed pushes (amount as a script number; id as a 36-byte outpoint in sighash preimage order). Wallets and contracts can build and check token outputs in script without assembling an inscription or parsing JSON.

Relationship to other documents

This BRC does not define marketplace locks, overlay topic naming, or BRC-100 basket profiles.

Specification

Wire format

Every token output begins with:

<push "BSV21"> <push token id | OP_0> OP_2DROP <push amount | OP_0> <push payload | OP_0> OP_2DROP <rest of script>

Rules:

• All four pushes are always present; empty values use OP_0.
• The prefix pushes four values and drops all four, so the remainder of the script runs as if alone.
• A script is a BSV-21 binary token output when the prefix matches this layout (including a valid payload push — OP_0 or CBOR map). Tag, id, and amount define the role; map contents do not affect balance or authority admission.
• The tag push is the only protocol marker.
• A decoder consumes the prefix; everything after it is ordinary locking-script content for whatever spend path the output uses.

Token identification

• A token id is the outpoint of the deploy output that created the token.
• On the wire it is 36 bytes: txid in natural/internal byte order ‖ uint32 little-endian vout — the same layout as outpoints in sighash preimages.
• Deploy leaves the id field empty (OP_0); that output's own outpoint is the token id.
• Every later output for the token carries the 36-byte id.
• The token id is fixed for the life of the token.
• For display and APIs, the string form is <txid>_<vout> (64 hex chars in display txid byte order, underscore separator) — the same form used by the JSON encoding (BRC-161); this id form is fixed for BSV-21 and is not the general dual-form outpoint convention in BRC-159, so a token presents identically under either encoding. Converting between 36-byte form and that string reverses the 32 txid bytes only.

UTXO model

Balances are carried on transaction outputs. Spending valid value or authority inputs and creating valid value or authority outputs is how supply moves, splits, merges, mints, or burns. Any Bitcoin locking script MAY lock a token output (P2PKH, multisig, covenant, marketplace template, …).

Roles

Each output's role is determined only by whether the token id is present and by the amount:

Amounts

• Bitcoin script numbers: minimally encoded, non-negative, little-endian.
• Domain: 0 … 2^64 - 1. The maximum encodes in nine bytes (eight value bytes + high zero sign byte).
• Amounts above the maximum, negative values, or non-minimal encodings are invalid.
• Amount zero marks authority, not value.

Payload

• The fourth push MUST be either OP_0 (empty) or a CBOR map (RFC 8949).
• Encoders SHOULD use deterministic CBOR (RFC 8949 §4.2) when writing a map.
• A non-empty push that is not a CBOR map is not a valid BSV-21 binary token output.
• Map contents do not affect balance or authority admission. Defined deploy display keys are specified below; unknown keys are ignored.

Deploy display fields

Optional metadata on the deploy output only. Later outputs normally use OP_0 and inherit display data from deploy. Missing or malformed display fields do not invalidate the deploy. These keys have no protocol meaning on non-deploy outputs. Additional keys MAY be defined later.

Symbol (sym)

Icon (icon)

Indexers expand a 4-byte value by prepending the deploy output's txid, yielding a normal 36-byte outpoint. Any other length is treated as absent.

The referenced outpoint SHOULD hold image (or other display) bytes — commonly a B protocol file (B protocol (19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut)) or an ordinal inscription. icon is a pointer only — not embedded image data and not a URL. Wallets resolve the outpoint to fetch content. Unresolvable icons do not affect token validity.

Decimals (dec)

Supply models

Fixed supply

Deploy with empty id and amount > 0. That amount is the entire initial supply held in the deploy output. No authority is created unless a separate authority deploy is used (a token has one deploy outpoint).

Authority supply

Deploy with empty id and amount 0. That output is the first authority. Later spends of authority may create value outputs (mint) and/or further authority outputs.

Deploy under a contract

The deploy output may be locked with a covenant (or other contract) in the same transaction that creates the token.

In the fixed-supply model, the whole initial supply is born under the contract’s spend rules. In the authority model, minting capability is born the same way. Later holders still receive ordinary value outputs; what the contract enforces is whatever it locks (deploy, authority, or both).

Authority operations

Authority outputs (id present, amount 0) may be:

• Split — one authority in → many authority out
• Combine — many in → one out
• Transfer — re-lock to a new script
• End — spend without a replacement authority out (that authority is destroyed)

Minting for the token ends only when no authority outputs remain.

Value operations

Value outputs (id present, amount > 0) move existing supply or, when an authority input is present, create new supply (mint). Split and merge are ordinary multi-input / multi-output spends under the balance rules below.

Validation rules

Validation is per token id within a transaction. Indexers admit or reject outputs; consensus miners do not enforce these rules.

Deploy (empty id):

• Always valid as genesis (no token-input check).
• Token id := this output's outpoint.

Authority (id present, amount 0):

• Valid only when the transaction spends a valid authority of the same token.
• Deploy with amount 0 is the token's first authority.
• Authority inputs contribute 0 to token balance.

Value (id present, amount > 0):

• If the transaction spends a valid authority for the token: value outputs are valid without input balance coverage (mint).
• Otherwise: let I = sum of amounts on valid value inputs of this token; let O = sum of amounts on value outputs of this token.
  • Admit value outputs only when I >= O (all value outs for the token, or none — all-or-nothing).
  • If O > I: value outputs are invalid; input tokens are burned.
  • If I > O: the difference is burned (implicit burn).

Circulating supply is the sum of admitted unspent value UTXOs.

Display metadata:

• sym, icon, and dec are set at deploy only.
• Invalid or unresolvable icon does not affect balance or authority admission.

Locking scripts

Any valid locking script is allowed after the prefix. This protocol does not constrain spend conditions beyond the prefix fields and the validation rules above.

Satoshi value (convention)

By convention, token outputs often hold 1 satoshi. That is ecosystem practice for indexing and wallet UX, not a protocol rule. Validators MAY apply a 1-sat policy when admitting outputs.

Examples

Output scripts

Fixed supply deploy (P2PKH), metadata in CBOR payload:

"BSV21" OP_0 OP_2DROP 21000000 <CBOR {"sym":"GOLD","dec":8}> OP_2DROP
OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG

Authority deploy:

"BSV21" OP_0 OP_2DROP OP_0 <CBOR {"sym":"STABLE","dec":2}> OP_2DROP
OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG

Value output:

"BSV21" <36-byte token id> OP_2DROP 5000 OP_0 OP_2DROP <locking script>

Authority output:

"BSV21" <36-byte token id> OP_2DROP OP_0 OP_0 OP_2DROP <locking script>

Fixed supply lifecycle

1. Deploy — empty id, amount 10 000 → token id = this outpoint.
2. Split — spend deploy; two value outs of 5 000.
3. Pay — spend one 5 000; value 4 900 to recipient + 100 change.

Authority lifecycle

1. Deploy — empty id, amount 0 (genesis authority).
2. Mint — spend authority; value 1 000 000 + authority (continue).
3. Distribute — split the value output.
4. Delegate — spend authority → two authority outs (admin A, admin B).
5. End authority — spend an authority with no authority out. Minting stops only when the last authority is ended.

Balance checks

Valid transfer:

In:  1_000 + 500 value
Out: 800 + 600 + 100 value

Invalid (no authority; outs rejected; inputs burned):

In:  500
Out: 300 + 400

Implicit burn:

In:  1_000
Out: 250
→ 750 burned

Mint (authority present; value need not be covered by value inputs):

In:  authority
Out: value 1_000_000 + authority

Security considerations

• Indexer trust — validity is not miner-enforced; wallets rely on overlays / indexers that implement these rules.
• Symbol collision — sym is not unique; always key tokens by deploy outpoint id.
• Auth compromise — holder of an authority UTXO can mint unbounded supply until that authority is ended.
• Over-output burn — creating value outputs that exceed inputs (without authority) burns the inputs.
• Display spoofing — sym / icon are unauthenticated claims; resolve icon outpoints independently if display integrity matters.

Implementations

• b-open-io/1sat-stack
• b-open-io/1sat-sdk

References

1. RFC 8949 — CBOR
2. BRC-36 — Outpoints
3. BRC-45 — UTXOs as tokens
4. BRC-161 — BSV-21 Fungible Tokens (JSON / Legacy)