Client-side validation —
the model that makes RGB possible.
Most blockchain protocols ask every node to validate every transaction. RGB inverts this entirely — each party validates only what matters to them, privately, without broadcasting anything to the network.
In this approach, contract data never touches the blockchain. Each participant holds and validates only their own slice of history. Bitcoin stores only a cryptographic proof — a few bytes — that the transition occurred.
A contract that doesn’t need
to be public to be valid.
Client-side validation is a cryptographic model in which the parties involved in a transaction validate the data themselves — locally, privately, without publishing anything to a global network. Only a compact cryptographic commitment is anchored to the Bitcoin blockchain, proving that a specific state transition occurred at a specific point in time.
Think of it as the digital equivalent of a signed contract between two parties. The contract is valid because both parties hold a signed copy and can verify its authenticity — not because it was registered in a public database.
Analogy
Imagine you transfer the ownership of a car. You don’t need to publish the full contract in a public newspaper — you need a signed document between buyer and seller, and a registration entry (the commitment) that proves the transfer happened on a specific date. RGB approach works the same way: the full data stays between the parties, Bitcoin provides the timestamp and the proof of uniqueness.
Why public blockchains
hit a hard ceiling.
In a standard blockchain like Ethereum, every node stores and re-executes every contract. This creates two fundamental problems that cannot be solved without compromising the security model: scalability and privacy.
|
Property |
On-chain validation |
Client-side validation |
|---|---|---|
|
Who validates? |
Every node on the network |
Only the parties involved |
|
Contract data location |
Public blockchain |
Off-chain, between parties |
|
Privacy |
✕ Publicly visible |
✓ Fully private |
|
Scalability |
✕ Limited by block size |
✓ Unlimited horizontal |
|
On-chain footprint |
Full contract data |
A few bytes per transition |
|
Bitcoin compatibility |
✕ Requires separate chain |
✓ Native on Bitcoin |
|
Lightning Network support |
✕ Not natively |
✓ Native integration |
Three steps. No global state.
Full Bitcoin security.
RGB implements client-side validation through a precise sequence of operations that keeps all contract data private while anchoring every transition to Bitcoin’s immutable ledger.
Contract state stays off-chain
The full contract state — ownership, amounts, conditions, history — is held privately by the parties involved. When Alice transfers an RGB asset to Bob, she sends him the relevant slice of contract history directly. No broadcast to the network, no public ledger entry, no third-party storage.
Data stays between Alice and Bob
A cryptographic commitment is anchored to Bitcoin
Giacomo Zucco and Peter Todd conceptualize RGB as a protocol for issuing digital assets on Bitcoin using client-side validation and single-use seals — without requiring a separate blockchain or on-chain contract data.
Bitcoin timestamps the transition
Bob validates locally and independently
Bob receives the contract history from Alice and validates it himself — checking that every transition in the chain is valid, that the genesis is correct, and that the Bitcoin commitments match. No trusted third party. No global consensus required. If the validation passes, the transfer is complete.
Trustless, local, independent
Three properties no on-chain
protocol can achieve together.
Client-side validation is not a trade-off — it is an architectural choice that enables three properties simultaneously, which is impossible in any system that stores contract data on a public blockchain.
Unlimited scalability
Thousands of RGB state transitions can be batched into a single Bitcoin transaction. Assets don’t compete for blockspace. There is no gas market, no throughput ceiling, no congestion tied to contract execution.
True privacy
Contract state — who owns what, how much, under what conditions — is never published anywhere. It is visible only to the parties directly involved in each specific transfer. Not even the Bitcoin blockchain knows.
Bitcoin-native security
Every state transition is anchored to a Bitcoin UTXO via a single-use seal. The security model is identical to Bitcoin itself — no additional validators, no federations, no extra trust assumptions required.
How RGB compares to
other Bitcoin asset protocols.
Client-side validation is the defining architectural difference between RGB Protocol on Bitcoin and every other protocol that brings assets to Bitcoin. Here is how the three main approaches compare.
|
Property |
RGB Client-side validation All contract data off-chain. Bitcoin as commitment layer only. |
Taproot Assets On-chain commitments Asset metadata committed in Taproot outputs. Some data on-chain. |
|---|---|---|
|
Privacy |
✓ Complete — nothing on-chain |
◑ Partial — metadata visible |
|
Scalability |
✓ Unlimited batching |
◑ Limited by Taproot outputs |
|
Contract expressiveness |
✓ Full Schema system |
✕ Token transfers only |
|
Lightning native |
✓ Typed channels, no bridge |
◑ Via Lightning Labs infra |
|
On-chain footprint |
✓ A few bytes per transition |
◑ Taproot output per asset |
For any doubt, see our dedicated section on RGB Protocol vs RGB++ →
What to read
next.
Client-side validation is the foundation — but RGB builds a full protocol on top of it. Here is where to go next depending on what you want to understand or build.
How RGB works
Single-use seals, schema-based contracts, and state transitions explained.
RGB & Lightning Network
How client-side validation enables native Lightning asset channels.
Client-side validation docs
Full technical specification of client-side validation. docs.rgb.info ↗
RGB Protocol AI Assistant
Ask questions about client-side validation and RGB. chatgpt.com.RGBProtocol ↗
Ready to build
on client-side validation?
Everything you need to start developing on RGB.