CashTokens on Bitcoin Cash
CashTokens are native token primitives for Bitcoin Cash applications.
CashTokens carry fungible-token and NFT state in Bitcoin Cash transaction outputs. This guide explains what wallets, indexers, and applications need to handle when they build token-aware products.
Educational overview. Product implementations vary.
The primitive
A token is state carried by a UTXO.
CashTokens extend the Bitcoin Cash UTXO model with native token state. The protocol defines what can be carried by an output; the wallet, indexer, and application decide how that state becomes a usable product.
A token-bearing output can contain a fungible amount, one NFT, or both, with all token data in that output belonging to the same category.
Fungible amounts
A token category and amount travel with a BCH output, so balances are assembled from token-bearing UTXOs.
NFT commitments
NFTs carry a commitment and a capability (none, mutable, or minting). Wallets must handle that state according to the capability and intended transaction.
Token-aware transactions
A builder must select the right token inputs and construct outputs without unintentionally burning tokens, changing NFT state, or misallocating BCH value.
Human-readable display
BCMR metadata can give wallets and applications names, symbols, decimals, icons, and descriptions to display.
From primitive to product
Wallets and applications must handle token state explicitly.
CashTokens are not an account balance stored in an application database. Every token-aware action has to be reflected in the inputs and outputs of a BCH transaction.
Keep BCH value and token state separate while selecting inputs and calculating change.
Preserve the category, amount, NFT capability, and commitment required by the intended flow.
Use BCMR data for display and discovery while keeping the on-chain category as the asset reference.
Cover sends, splits, merges, capability transitions and intentional token burns, missing metadata, and unsupported wallet paths.
CashTokens and covenants
Asset state and spend rules are different layers.
CashTokens describe the asset state carried by a transaction. Covenants constrain which transaction paths are permitted. A product can use either layer independently, or combine them when a token flow also needs enforceable spend conditions.
CashTokens answer
Which token category is present?
How much is carried?
Which NFT capability or commitment applies?
Covenants answer
Which transaction path is allowed?
What outputs must be created?
How does the controlled state continue?
What CashTokens do not provide by themselves
The protocol primitive is only one part of the product.
Wallet behavior
Token selection, change handling, signing, and user-facing transaction previews still need to be built.
Metadata availability
Names and icons depend on metadata resolution. Clients need useful fallbacks when metadata is missing or stale.
Spend restrictions
Token state does not automatically restrict future spends. Use a covenant when the transaction path itself must be constrained.
Application correctness
Builders and tests must prove that the resulting token state matches the intended transition.
Continue the technical path
Move from the token primitive to enforcement, metadata, wallet behavior, or implementation resources.
Related reading
Building a CashTokens product?
Start with the protocol layer, then bring us the wallet, application, or integration problem.