RGB Protocol

RGB Protocol is a smart contract system built on Bitcoin that enables complex programmable assets and contracts without requiring a separate blockchain. OMXUS uses RGB to anchor identity records and governance decisions to Bitcoin's security model, providing the cryptographic backbone for Decentralized Identifiers, vote tallying, and sybil-resistant identity.

What is RGB?

RGB is a "client-side validation" protocol that fundamentally rethinks how smart contracts work. Rather than replicating every piece of contract state across every node in a global network -- the model pioneered by Ethereum -- RGB keeps contract data on the devices of the parties who actually care about it, while anchoring cryptographic commitments to Bitcoin transactions.

Core properties:

• Stores contract data off-chain on users' own devices
• Anchors cryptographic commitments to Bitcoin transactions
• Inherits Bitcoin's security, censorship resistance, and decentralization
• Enables Turing-complete smart contracts without any Bitcoin protocol changes
• Achieves privacy by default -- only parties to a contract see its state

The Name

RGB originally stood for "Really Good Bitcoin," coined by Giacomo Zucco in 2018 when the project emerged from Peter Todd's earlier work on client-side validation and single-use seals. As the protocol matured beyond that initial scope, the acronym was dropped and RGB became the protocol's proper name.

History and Development

The intellectual lineage of RGB traces through several key innovations:

Year	Milestone	Contributor
2016	Client-side validation concept published	Peter Todd
2016	Single-use seals concept	Peter Todd
2018	RGB protocol proposal	Giacomo Zucco, BHB Network
2019	LNP/BP Standards Association founded	Maxim Orlovsky, community
2021	RGB v0.8 -- first functional release	LNP/BP Standards Association
2023	RGB v0.10 -- stable release with Lightning integration	LNP/BP Standards Association
2024	RGB v0.11 -- improved tooling, wallet support	LNP/BP Standards Association
2025	Growing ecosystem of wallets and applications	Multiple contributors

How It Works

Traditional Smart Contracts: The Ethereum Model

Ethereum and similar platforms use a global state machine model:

Contract Code + State
        |
        v
[Blockchain] <-- Every node stores everything
        |            Global consensus on all state
        v
All nodes validate all transactions

This approach has significant drawbacks:

• Scalability limits: Every node processes every transaction, creating a throughput ceiling. Ethereum processes roughly 15-30 transactions per second natively.
• Privacy failure: All contract state is public by default. Token balances, NFT ownership, DeFi positions -- all visible to anyone.
• Fee volatility: During network congestion, gas fees can spike to hundreds of dollars per transaction, making the network unusable for ordinary users.
• Separate security assumptions: Ethereum's security depends on its own validator set, not Bitcoin's vastly larger proof-of-work investment.
• State bloat: The global state grows continuously, making it increasingly expensive to run full nodes.

The RGB Model: Client-Side Validation

RGB inverts the architecture:

Contract Code + State
        |
        v
[Your Device] <-- Only you store your data
        |
        v
[Commitment Hash]
        |
        v
[Bitcoin Transaction] <-- Only a small commitment on-chain

This yields:

• Unlimited scalability: No global state to synchronize. Throughput is limited only by Bitcoin's transaction capacity for anchoring, and multiple RGB state transitions can share a single Bitcoin anchor.
• Privacy by default: Contract state lives on participant devices. Third parties cannot observe contract activity.
• Bitcoin-grade security: Commitments are anchored to the most computationally secure blockchain in existence.
• Minimal fees: On-chain footprint is tiny -- just a hash commitment embedded in a Bitcoin transaction.
• No state bloat: Bitcoin's blockchain is not burdened with contract data.

Key Concepts

Client-Side Validation

The foundational insight of RGB is that not everyone needs to validate everything. In traditional finance, your bank validates your transactions; your neighbor's bank validates theirs. Neither needs to see the other's data.

Client-side validation applies this principle to smart contracts:

• Only parties with an interest in a contract validate its state transitions
• You verify the contracts you hold assets in or interact with
• Others have no need -- and no ability -- to see your contract state
• The validation burden is distributed proportionally to participation

This is secured because every state transition is ultimately anchored to a Bitcoin UTXO. If someone presents you with a fraudulent state history, the Bitcoin anchoring chain will not verify.

Single-Use Seals

A single-use seal is a cryptographic commitment that can only be "opened" once -- analogous to a physical wax seal on an envelope. Once broken, it cannot be resealed.

In RGB, Bitcoin UTXOs serve as single-use seals:

