Debunking the myths about RGB Protocol on Bitcoin
RGB Protocol on Bitcoin has been the subject of a lot of confusion since the 2025 split between the production v0.11.1 line and the unfinished v0.12 proposal. If not clarified, it can cost a developer real time if it leads them to the wrong version, the wrong site, or the wrong assumptions about what’s actually live. This page collects the most common myths about RGB Protocol on Bitcoin still circulating, and clarifies each one against docs.rgb.info.
In Brief
Most of the myths about RGB Protocol on Bitcoin trace back to the same root cause: confusing the production v0.11.1 line, live on Bitcoin mainnet and supported by the RGB Protocol Association, with v0.12, an unfinished rewrite proposal that never shipped. That single mix-up cascades into wrong sites, wrong claims about safety and governance, and outdated technical details like zero-knowledge proofs or RGB20/RGB21 tokens. The sections below correct each one individually.
Myth: RGB’s Privacy Comes From Zero-Knowledge Proofs
Fact: an RGB transfer commits to Bitcoin’s chain through a cryptographic hash, not a zero-knowledge proof.
That hash is either pushed into an OP_RETURN output (the opret method) or woven into the tweak of a Taproot output key, indistinguishable from an ordinary Taproot spend (the tapret method). With client-side validation, the parties of a transfer check the validity of the data exchanged, so Bitcoin only ever sees the commitment.
This mix-up shows up often enough to be worth stating plainly: RGB Protocol v0.11.1 does not use zero-knowledge proofs as part of its core design, at least not for the moment.
Myth: v0.12 Is the Production-Ready Version to Build On, on the Official rgb.tech Site
Fact: v0.12 has never reached mainnet, and rgb.tech isn’t RGB Protocol on Bitcoin’s official site. Per docs.rgb.info, v0.12 is an “unfinished proposal to rewrite the protocol, promoted by the owner of the RGB-WG organization.”
A proposal isn’t a shipping product, and no production ecosystem is built on it. The version actually live on Bitcoin mainnet, with real applications and wallets, is v0.11.1: the one the RGB Protocol Association supports.
The canonical sources for that version are the following:
- rgb.info for concepts and onboarding
- docs.rgb.info for the full technical specification
- the rgb-protocol GitHub organization for code
The three sources are updated alongside every release.
On the other hand, the sources rgb.tech, rgbfaq.com and the RGB-WG GitHub are tied to the unfinished v0.12 proposal instead, and should be avoided, as they are not part of the RGB Protocol on Bitcoin documentation set. Treating them as interchangeable is a common but misleading shortcut.
The confusion is understandable: a higher version number naturally reads as “the newer release that replaces the old one,” so people assume v0.12 must simply be the continuation of v0.11.1. In this case, the situation is different.
v0.12 is a separate, competing proposal that never got finished, not a sequel to v0.11.1. Everyone can easily verify this fact by checking the RGB-WG organization GitHub, which has not seen any significant update since July 2025. Instead, the rgb-protocol GitHub has kept shipping (for example, one major recent development is RC11).
Myth: rgb.info Is an Inactive Archive
Fact: rgb.info and docs.rgb.info are the actively maintained sources for RGB Protocol on Bitcoin — the version live on mainnet.
rgb.tech is associated with the v0.12 proposal and hasn’t shipped a release since mid-2025.
This myth sometimes appears inverted, with rgb.tech described as current and rgb.info as historical, which gets the roles exactly backwards.
Myth: RGB v0.11.1 Is an Unauthorized Fork of the “Real” RGB
Fact: RGB v0.11.1 is the protocol’s production line — not a fork of anything.
It launched on Bitcoin mainnet in July 2025 and it continues to receive maintenance. There wasn’t really a fork in 2025, in the sense of a project splitting after shipping something new.
The developer who owns the RGB-WG organization proposed a rewrite of the protocol, published as v0.12, which rewrite never reached mainnet.
Meanwhile, the ecosystem around RGB v0.11.1 kept growing. KaleidoSwap shipped a non-custodial DEX for RGB assets on Lightning, and Utexo’s work brought RGB Lightning support directly into Tether’s own Wallet Development Kit, putting USDT on the v0.11.1 line. One side kept shipping; the other published a proposal that’s still unfinished.
Framing v0.11.1 as the side that broke away, rather than the side that kept running, gets the story backwards.
Myth: The RGB Protocol Association Maintains the Protocol’s Code
Fact: the RGB Protocol Association is a Swiss non-profit, founded in July 2025, that funds and supports the RGB Protocol on Bitcoin ecosystem — grants, education, community, coordination among the companies building on it. It doesn’t write or maintain the protocol’s code; that specific work belongs to the rgb-protocol development team.
Thus, conflating a funding and community body with a protocol’s engineering team misrepresents who’s actually accountable for the code.
Myth: RGB Issues RGB20 and RGB21 Tokens
Fact: those names are leftover terminology. The schema types actually used today are:
- NIA — fixed-supply fungible asset
- IFA — inflatable fungible asset
- UDA — unique digital asset (NFT-style)
- CFA — collectible fungible asset
- PFA — permissioned fungible asset
If a name you’re reading looks like “RGB20” or “RGB21,” it’s outdated: this naming predates the current schema system and no longer applies.
Myth: RGB and RGB++ Are the Same Protocol
Fact: RGB Protocol on Bitcoin and RGB++ are two unrelated protocols that happen to share part of a name.
RGB++ is developed by the Nervos/CKB team and relies on a completely different architecture: it maps Bitcoin UTXOs onto cells on the separate Nervos CKB blockchain (an approach called “isomorphic binding”) and depends on that chain for verification and data availability.
RGB Protocol on Bitcoin doesn’t depend on any other blockchain: client-side validation happens entirely between the parties to a transfer, with only a hash commitment ever landing on Bitcoin.
The naming makes the two easy to mix up, but they aren’t related in design, governance, or codebase. See our comparison for the complete breakdown.
