Chapter 22

Client-Side Validation

Single-Use Seals and Off-Chain State

Bitcoin's blockchain provides a globally replicated, publicly verifiable ledger. But this publicity comes at a cost: every node must validate every transaction, limiting throughput and privacy. Client-side validation inverts this model— validation happens privately between transacting parties, with Bitcoin serving only as a timestamping and anti-double-spend anchor.

This chapter explores the theoretical foundations of client-side validation, from Peter Todd's single-use seals to modern implementations like RGB and Taproot Assets. These protocols enable scalable, private asset issuance on Bitcoin without bloating the blockchain.

22.1 The Validation Paradigm Shift

Traditional blockchain design couples state transitions with global consensus:

On-Chain Validation

Model: Publish all data on-chain; every node validates everything

Scaling: O(n) validation for n transactions

Privacy: All transaction data public

Example: Standard Bitcoin, Ethereum ERC-20

Client-Side Validation

Model: Data exchanged privately; blockchain proves non-double-spend

Scaling: O(1) on-chain, O(history) for recipient

Privacy: Only parties see transaction data

Example: RGB, Taproot Assets

Definition 22.1 (Client-Side Validation)

In a client-side validation protocol:

  1. State transitions (e.g., asset transfers) happen off-chain
  2. The sender proves validity to the receiver directly
  3. Bitcoin transactions serve as witnesses to prevent double-spending
  4. Full nodes see only opaque commitments, not transaction meaning

What Bitcoin Provides

Client-side validation leverages specific Bitcoin properties:

Property Use in CSV
Transaction ordering Determines which spend came first
UTXO uniqueness Each UTXO can be spent exactly once
OP_RETURN / Taproot Embed commitments in transactions
Timestamping Prove state existed at block time
Censorship resistance Anyone can publish commitments

22.2 Single-Use Seals

The theoretical foundation of client-side validation is the single-use seal, introduced by Peter Todd in 2016.

Definition 22.2 (Single-Use Seal)

A single-use seal is a cryptographic primitive that can be:

  • Opened: Closed over a message exactly once
  • Verified: Anyone can check if a seal was closed over message m
  • Unique: A seal cannot be closed over two different messages

Formally, a seal S provides:

  • Close(S, m) → witness: Close seal over message m
  • Verify(S, m, witness) → bool: Verify seal was closed over m

With the property that if Verify(S, m₁, w₁) and Verify(S, m₂, w₂) both return true, then m₁ = m₂.

Bitcoin UTXOs as Seals

Theorem 22.1 (UTXO Single-Use Seal)

A Bitcoin UTXO naturally implements a single-use seal:

  • Seal identifier: The outpoint (txid:vout)
  • Close operation: Spend the UTXO with commitment to m in the spending tx
  • Witness: The spending transaction
  • Verification: Check tx spends the UTXO and contains commitment to m

The seal can only be closed once because a UTXO can only be spent once.

Proof.

Suppose an adversary could close seal (UTXO) over both m₁ and m₂ where m₁ ≠ m₂. This would require two transactions tx₁ and tx₂ both spending the same UTXO, with tx₁ committing to m₁ and tx₂ committing to m₂. But Bitcoin consensus ensures only one transaction spending a given UTXO can be included in the blockchain. Therefore, at most one closing can be valid. ∎

Single-Use Seal Using Bitcoin UTXO UTXO (Seal) abc123...:0 State: OPEN Spend with commitment Spending Transaction Input: spends abc123...:0 OP_RETURN / Taproot commit Hash(message) Seal CLOSED over message m Double-Close Attempt (Impossible) Cannot create second valid spending tx for same UTXO Bitcoin consensus guarantees UTXO uniqueness
Figure 22.1 — A Bitcoin UTXO as a single-use seal: spending the UTXO with a commitment "closes" the seal over that message. The UTXO can only be spent once, ensuring the seal can only be closed once.

Commitment Schemes

The message committed to in the seal can be embedded in various ways:

Definition 22.3 (Commitment Methods)

Method Location Size Privacy
OP_RETURN Output script Up to 80 bytes Visible commitment
Pay-to-contract Public key tweak 32 bytes (hidden) Indistinguishable from regular
Taproot Script tree leaf Arbitrary Hidden unless revealed

Definition 22.4 (Pay-to-Contract)

Given public key P and message m, the tweaked key is:

P' = P + H(P || m) · G

Where H is a hash function and G is the generator. The commitment is hidden in P' but verifiable given P and m.

22.3 RGB Protocol

RGB is the most developed client-side validation protocol for Bitcoin, enabling smart contracts and asset issuance with full privacy and scalability.

Definition 22.5 (RGB)

RGB (Really Good Bitcoin) is a client-side validation system where:

  • State: Asset ownership, contract data stored off-chain
  • Transitions: State changes validated by recipients
  • Anchoring: Commitments embedded in Bitcoin transactions
  • Seals: UTXOs define ownership and prevent double-spending

RGB Architecture

RGB Protocol Architecture Bitcoin Layer UTXOs (seals) + Taproot commitments (anchors) Public, validates ordering and uniqueness only RGB State Layer Contract Schema Defines state + transitions State (Off-chain) Asset ownership, data State Transitions Transfers, operations Consign Proofs Client Validation Layer Sender Creates transition Consignment (state proof) Receiver Validates proof Private P2P only
Figure 22.2 — RGB architecture: clients exchange proofs directly; Bitcoin provides only anchoring and anti-double-spend guarantees.