• A contract state is committed to a specific Bitcoin UTXO
• Spending that UTXO "opens" the seal, enabling exactly one state transition
• The new state is committed to a new UTXO, creating a new seal
• This chain of seals creates an unforgeable, linear history

The elegance is that Bitcoin's consensus mechanism -- which already prevents double-spending of UTXOs -- automatically prevents double-spending of RGB contract states. No additional consensus mechanism is required.

State Transitions

Contract state changes through a defined sequence:

1. Current state exists, committed to a Bitcoin UTXO
2. A transition is constructed according to contract logic (the schema)
3. The new state is determined by the transition rules
4. A commitment to the new state is embedded in a new Bitcoin transaction
5. The old UTXO is spent (opening the seal), and the new state is committed to a new UTXO

Schemas and Interfaces

RGB uses schemas to define contract types and interfaces to define how users interact with them:

• A schema is like a class definition -- it specifies what states and transitions a contract can have
• An interface is like an API -- it specifies how external software interacts with a contract
• Standard interfaces (like RGB20 for fungible tokens, RGB21 for NFTs) enable interoperability
• Custom schemas enable arbitrary contract logic

Comparison: RGB vs Ethereum Tokens

Feature	Ethereum (ERC-20/721)	RGB (RGB20/21)
Data storage	On-chain, global	Off-chain, client-side
Privacy	None (all public)	Full (only parties see state)
Scalability	~15-30 TPS native	Theoretically unlimited
Security model	Ethereum PoS validators	Bitcoin PoW miners
Fee structure	Gas fees, volatile	Minimal Bitcoin fees for anchoring
Smart contract capability	Turing-complete (Solidity)	Turing-complete (AluVM)
Token issuance	Deploy contract to chain	Create schema, issue off-chain
Transfer mechanism	On-chain transaction	Off-chain state transition + anchor
Ecosystem maturity	Large (since 2015)	Growing (since 2019)
Developer tooling	Extensive	Developing
Lightning Network integration	No native support	Native support via LNP
State bloat impact	Grows Ethereum state	No impact on Bitcoin state

OMXUS Applications

Identity Anchoring

Human Existence Records (HERs) are anchored via RGB:

[Three Vouching Attestations]
        |
        v
[Merkle Tree of Attestations]
        |
        v
[Commitment in RGB Contract]
        |
        v
[Bitcoin Transaction]

This creates:

• Timestamped proof of identity creation -- provably existed at a specific point in time
• Immutable record of the vouching chain -- who vouched for whom, and when
• Verifiable without trusted third party -- anyone can check the chain
• Bitcoin-secured integrity -- tampering would require rewriting Bitcoin's blockchain

The RGB schema for OMXUS identity includes:

Schema: OMXUSIdentity
  - Genesis: Initial identity creation
  - Transitions:
    - AddVoucher: Record vouching attestation
    - UpdateKeys: Key rotation
    - AddCheckpoint: Periodic anchoring
    - Revoke: Emergency identity revocation
  - State:
    - DID: Decentralized identifier
    - VoucherList: List of voucher DIDs
    - CreatedAt: Timestamp
    - Checkpoints: Anchoring history
    - KeyHistory: Record of key rotations

Vote Tallies

Governance decisions are anchored to Bitcoin through RGB:

[Individual Encrypted Votes]
        |
        v
[Aggregated Tallies by Region]
        |
        v
[Merkle Tree of Tallies]
        |
        v
[RGB Commitment]
        |
        v
[Bitcoin Transaction]

Properties:

• Individual votes remain private -- encrypted with voter's keys
• Aggregate results are public -- committed to an immutable record
• Tampering is detectable -- any change breaks the Merkle proof
• Historical record is permanent -- cannot be erased or altered
• Auditability -- any participant can verify the commitment chain

Epoch Checkpoints

OMXUS creates periodic system-state snapshots anchored to Bitcoin:

• Network state captured at defined intervals (e.g., weekly)
• Enables verification starting from any checkpoint rather than replaying entire history
• Creates synchronization points for new nodes joining the network
• Allows safe pruning of old detailed data while retaining cryptographic proof

Contract-Based Governance

Beyond identity and voting, RGB enables OMXUS to implement:

• Community resource allocation contracts -- transparently track how collective funds are deployed
• Dispute resolution records -- ViewSwap outcomes and mediation results anchored permanently
• Infrastructure agreements -- mesh node commitments and service-level contracts
• Economic flows -- tracking the redistribution mechanisms with full auditability

