How RGB Protocol on Bitcoin
works.
RGB Protocol on Bitcoin has three cryptographic primitives — client-side validation, single-use seals, and the Schema system — working together to make digital asset ownership on Bitcoin possible without publishing contract data on-chain.
All technical content on this page is based on RGB documentation at docs.rgb.info ↗
RGB Protocol on Bitcoin is built on three
cryptographic building blocks.
Each primitive solves a specific problem. Together they make it possible to own and transfer digital assets on Bitcoin without any contract data touching the blockchain.
Client-side validation
Each party validates only their own slice of contract history. Privacy by design, unlimited scalability.
Single-use seals
Every state transition is bound to a Bitcoin UTXO. Spending it closes the seal — preventing double-spending.
Schema system
Declarative contract templates define state structure and transition rules — without executable on-chain code.
The order matters: the Schema defines what the contract is, client-side validation ensures only relevant parties see the data, and single-use seals ensure each transition is final and unique. Bitcoin provides the timestamp and double-spend protection.
Each party validates
only what matters to them.
◎ Source: docs.rgb.info — Client-side Validation ↗
In a standard blockchain, every node stores and re-executes every contract. This creates a fundamental scalability and privacy ceiling — all data is public, all nodes bear the full computational load.
RGB inverts this. As stated in docs.rgb.info, “the logic of validation can be reversed”: each participant validates only their own relevant subset of contract history — the Directed Acyclic Graph (DAG) connecting Genesis to their current owned state. This private slice of history is called a shard.
The scalability benefit is direct: since only the tiny cryptographic commitment needs to be stored by all (order of tens of bytes, or zero extra bytes in the Tapret scheme), thousands of RGB transitions from different contracts can be batched into a single Bitcoin transaction with negligible on-chain footprint.
A promise that can only
be kept once.
Definition — docs.rgb.info
“Single-Use-Seal is a formal promise to commit to a (yet) unknown message in the future, once and only once, such that the fact of commitment is demonstrably known to all members of a certain audience.”
— docs.rgb.info/distributed-computing-concepts/single-use-seals
Proposed by Peter Todd in 2016, single-use seals are the anti-double-spend mechanism of RGB Protocol on Bitcoin. They work in three steps:
Alice defines the seal
Alice promises Bob to publish a specific message at a defined point in time, using an agreed publication medium — in RGB, a Bitcoin UTXO.
seal ← Define()
Alice closes the seal
Alice publishes the message (an RGB state transition commitment) by spending the UTXO. This produces a witness — proof the seal was closed. The seal cannot be closed again.
witness ← Close(seal, message)
Bob verifies independently
Bob receives the seal, witness, and message, and verifies locally that the seal was correctly closed. No trust in Alice required — the Bitcoin blockchain provides the proof.
bool ← Verify(seal, witness, message)
In RGB, seal definitions are Bitcoin UTXOs. The commitment is a hash embedded in a Bitcoin transaction. The seal closure is the spending of that UTXO. The chain of connected transaction spends represents the Proof-of-Publication — the immutable record that a transition occurred.
This is what makes ownership of RGB assets identical in security to ownership of bitcoin itself: controlling a UTXO means controlling all RGB assets assigned to it via single-use seals.
Contracts defined declaratively,
not as executable code.
An RGB Schema is a declarative template that defines the structure of a contract. As documented in docs.rgb.info, a Schema is the analog of a class in object-oriented programming — it specifies what the contract is, not how to execute it on-chain.
This is architecturally different from Ethereum, where contract code is stored and executed by every node on the blockchain. In RGB, the Schema defines validation rules that are executed locally by AluVM during client-side validation — never on-chain. A Schema answers:
What owned states and assignments exist?
What global state does the contract have?
How is Genesis structured?
What state transitions are possible?
How can state data change within transitions?
After compilation, a Schema is encoded in a .rgb binary file imported by wallet software. Five standard schemas are supported — NIA, UDA, CFA, IFA, PFA — and custom schemas can be built for any use case.
From Genesis to the
current state.
As documented in docs.rgb.info, “a State can be defined as a unique configuration of information or data that represents the conditions of a contract at a specific point in time.” Every RGB contract evolves through a chain of state transitions from its first definition (Genesis) to its current active state.
Genesis
First contract state. Defines global state (ticker, supply) and initial ownership allocations.
State transition
Each transition builds on the previous, forming a DAG. Ordering guaranteed by Bitcoin timestamps.
Genesis
First contract state. Defines global state (ticker, supply) and initial ownership allocations.
State transition
Each transition builds on the previous, forming a DAG. Ordering guaranteed by Bitcoin timestamps.
The key insight from docs.rgb.info: “a given chain of RGB transitions does not necessarily correspond to a chain of Bitcoin transactions” — the on-chain order of anchor transactions does not allow inferring the ordering of DAG nodes. The DAG ordering is maintained by operations committing to their inputs, anchored to Bitcoin for timestamping.
Assets that move at
Lightning speed.
The primitives above don’t just work on Bitcoin’s base layer — they integrate natively with the Lightning Network. RGB state transitions embed directly inside Lightning commitment transactions, meaning assets flow through typed channels at the same speed and cost as any Lightning payment.
Unlike approaches that wrap or bridge assets to interact with Lightning, RGB operates at the protocol level. Each channel carries its own typed asset state — validated privately by each party, settled on Bitcoin, with no extra trust assumption beyond the channel itself.
Instant settlement
RGB asset transfers settle in milliseconds — the same speed as any Lightning payment, identical security from Bitcoin’s proof-of-work.
Near-zero fees
Lightning routing fees apply — fractions of a cent regardless of amount. No base-layer transaction cost, no gas, no fee market.
Contracts that work like
bearer instruments.
As documented in docs.rgb.info, the philosophy behind RGB’s architecture has historical roots: “Not long ago, contracts such as securities were bearer instruments. The bearer nature of contracts is, in fact, a centuries-old tradition.”
RGB revives this model in digital form. The bearer rights of each party are contained as data within the contract — held privately, transferable directly between parties, enforced cryptographically without a custodian or registry.
Assets live in custodial registries
– Bank or broker holds the record of ownership
– Transfer requires intermediary approval
– Counterparty risk at every level
– Privacy depends on institution policies
– Censorship possible at registry level
Rights contained in the contract itself
– Ownership proven by controlling the UTXO
– Transfer is direct — sender to receiver
– No intermediary, no custodian
– Privacy by design — data between parties only
– Bitcoin-level censorship resistance
The order matters: the Schema defines what the contract is, client-side validation ensures only relevant parties see the data, and single-use seals ensure each transition is final and unique. Bitcoin provides the timestamp and double-spend protection.
What to read
next.
Client-side validation
Deep dive into the privacy and scalability model of RGB.
RGB & Lightning Network
How state transitions work inside Lightning channels.
Ready to build
on RGB Protocol on Bitcoin?
The primitives are clear — now put them to work.