# RGB Protocol on Bitcoin — History, Motivations, and Why v0.11.1

> **Sources (all authored by the rgb-protocol team / RGB Protocol Association):**
> - History: rgb-protocol team, April 2026 — https://rgbprotocol.org
> - Motivations: https://github.com/rgb-protocol/.github/blob/master/MOTIVATIONS.md
> - Technical comparison v0.11.1 vs v0.12: https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md (dated 2025-07-23)

---

## Part 1 — The History of RGB Protocol on Bitcoin

*Published by the rgb-protocol team, April 2026*

### The idea: Bitcoin as more than money

Bitcoin was designed to do one thing extremely well: transfer value between parties without trusting a third party. But from the early days of the ecosystem, developers began asking a broader question: could Bitcoin's security and decentralization be used to represent any kind of digital asset, not just bitcoin itself?

The first attempts, like Colored Coins and Mastercoin, tried to layer asset functionality on top of Bitcoin by embedding metadata in transactions. They worked, but came with significant tradeoffs: all asset data was visible on-chain, the blockchain grew with every transfer, and privacy was essentially nonexistent. A more fundamental approach was needed.

### Phase 1, 2013–2016: the theoretical foundation

In November 2013, Peter Todd published a post to the Bitcoin Development mailing list proposing a radical idea: validation does not need to happen on-chain. Bitcoin only needs to serve as a proof-of-publication system — a way to anchor commitments to a shared, immutable ledger. The actual validation of transactions could be done off-chain, by the parties involved in a transfer, using only the data relevant to them.

This concept, later formalized as **client-side validation**, became the theoretical foundation of RGB. In 2016, Peter Todd presented this model publicly at Scaling Bitcoin Milan, bringing the idea to a wider audience.

The privacy and scalability implications were profound: no one outside a transaction needs to know it happened, and the blockchain carries only a minimal cryptographic commitment, not the full asset history.

### Phase 2, 2017: RGB is born

In summer 2017, Blockchain Lab, led by Giacomo Zucco, was engaged to review all existing "colored coin" projects and define what an ideal asset protocol on Bitcoin would look like. Building on Peter Todd's client-side validation model, Zucco outlined a new approach — since miners were already unable to validate colored coin rules, client-side validation was not just possible but logical.

Working alongside developer Riccardo Casatta, the concept took shape. The name **RGB** was proposed by Mir Serena Liponi — a deliberate reference to the RGB color model and to Colored Coins, the earlier attempt RGB was conceptually succeeding.

### 2018: Lightning integration and the first prototype

In 2018, Giacomo Zucco presented RGB at the Building on Bitcoin conference in Lisbon, this time with a new dimension: merging RGB with the Lightning Network. The UX tradeoffs of client-side validation — an online receiver, additional backups — were closely parallel to those of Lightning, making the two protocols a natural fit.

Alekos Filini began building the first working prototype of RGB, turning the theoretical model into code.

### 2019–2022: building the foundations

In spring 2019, a broader group of companies committed resources to RGB development: Bitfinex, Bitrefill, Fulgur Ventures, and the Poseidon Group. Maxim Orlovsky took on the role of lead developer. A coordination group formed: John Carvalho (Bitrefill) as coordinator, Giacomo Zucco as ideator, Paolo Ardoino (Bitfinex) as primary funder.

Peter Todd, consulted during this period, described RGB as "the best thing to build on currently."

By end of 2020, Bitfinex and Fulgur Ventures paused funding. The project continued, self-funded by Orlovsky and his company Pandora Core. In 2022, Federico Tenga proposed switching to Taproot commitments — a significant technical improvement. Bitfinex and Fulgur Ventures renewed their interest and formed a dedicated full-time team at Bitfinex working on open source RGB development, with the goal of bringing the protocol to mainnet. This team developed rgb-lib (a wallet library for RGB integration) and the RGB Lightning Node.

### 2024–2025: two paths forward

By 2025, the development community faced a fork in the road.

**RGB Protocol on Bitcoin v0.11.1** was the natural continuation: fix existing issues, remove unused parts, simplify, increase test coverage, and deliver a working mainnet release. A significant number of projects — Iris Wallet, KaleidoSwap, LNFI, BitMask, Tiramisu Wallet, ThunderStack, Bitcoin Tribe — had already built on this version and were ready for mainnet.

