BRC-161/162: BSV-21 fungible tokens (JSON + binary)

[shruggr]

Summary

BRC	File	Content
161	tokens/0161.md	BSV-21 JSON / legacy (application/bsv-20 inscription)
162	tokens/0162.md	BSV-21 binary (preferred for new tokens)

• Token id = deploy outpoint; UTXO balances; fixed supply + authority mint
• 161 uses ord envelopes (BRC-160); balance rules are BSV-21 UTXO/authority, not 1Sat sat-ordering
• 162 is script-native prefix + CBOR payload

Test plan

• Spec review of 161/162

[GenericCPU]

Looks like the right split: 161/162 = token economics + wire, and (as you noted) not BRC-100 baskets.

HandCash is aligned on JSON/161 for Collect → Tokens (basket bsv21, not Pay / not 1sat). Filing a thin BRC-163 basket profile next that depends on this PR — list/send/import + CI/id/amt remittance, admission still 161/162.

[GenericCPU]

Let me know what you think
#217

[Copilot]

Pull request overview

Adds BRC-161 and BRC-162 to define the BSV-21 fungible token protocol in two encodings: a legacy JSON ord inscription carrier (161) and a preferred binary script-prefix + CBOR payload format (162). This fits into the existing tokens/ standards set and updates the repo’s navigational indexes accordingly.

Changes:

• Introduces BRC-161: BSV-21 fungible tokens via application/bsv-20 JSON inscriptions (legacy carrier).
• Introduces BRC-162: BSV-21 fungible tokens via script-native prefix and optional CBOR payload (preferred for new tokens).
• Adds both new specs to tokens/README.md, root README.md, and SUMMARY.md for discoverability.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tokens/README.md	Adds BRC-161/162 entries to the tokens index table.
tokens/0161.md	New spec: BSV-21 JSON/legacy inscription encoding and validation rules.
tokens/0162.md	New spec: BSV-21 binary script-prefix encoding and CBOR payload rules.
SUMMARY.md	Adds BRC-161/162 to the GitBook/SUMMARY navigation.
README.md	Adds BRC-161/162 to the root standards index table.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

tokens/0162.md:16

• The abstract sentence "later authority spends mint new supply" is ungrammatical and reads like a missing word. This is a spec doc, so tightening the language helps avoid ambiguity.

2. **Authority** — deploy creates minting authority; later authority spends mint new supply.

tokens/0162.md:136

• The icon paragraph has a duplicated phrase: "a B protocol file (B protocol (...))". This reads like an editing artifact and makes the reference less clear.

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.

[shruggr]

@copilot How are you suggesting this to work? I'm not sure that I really see what the issue is here directly. How would you suggest we change this?

[shruggr]

Please address my question

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (2)

tokens/0162.md:196

• The value-output validation rule here makes authority spends a blanket bypass for balance conservation ("value outputs are valid without input balance coverage"). That contradicts BRC-161, which explicitly states authority inputs do not relax transfer balance checks, and it also contradicts the PR description’s claim that 161 vs 162 differ only by encoding. This needs a single, consistent rule across both specs (either introduce an explicit per-output operation marker in the binary encoding, or update the JSON rules to allow authority/minting to cover transfer outputs in the same tx).

**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).

tokens/0162.md:77

• BRC-161 defines the token id string form as 64 lowercase hex txid characters plus underscore plus non-negative decimal vout. To ensure the JSON and binary encodings round-trip to the exact same id representation, BRC-162 should also explicitly require lowercase hex (and ideally call out decimal vout) here.

* 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](./0161.md)); this id form is fixed for BSV-21 and is not the general dual-form outpoint convention in [BRC-159](./0159.md), so a token presents identically under either encoding. Converting between 36-byte form and that string reverses the 32 txid bytes only.