Client-side validation

Wonder

1. Why would a protocol commit to less data on-chain to achieve more privacy?
2. How does a single hash prevent double-spending without revealing the asset’s history?
3. What is the cost of moving trust from a central indexer to every individual user?

Explore

1. In standard token protocols, all state resides on-chain. Every transfer is visible, and any node can reconstruct the entire history. This transparency enables shared markets but sacrifices privacy and scale. Client-side validation inverts this model. Instead of storing the asset’s full history in a global ledger, each holder maintains their own copy of the relevant data. The blockchain stores only a cryptographic fingerprint (a commitment), placed when a seal is closed, that links to this off-chain state.
2. Peter Todd developed the idea around 2016, built on his concept of ‘single-use seals’. A seal is a Bitcoin output, which can be spent only once. To transfer an asset, Alice spends that output in a transaction that commits to a hash of the transfer, naming a new seal for Bob. Because an output can be spent only once, Alice cannot close the same seal twice; a second transfer would have no valid seal, and anyone checking the history would reject it.
3. The privacy benefit is structural. Since the full asset history never touches the public blockchain, observers cannot trace ownership chains or analyze trading patterns. History is shared only with each successive holder, never with the public. This allows for confidential contracts and assets to circulate on Bitcoin without exposing user activity to global surveillance, a significant departure from transparent token standards.
4. The trade-off is burden. Users must store their asset history securely and pass it along with every transaction. If a user loses this data, they lose access to the asset, as no central authority can restore it. This ‘bring your own state’ model requires robust local storage and careful key management. It shifts complexity from network nodes to individual clients, demanding higher technical literacy from users who wish to participate.
5. RGB, based on Todd’s ideas and developed largely by Maxim Orlovsky and the LNP/BP Standards Association, is a prominent implementation of this logic. It uses structured contracts where each transition commits to the next set of rules via a seal. More recently, Lightning Labs launched Taproot Assets on Bitcoin mainnet in October 2023. This protocol leverages Taproot’s script flexibility to embed these commitments efficiently, supporting fungible tokens and non-fungible assets with enhanced privacy features compared to earlier colored coin attempts.
6. Shared markets remain the primary limitation. In a decentralized exchange where thousands of users trade against a single liquidity pool, every participant must verify the entire state of that pool locally. This is computationally intensive and difficult to synchronize in real-time. Client-side validation excels in point-to-point transfers or small groups but struggles with high-throughput, many-to-many applications that require immediate global consensus on asset state.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• P. Todd, 'Single-use seals' (2016-2017)
• RGB Protocol Documentation (rgb.tech)
• Lightning Labs, Taproot Assets Mainnet Launch Announcement (October 2023)