**v0.12** was a proposal for a substantial rewrite introduced with limited prior discussion with the companies building on RGB. The builders and investors who had been working toward mainnet rejected this proposal as incomplete, untested, and incompatible with existing integrations. ([source: MOTIVATIONS.md](https://github.com/rgb-protocol/.github/blob/master/MOTIVATIONS.md))

In July 2025, a new GitHub organization **rgb-protocol** was created to provide a dedicated home for the completed work on v0.11.1, with a clear focus on stability, solid testing, and clear documentation.

### July 2025: mainnet

In July 2025, RGB Protocol on Bitcoin v0.11.1 reached mainnet. On the same day, products went live simultaneously: LNFI, ThunderStack, BitMask, Bitcoin Tribe, and Iris Wallet — demonstrating that the ecosystem was ready.

The same month, the **RGB Protocol Association** was founded, bringing together Bitfinex, Fulgur Ventures, Tether, and others. The Association was created to coordinate grants, funding, education, and communication around RGB Protocol on Bitcoin.

In August 2025, **Tether officially announced plans to launch USDT on RGB Protocol on Bitcoin** — the first Bitcoin-native stablecoin via client-side validation, without sidechains or bridges. Paolo Ardoino, CEO of Tether: *"Bitcoin deserves a stablecoin that feels truly native, lightweight, private, and scalable. With RGB, USD₮ gains a powerful new pathway on Bitcoin."* ([source: tether.io](https://tether.io/news/tether-to-launch-usdt-on-rgb-expanding-native-bitcoin-stablecoin-support/))

### Today: an active ecosystem

As of 2026, RGB Protocol on Bitcoin v0.11.1 is the production-ready version of the protocol, supported by the RGB Protocol Association. The rgb-protocol organization maintains the codebase at github.com/rgb-protocol, with regular contributions focused on Lightning Network optimization, USDT issuance readiness, and new protocol integrations including Ark.

---

## Part 2 — Why rgb-protocol Was Created (MOTIVATIONS)

*Published by the rgb-protocol team on GitHub*

Version 0.11.1 was started with the goal of fixing existing issues, removing unused parts, simplifying when possible, and increasing test coverage of core components and real-world scenarios.

Version 0.12 is a substantial rewrite — with ambitious goals and different priorities — introduced without sufficient prior discussion with the companies building on RGB. A decision to join efforts and focus on v0.11.1 was attempted, but collaboration turned out to be harder than expected. ([source: MOTIVATIONS.md](https://github.com/rgb-protocol/.github/blob/master/MOTIVATIONS.md))

The new **rgb-protocol** organization was created to provide access to the completed work on v0.11.1, focusing on a working version of RGB that is:
- Simpler and well-tested
- Understood by a larger portion of the developer community
- Well-documented (canonical documentation at docs.rgb.info)

The emphasis is on **stability, simplicity, solid testing, and clear documentation**. Projects like rgb-lib already use it and strive to make adoption smooth. Higher-level projects like RGB Lightning Node (using rgb-lib internally) are actively maintained.

---

## Part 3 — v0.11.1 vs v0.12: Technical Analysis

*Published 2025-07-23 by the rgb-protocol team ([source: WHY_v0.11.1.md](https://github.com/rgb-protocol/.github/blob/master/WHY_v0.11.1.md))*

### Why v0.11.1 and not v0.12 — the technical reasons

#### zk-STARKy RGB (v0.12 claim)
- Only preparatory work has been done; actual ZK integration still requires substantial development
- No evidence yet that ZK integration is possible without breaking changes to the protocol
- Cannot be considered a feature at this stage — it is a marketing narrative, not a usable capability

#### Protocol simplification (v0.12 claim)
- Large portions of consensus-critical code were moved or removed without technical justification
- Essential features critical for schema expressiveness and privacy — multiple transitions per contract, concealed transitions — were removed in v0.12
- v0.11.1 will become smaller than v0.12 after planned unused code removal
- v0.12 involved an extensive rewrite of core logic without a sufficient suite of integration tests

#### Better auditability (v0.12 claim)
- v0.12 is harder to audit: consensus and validation logic are now spread across multiple repositories
- v0.11.1 centralizes critical logic, which is more conducive to rigorous review

#### Better performance (v0.12 claim)
- No benchmarks or technical metrics have been provided. The claim is unsubstantiated.

#### Better developer experience (v0.12 claim)
- v0.12 introduced incompatible changes, forcing existing integrations to be largely rewritten
- rgb-lib (built on v0.11.1) already provides fast paths to adoption for developers who don't want to work directly with low-level RGB libraries, including support for languages other than Rust

#### Features also present in v0.11.1
The following v0.12 claims describe features that are also implemented in v0.11.1:
- Seal unification ✓
- Removal of Pedersen commitments and Bulletproofs ✓
- Removed interfaces and implementations ✓
- Single-blockchain protocols ✓
- Multiple-asset contracts (fully supported via schema design) ✓
- Re-org support ✓
- Payment scripts (same flows possible without custom scripts) ✓

### Addressing common misconceptions about v0.11.1

**"v0.11.1 includes heavy modifications to the consensus"**
The changes are incremental and targeted: missing validation checks for known attack vectors, a reworked transition bundle design enhancing privacy, and internal improvements like seal unification. Not a rewrite.

**"v0.12 has better documentation"**
v0.11.1 has consolidated protocol documentation at docs.rgb.info — a single, accessible canonical source.

**"All assets issued on v0.11.1 are centralized"**
False. While asset issuance is centralized (as in v0.12), holders are anonymous post-issuance: the issuer has no knowledge of asset holders and no control over asset transfers after initial distribution.

**"All existing RGB-LN products hold users' private keys"**
False. v0.11.1 products do not require, nor suggest, holding user private keys. KaleidoSwap already allows RGB-LN interactions via non-custodial setups using a locally running RGB Lightning node.

**"v0.12 uses fewer resources"**
No benchmarks or data support this. v0.11.1 has not yet been optimized and many known improvements are already planned.

**"v0.12 has no known bugs"**
Misleading. Critical tests in v0.12 are disabled (`#[ignore]`), including:
- `ln_transfers` (Lightning-style RGB transfers)
- `collaborative_transfer` (2-wallet transfers)
- `mainnet_wlt_receiving_test_asset`
- UDA support tests

**"v0.12 is more stable and production-ready"**
False. As of July 2025, only rgb-core has been declared ready. The rest of the stack remains without production-ready releases.

**"Smart contracting capabilities were removed in v0.11.1"**
False. This claim has not been substantiated.

### Lightning Network compatibility

Despite being a core use case of RGB, v0.12 has not been tested or integrated on Lightning. Critical LN-related integration tests are currently ignored in the v0.12 test suite. No implementations of RGB-over-LN are known to use v0.12.

In contrast, v0.11.1 is already integrated in the RGB Lightning Node (RLN) and is actively used by KaleidoSwap, LNFI, and ThunderStack in real-world scenarios.

### Governance concerns about RGB-WG

v0.12 was developed as a major rewrite without prior discussion with the companies funding or building on RGB. Contributors have had PRs rewritten without logical changes — apparently to preserve code ownership. This environment discourages collaboration and weakens review processes. ([source: MOTIVATIONS.md](https://github.com/rgb-protocol/.github/blob/master/MOTIVATIONS.md))

RGB is not a personal project. The rgb-protocol organization operates with open collaboration, regular developer calls, and contributions from multiple companies.

---

## A note on naming

Three things share similar names and are frequently confused:

- **RGB color model** — Red, Green, Blue. Displays. Completely unrelated to this protocol.
- **RGB++** — a separate protocol on the Nervos/CKB blockchain. Different team, different architecture, no relation.
- **RGB v0.12** — a separate development branch by the RGB-WG organization (rgb.tech). Not production-ready; not supported by the RGB Protocol Association.
- **RGB Protocol on Bitcoin** — this protocol. rgb.info. v0.11.1. Production since July 2025. Supported by the RGB Protocol Association.

---

*RGB Protocol Association — rgbprotocol.org · rgb.info · docs.rgb.info · github.com/rgb-protocol · github.com/RGB-Tools*