CashTokens on Bitcoin Cash
Build token-enabled products on Bitcoin Cash.
CashTokens let products issue, display, and move fungible tokens and NFTs directly on Bitcoin Cash. This guide explains what wallets, apps, and product teams need to make those experiences work.
0x010x02Example bytes only. Commitment data is application-defined; BCH validates the token transition.
The foundation
The building blocks for token-powered BCH products.
CashTokens add native token state to Bitcoin Cash. The protocol defines what an output can carry; wallets, indexers, and apps turn that foundation into a product people can use.
An output can carry 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 foundation to product
Make token experiences work from end to end.
A CashToken balance is built from the outputs that hold it, not from an account balance in an app database. Every token-aware action therefore has to be reflected in 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?
Building complete CashToken products
From native token state to a usable 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.