RGB State Transitions

Definition 22.6 (RGB State Transition)

An RGB state transition contains:

  • Inputs: References to previous state (seals being closed)
  • Outputs: New state assignments to new seals
  • Metadata: Contract-specific data
  • Anchor: Reference to Bitcoin transaction commitment

Example 22.1 (RGB Asset Transfer)

Alice owns 100 RGB tokens sealed to UTXO A. She transfers 30 to Bob:

  1. Create state transition: Input: 100@UTXO_A → Outputs: 70@UTXO_A', 30@UTXO_B
  2. Anchor transition to Bitcoin tx that spends UTXO_A
  3. Create consignment (proof) for Bob containing:
    • The state transition
    • Complete history back to issuance
    • Bitcoin anchoring proofs
  4. Bob validates the entire history client-side
  5. If valid, Bob accepts the 30 tokens

Consignments

Definition 22.7 (Consignment)

A consignment is the proof package sent from sender to receiver:

  • Complete DAG of state transitions from genesis to current
  • Bitcoin anchoring data (transaction proofs)
  • Contract schema and validation code
  • Only the branch relevant to the receiver's incoming state

Theorem 22.2 (RGB Validation Completeness)

Given a valid consignment, a receiver can independently verify:

  1. The genesis contract is valid
  2. Every state transition follows contract rules
  3. Every anchor exists in a confirmed Bitcoin block
  4. No seal was closed twice (via Bitcoin UTXO uniqueness)

The receiver needs no trusted third party—verification is purely mathematical.

Privacy Properties

Observer What They Learn
Bitcoin full node Nothing (just sees regular Bitcoin tx)
Blockchain analyst Cannot link RGB activity without consignment
Receiver Only the history leading to their receipt
Other RGB users Nothing about unrelated transfers

22.4 Taproot Assets (Taro)

Taproot Assets (formerly Taro) is Lightning Labs' implementation of client-side validation, designed specifically for Lightning Network integration.

Definition 22.8 (Taproot Assets)

Taproot Assets uses Taproot's script tree for commitments:

  • Asset tree: Merkle tree of asset commitments in Taproot leaves
  • MS-SMT: Merkle-Sum Sparse Merkle Tree for asset state
  • Universe: Optional public registry for asset discovery
  • Lightning: Native integration via asset channels

Taproot Integration

Taproot Assets Commitment Structure Taproot Output P = Internal + H(Internal||root)·G Script Tree Root Regular Scripts Asset Commit Asset Commitment • Asset ID • Amount • Script key • Version, metadata
Figure 22.3 — Taproot Assets embeds asset commitments in Taproot script trees. The commitment is invisible unless revealed.

Comparison: RGB vs Taproot Assets

Feature RGB Taproot Assets
Smart contracts Full schema system Limited (assets focus)
Commitment Taproot / OP_RETURN Taproot only
Data structure DAG of transitions MS-SMT
Lightning Via separate channels Native integration
Discovery Fully private Optional "Universe"
Maturity Longer development Newer

22.5 Scalability Analysis

On-Chain Footprint

Theorem 22.3 (CSV On-Chain Scaling)

For N client-side validation transfers, the blockchain footprint is:

  • Optimal case: O(1) — multiple transfers share one anchor tx
  • Typical case: O(N) Bitcoin transactions, but each tx is minimal size
  • Data stored: Only commitments (~32 bytes), not state

Compare to on-chain tokens (e.g., ERC-20): each transfer requires full transaction data stored forever.

Validation Cost

Theorem 22.4 (Validation Scaling)

Receiver validation cost is O(history_length), not O(all_transfers):

  • Receiver only validates their branch of history
  • Parallel branches (other users' transfers) never seen
  • History can be pruned after validation

Example 22.2 (Validation Comparison)

An asset with 1 million total transfers, Alice receiving for the first time:

Approach Alice Must Validate
On-chain (Ethereum ERC-20) Sync entire blockchain
RGB / Taproot Assets ~10-100 transitions (her branch only)

Trade-offs

Aspect Benefit Cost
Privacy Complete (only parties see data) No public auditability
Scalability Minimal blockchain footprint Client storage of proofs
Interactivity — Receiver must be online to validate
Recovery — Must backup consignments, not just seed

22.6 Applications

Use Cases

Lightning Integration

Both RGB and Taproot Assets support Lightning Network transfers:

Exercises

Exercise 22.1

Prove that a single-use seal based on Bitcoin UTXOs cannot be closed twice, assuming Bitcoin's consensus rules hold.

Exercise 22.2

Design a pay-to-contract scheme for committing to RGB state transitions in a Taproot output. Show how to verify the commitment.

Exercise 22.3

Alice transfers RGB tokens to Bob, who transfers to Carol. What must Carol's consignment contain? What can Carol learn about Alice from this consignment?

Exercise 22.4

Compare the blockchain footprint of transferring a token 1000 times using: (a) Ethereum ERC-20, (b) RGB with individual anchors, (c) RGB with batched anchors.

Exercise 22.5

Explain why client-side validation cannot provide the same "trustless audit" properties as on-chain tokens. In what scenarios is this acceptable or even desirable?

Exercise 22.6

Design a backup strategy for RGB assets. What must be preserved beyond the Bitcoin wallet seed? What happens if a consignment is lost?

Chapter Summary