Technical Architecture

+-------------------------+
|    OMXUS Applications   |  <-- Identity, Voting, Contracts
+-------------------------+
            |
+-------------------------+
|    RGB Smart Contracts  |  <-- Schema logic, state transitions
+-------------------------+
            |
+-------------------------+
|    AluVM Execution      |  <-- Virtual machine for contract code
+-------------------------+
            |
+-------------------------+
|    RGB State (Client)   |  <-- Off-chain, held by participants
+-------------------------+
            |
+-------------------------+
|    Commitment Layer     |  <-- Merkle trees, hash commitments
+-------------------------+
            |
+-------------------------+
|    Bitcoin / Lightning  |  <-- On-chain anchoring, fast payments
+-------------------------+

AluVM

RGB uses AluVM (Algorithmic Logic Unit Virtual Machine) as its execution environment:

• Register-based architecture (unlike Ethereum's stack-based EVM)
• Designed for formal verification of contract correctness
• Deterministic execution -- same inputs always produce same outputs
• No unbounded loops -- contracts always terminate
• Efficient for the kinds of validation logic RGB contracts require

Lightning Network Integration

RGB state transitions can be routed through the Lightning Network, enabling:

• Instant transfers -- sub-second token transfers
• Microscopic fees -- fractions of a cent
• High throughput -- millions of transfers per second theoretically
• Offline finality -- channel state is final between parties

This is critical for OMXUS because vote submission and emergency alerts require near-instant confirmation.

Why Bitcoin?

Security

Bitcoin provides the highest security guarantee of any blockchain:

• Longest continuous operation -- running uninterrupted since January 3, 2009
• Highest hash rate -- over 600 EH/s as of 2025, representing billions of dollars in mining infrastructure
• Most decentralized -- tens of thousands of full nodes across every continent
• Battle-tested economics -- survived every attack vector attempted over 16+ years
• Immutability track record -- no successful 51% attack despite enormous financial incentive

Neutrality

Bitcoin is uniquely suited as a foundation for democratic infrastructure because:

• Not controlled by any corporation, government, or individual
• Cannot be shut down without shutting down the global internet
• Censorship-resistant -- any valid transaction will eventually be mined
• Permissionless -- no authorization required to use it
• Politically neutral -- used across the entire political and geographic spectrum

Simplicity of Integration

RGB leverages Bitcoin without modifying it:

• No Bitcoin protocol changes required -- works with Bitcoin as it exists today
• Uses existing Bitcoin features (transactions, UTXOs, OP_RETURN, Taproot)
• Inherits all security properties automatically
• No new consensus mechanisms to trust or validate
• Protocol upgrades are independent of Bitcoin's development cycle

Current Status

RGB is under active development with growing adoption:

Component	Status	Notes
RGB Core	v0.11 (stable)	Core protocol library
RGB Standard Library	Active	Common schemas and interfaces
RGB20 (Fungible Tokens)	Stable	Equivalent to ERC-20
RGB21 (NFTs)	Stable	Equivalent to ERC-721
AluVM	Active	Contract execution engine
Lightning integration	Active	Via LNP (Lightning Network Protocol)
Wallets (Iris, MyCitadel, BitMask)	Active	End-user applications
LNP/BP Standards Association	Active	Coordinates development
OMXUS integration	Design phase	Identity and voting schemas

Challenges

Ecosystem Size

RGB's ecosystem is smaller than Ethereum's:

• Fewer developers (hundreds vs tens of thousands)
• Fewer tools and libraries
• Less documentation and educational material
• Smaller community for troubleshooting

However, this is changing rapidly, and OMXUS contributes to ecosystem growth by building applications and tooling that others can use.

Conceptual Complexity

Client-side validation requires a mental model shift:

• Users must maintain their own state data (or delegate to trusted storage)
• Verification requires access to the state history, not just a blockchain query
• Backup and recovery are more important -- losing your state data can mean losing access to contracts
• OMXUS handles this through NFC ring storage, IPFS replication, and mesh network distribution

Interoperability

Cross-ecosystem interaction remains limited:

• Not directly compatible with Ethereum contracts or tokens
• Bridges between RGB and other systems are in early development
• Standards are still evolving, meaning some interfaces may change
• OMXUS mitigates this by being self-contained -- it does not depend on Ethereum or other chains

See Also

• Technical Architecture
• Decentralized Identifiers
• Sybil Resistance
• Voting
• Lightning Network
• Mesh Networks
• Main Page