RGB brings smart contracts and assets to Bitcoin without putting them on the chain. Contract logic and state live off-chain. Bitcoin holds only a small commitment. Ownership stays as strong as holding bitcoin itself. The standard is maintained by the RGB Protocol Association.
Most chains put the contract on-chain. RGB keeps it off.
On an account chain, every node stores and re-runs your contract. RGB inverts this. The contract and its history stay with the owner. The chain sees one commitment.
On-chain contracts · e.g. Ethereum
Public block
Contract code
All state and history
Every counterparty
Stored and re-executed by every node. Heavy, public, permanent.
RGB · client-side validation
Off-chain · with the owner
Contract code
Full state and history
Your slice only
↓
⊞ One commitment (hash)
Bitcoin UTXOtens of bytes on-chain
Fig 02
The building blocks
RGB stands on three primitives.
Each solves one problem. Together they let you own and move an asset on Bitcoin without any contract data touching the chain.
01
Client-side validation
Each party validates only its own slice of history. There is no global consensus over contract data, and nothing is broadcast to the network.
You verify only the data you actually need.
02
Single-use seals
Every state transition is bound to a Bitcoin UTXO. Spending that UTXO closes the seal, once and only once. Bitcoin's own anti-double-spend rule enforces it.
A UTXO you can close exactly once.
03
The schema
A declarative template that defines what a contract is: its states, its rules, its transitions. Wallets run it locally on AluVM. It is never executed on-chain.
A contract class, not on-chain code.
The order matters. The schema defines what the contract is. Client-side validation keeps its data private. Single-use seals make every transition final.
Fig 03
Single-use seals
A promise you can keep once: define, commit, close.
A seal is a Bitcoin UTXO. Spending it publishes a commitment and closes the seal forever. This is the anti-double-spend mechanism, and it is exactly as strong as Bitcoin.
Step 1 · Define
UTXO A
unspent output you control
The seal points at this UTXO. It names where a future commitment will land.
→
Step 2 · Commit
Witness transaction
⊞ commitment (hash)
A transaction spends UTXO A and carries a hash of the new state.
→
Step 3 · Close
UTXO A
The output is spent. The seal is closed for good and cannot be reused.
To double-spend an RGB asset you would have to reverse a confirmed Bitcoin transaction. That means out-mining the entire Bitcoin network.
Fig 04
Where the asset lives
A history in your stash, pinned to a UTXO.
The asset is a chain of state transitions from genesis onward, held off-chain in your stash. Each step is assigned to a UTXO. Control the current UTXO and you control the asset.
Off-chain stash · validated client-side
Genesis
issued by contract
→
Transition 1
issuer to Alice
→
Transition 2
Alice to Carol
→
Current state
owned now
UTXO
UTXO
UTXO
UTXO (unspent)
Unspent means you are the current owner.
Fig 05
Alice sends to Bob
A transfer, step by step.
Bob names a UTXO. Alice assigns the asset to it, commits on-chain, and hands Bob the history. Bob checks it himself. The chain never learns what moved.
Alice
Bob
Alice
Stash
holds the full history
Owns UTXO A + keys
The current owner, sending the asset.
1
Bob issues an invoice. It defines a single-use seal on one of his UTXOs.
2
Alice builds a state transition. It closes her seal and assigns the asset to Bob's.
3
Alice commits on-chain. A witness transaction spends UTXO A and embeds the commitment, by Tapret or Opret.
4
Alice sends a consignment. It carries her validated stash plus the new state, passed off-chain.
5
Bob validates locally. He checks the whole history to genesis against the schema, then saves the stash.
Bob
Provides UTXO B
Saves stash
new owner of the asset
Verifies everything himself, trusting no one.
On the Bitcoin chain: ordinary transactions signed with Alice's keys. No visible relation to the RGB asset, and no analysis possible.
Fig 06
On-chain footprint
The chain sees a commitment, and nothing else.
Asset type, amount, and counterparty never leave your device. Only a hash is anchored, and one Bitcoin transaction can carry commitments for many contracts at once.
What the public chain sees
Asset typehidden
Amounthidden
Counterpartyhidden
⊞ A commitment (hash)visible
How the commitment is anchored
Tapret
Tucked into a Taproot output. Zero extra bytes on-chain.
Opret
Placed in an OP_RETURN output. Tens of bytes.
MPC tree
Batches many contracts' transitions under one commitment.
Thousands of transitions from different contracts fit inside a single Bitcoin transaction.
Fig 07
The commitment layer
One transaction, one commitment. No second story.
The whole system rests on a single rule: the witness transaction must provably contain exactly one commitment. If a sender could hide two, they could show two different histories to two different people. Deterministic Bitcoin Commitments remove the choice.
Witness transaction · outputs scanned in order
Only the first DBC-compatible output counts: the first output that is either Taproot or OP_RETURN. Everything after it is ignored by RGB validation, so there is nothing to choose between.
vout 0
P2WPKH
not DBC-compatible, skipped
the commitment
vout 1
Taproot → Tapret
first DBC-compatible output
vout 2
OP_RETURN
ignored: a Taproot output came first
vout 3
Change
ordinary output
Tapret
taproot · zero extra bytes
The commitment is tucked into the Taproot script tree as an extra leaf. On-chain it is indistinguishable from any other Taproot spend, and costs nothing in block space. Preferred where privacy matters.
Opret
op_return · tens of bytes
The commitment sits in plain sight inside an OP_RETURN. Simpler to implement and to audit, at the cost of a visible marker and a few tens of bytes of block space.
A transaction carries either a Tapret or an Opret, never both. The seal does not have to pick a scheme when it is created. The rule about the first applicable output decides it later, on its own.
Fig 08
Multi-protocol commitments
Many contracts share one hash, and see nothing of each other.
If only one commitment per transaction is allowed, how do several contracts settle at once? They are merkelized together. Each contract gets a deterministic leaf position, the empty leaves are filled with entropy, and the root becomes the single hash that goes on-chain.
MPC tree · width 8, three contracts
Where a contract lands
pos(cᵢ) = cᵢ mod (w − cofactor)
The position falls out of the ContractId itself, so nobody can place a contract where they like. The builder starts from the smallest tree wider than the number of contracts and tries each cofactor until every contract gets a distinct slot; if none does, the tree grows one level. A kind of small mining process.
The root is hashed once more, tagged in BIP-341 fashion, and that single 32-byte value is what Tapret or Opret carries. Thousands of transitions across unrelated contracts, one hash.
The entropy leaves are the privacy trick. A verifier of one contract receives only the Merkle path to its own leaf, so it cannot tell how many other contracts settled in the same transaction, or whether any did.
Fig 09
Anchors
The anchor is the proof that joins the two halves.
Off-chain data on one side, a hash in a Bitcoin transaction on the other. An anchor is the small bundle of proofs that lets a recipient walk from their own transition all the way to a confirmed output, and confirm the two are the same thing.
Client-side data
State transition
what actually moved
Transition bundle
all transitions of this contract in this transaction
The anchor
Witness txid
MPC Merkle proof
path, position, cofactor
DBC proof
Tapret path or Opret output
Travels with the consignment, off-chain
Bitcoin blockchain
Witness transaction
spends the seal, confirmed in a block
⊞ mpc::Commitment
Thirty-two bytes, secured by proof of work.
What the recipient's wallet checks, in order
1
Rebuild the bundle id
Hash the transitions received. This is the leaf content.
2
Walk the Merkle path
Recompute the root from the proof, then the tagged commitment.
3
Find the one output
Locate the first DBC-compatible output of the witness transaction.
4
Compare
If the two hashes match, the history is anchored. If not, reject.
This is the whole trust model in one sentence: the wallet believes the data because the proofs reduce to a hash that Bitcoin already confirmed: no server, no indexer, no committee.
Fig 10
The speed layer
For everyday volume, RGB rides Lightning.
An asset assigned to a UTXO inside a Lightning channel moves at Lightning speed. Transfers settle off-chain, instantly and for almost nothing. Bitcoin is touched only to open and close the channel.
Lightning channel · off-chain
Alice
node
Bob
node
Instant
Near-zero fee
High volume
Private
On-chain: open channel
many RGB transfers, off-chain
On-chain: close channel
Fig 11
What you can issue
Five schemas, live on Bitcoin today.
The RGB Protocol Association ships five production schemas as of v0.11.1. Each is a template with its own rules. An issuer picks one at genesis, and every recipient validates against it. Older names RGB-20, RGB-21, and RGB-25 live on as the underlying interfaces.
NIA
Non-inflatable asset
RGB-20 interface · fungible
Fixed-supply fungible token: ticker, name, precision, and a hard cap that can never grow. The schema behind stablecoins and capped tokens.
IFA
Inflatable fungible asset
fungible · re-issuable
A fungible token that allows secondary issuance. Inflate, burn, and link transitions let supply change under the contract’s own rules.
PFA
Issuer-approved fungible
fungible · permissioned
Every transfer must be signed off by the issuer. Built for regulated assets like tokenized company shares with legal transfer constraints.
UDA
Unique digital asset
RGB-21 interface · non-fungible
A single, non-fractionable NFT with an attached media file and preview. The simplest one-of-a-kind asset on Bitcoin.
CFA
Collectible fungible asset
RGB-25 interface · fungible
Media-rich collectibles that still divide and trade like fungible tokens. Editioned, collectible series.
All five are validated client-side and anchored the same way: off-chain data, one Bitcoin commitment. BitMask One supports RGB-20 issuance today.
Fig 12
Why it matters
Bitcoin security, without Bitcoin's constraints.
RGB keeps the security you want from Bitcoin and drops the parts that made assets impractical: public data, chain bloat, and a network that re-runs your contract.
On-chain contracts
RGB
Where state lives
On every node, public
Off-chain, with the owner
Who validates
The whole network
Only the parties involved
What Bitcoin stores
A separate chain
One commitment per transition
Privacy
Public by default
Private by default
Security
Its own consensus
Bitcoin proof of work
The takeaway
RGB is no longer an R&D bet. It is a matured protocol, and in August 2025 Tether announced it will issue USDT natively on Bitcoin through RGB.
Compiled from public RGB documentation (docs.rgb.info, rgb.info), Bitcoin Optech, and protocol reporting. RGB: client-side validation on Bitcoin. Concepts by Peter Todd and Giacomo Zucco, developed by Maxim Orlovsky and the LNP/BP Standards Association.
RGB gives Bitcoin wings. Build on it with BitMask.