CashTokens Kickoff: Building with Native Tokens and Covenants on Bitcoin Cash

Bitcoin Cash combines low-cost UTXO transactions with native token state and transaction-level programmability.

CashTokens let fungible tokens and NFTs live directly on BCH outputs, while covenants can define how selected funds and state may move next.

For builders, this creates an application model based on composing transactions from UTXOs and validating the resulting state at the transaction boundary. This article introduces that model and the product patterns it enables.

The UTXO Model: How It Differs and Where It Provides Value

In account-based systems, token balances are commonly tracked in contract storage:

• Token balances are tracked in contract storage.
• Transfers update that storage through calls or instructions.
• Applications can layer additional business logic around those contract calls.

On BCH with CashTokens:

• No central balance variables in contracts.
• Holdings aggregate token amounts across controlled UTXOs.
• Transfers spend existing UTXOs to produce new ones.
• Ownership enforces natively at the protocol level.

This UTXO model is useful for workflows built around discrete outputs and transaction-level validation:

• Low-cost payments — BCH transaction fees support frequent, low-value transfers.
• Protocol-level token validation — BCH nodes validate token state according to CashTokens rules.
• UTXO-based transfers — Token movements consume existing outputs and create new ones.

This model suits applications built around explicit inputs, outputs, and transaction-level state transitions.

---

CashTokens Fundamentals

CashTokens extend Bitcoin Cash outputs with an optional token prefix (codepoint 0xef) that encodes token data before the locking bytecode.²

Token Representation on Outputs

• Each output carries at most one NFT and fungible tokens from only one category.
• Protocol enforces conservation: input tokens ≥ output tokens per category (implicit burning allowed).

Fungible Tokens

• Undifferentiated units (like BCH sats).
• Defined by a 32-byte category ID + amount (1 to ~9 quintillion).
• All supply created in the genesis transaction — no later minting.

Non-Fungible Tokens (NFTs)

• Unique items with a commitment (0–40 bytes, attested by issuer).
• Commitments can hold metadata, state, or IDs.
• Multiple NFTs can share commitments unless covenants enforce uniqueness.

NFT Capabilities (4-bit field)

• None (immutable) — Fixed commitment.
• Mutable — Spending tx can update commitment.
• Minting — Spending tx can create any number of new NFTs.

Capabilities enable powerful patterns: controlled issuance (minting NFT as "admin key"), updatable state, or restricted mutation.

Token Categories & Genesis

• Category ID = TXID of the genesis transaction (from input spending output 0).
• Genesis creates full fungible supply + initial NFTs.
• Protocol prevents over-minting or invalid transitions.

Ownership follows UTXO control — ledger-verified, no extra layers.

---

Covenants: Enforcing Spend Conditions

Covenants embed constraints into an output's locking script using native introspection (expanded since 2022/2023).³

How Covenants Work

• Scripts inspect the spending transaction via opcodes/variables:
  • tx.inputs[i].tokenAmount, tx.outputs[i].nftCommitment
  • this.activeInputIndex, this.age, tx.time, etc.
• No persistent state — evaluated fresh per spend.
• Logic checks the entire tx structure (inputs, outputs, tokens) against rules.

This creates constraint-based programming: enforce what the next tx must look like, rather than mutating state over time.

Common Enforcement Patterns

• Require specific output destinations (e.g., match P2PKH hash160).
• Conserve value/tokens exactly (deduct fee, redistribute).
• Gate actions with NFTs (require minting capability for issuance).
• Use NFT commitments for "state" (timestamps, counters).
• Timelocks, heartbeats, or inheritance after timeout.

Differences from EVM-Style Contracts

Covenants define transaction conditions without relying on persistent contract storage:

• Transaction-bound validation
• Rules evaluated against the spending transaction
• State carried forward through UTXOs and NFTs

This model is less general than a Turing-complete VM, but can be a good fit when the required financial behavior can be expressed as explicit transaction conditions.

---

Translating Authority Patterns: NFTs as Control Mechanisms

Account-based systems commonly represent administrative authority through stored roles or program-defined signer addresses.

On BCH, a product can represent authority with an NFT and transaction rules:

• Covenant requires NFT inclusion (often specific capability) for sensitive ops.
• Transfer NFT → reassign control. No code changes, no migrations.

Key consideration:
Authority demands explicit tx proof every time — predictable in constrained scenarios, but requires careful design to avoid unintended spends.

---

Next Steps in the Series

CashTokens Hands-On covers implementation:

1. NFT-controlled issuance
2. Fungible token flows
3. Authority reassignment via NFT transfer

All on local CashScript mocknet for clear, testable mechanics.

OPTN Labs builds products and infrastructure around these primitives, including self-custody wallets, token-aware application flows, and covenant-based transaction workflows. For the technical guides and builder resources, use the links above to continue into the CashTokens, covenants, and developer material.