CashTokens are native Bitcoin Cash token primitives. A token-aware transaction can carry fungible amounts, non-fungible commitments, and NFT capabilities inside BCH outputs while remaining part of the UTXO model.
TX::Watch and TokenWatch share one parser so the visual stream and token-focused interface interpret those outputs consistently.
Decode the protocol, not a hand-written approximation
CashToken data begins with a token prefix in a transaction output's locking bytecode. Earlier versions of this article walked through a partial manual decoder. That approach was easy to get wrong: compact integers are variable length, category IDs have a defined byte order, and NFT capability and commitment fields change the structure.
The current implementation uses Libauth's token-prefix reader, which follows the CashTokens specification. It rejects malformed prefixes and returns:
- the 32-byte token category ID;
- the fungible token amount;
- an optional NFT commitment;
- an optional NFT capability: immutable, mutable, or minting.
The parser inspects every available token-bearing input and output, not just output zero.
Compare category flows
For each category, TX::Watch groups decoded inputs and outputs. The difference can support several useful labels:
- genesis, when a category first appears under the protocol's genesis rules;
- fungible transfer or apparent fungible burn;
- NFT transfer;
- NFT creation or update;
- minting-baton activity;
- apparent NFT burn;
- mixed fungible and NFT activity.
These are interface-level classifications. A browser feed may omit previous-output detail, and matching an NFT by capability and commitment does not establish the participants' intent. Consensus validation remains the job of a validating BCH node.
Resolve identity separately
The category ID is authoritative protocol data. A human-readable name, symbol, icon, website, and decimal preference come from metadata, commonly through a Bitcoin Cash Metadata Registry.
TX::Watch can request metadata from Paytaca's BCMR indexer and on-chain context from Chaingraph. That information is optional and untrusted:
- a token can have no valid metadata;
- registries can conflict or become unavailable;
- an icon or website is not proof of issuer identity;
- decimal places affect display, not the base-unit amount encoded in the transaction.
Unknown categories stay visible under their category ID rather than being discarded.
Keep the visual claim narrow
The tools show activity observed during the current browser session. They are not complete token directories, portfolio trackers, price feeds, or trading systems. Counts can reset, upstream services can lag, and lifecycle labels can remain incomplete until enough transaction context is available.
That narrower contract is useful: protocol bytes establish that token activity exists, metadata makes it legible when available, and the interface keeps the distinction visible.