RGB Protocol on Bitcoin, Explained From the Start: Federico Tenga at Plan ₿ Forum 2022
This article is based on the talk “RGB Protocol: Asset Issuance on Bitcoin and Lightning Network,” given by Federico Tenga (Bitfinex team) at Plan ₿ Forum 2022 in Lugano.
Before RGB Protocol on Bitcoin reached mainnet, before v0.11.1, before Tether chose it for USDT, there was this talk. In 2022, Federico Tenga stood in front of a room in Lugano and explained, from first principles, why RGB exists at all: why smart contracts don’t have to run on a global network to be trustworthy, why Bitcoin is the best place to anchor that trust, and how a single UTXO can carry an asset without ever touching the chain until someone actually wants to move it.
Note: RGB Protocol on Bitcoin (rgb.info, v0.11.1) is the production-ready protocol supported by the RGB Protocol Association. It is distinct from RGB-WG (rgb.tech) and from RGB++, a separate protocol on the CKB chain by Nervos.
Editorial note (2026): this talk is archival footage from 2022, republished for its historical and technical value. The core design it describes, including client-side validation, single-use seals, and Bitcoin as a commitment layer, is still exactly how RGB Protocol on Bitcoin works today. A few specifics have since moved on: the schemas Federico calls RGB20 and RGB21 are the ancestors of today’s NIA, IFA, UDA, CFA, and PFA schemas (see the full list in the RGB glossary); Iris Wallet has grown well beyond the Android-only testnet app shown here, as documented in the current RGB wallets ecosystem; and RGB on Lightning, still work in progress at the time of the talk, is now under active development, tracked on the RGB Lightning Network roadmap. Maxim Orlovsky, credited here as RGB’s lead developer at the time, later continued a separate codebase (RGB-WG, v0.12), distinct from the v0.11.1 protocol maintained today. See the full history of RGB Protocol on Bitcoin and why v0.11.1, not v0.12 for the complete story.
In Brief
- RGB Protocol on Bitcoin uses client-side validation: only the parties to a contract execute and validate it, instead of an entire network re-running the same code
- Assets are assigned to a Bitcoin UTXO acting as a single-use seal (a concept by Peter Todd); proving ownership of the asset means proving ownership of the UTXO, by spending it
- Bitcoin only ever sees a commitment hash, via OP_RETURN (opret) or Taproot (tapret), never the contents of the transfer
- Issuance is free: creating a new asset is not an on-chain event, and the first cost is paid only when the asset is first transferred
- RGB was built with privacy in mind from the start: blinded UTXOs hide who a payment is going to, and Bulletproofs hide transferred amounts from later validators
- Transaction batching lets a single Bitcoin transaction settle an arbitrary number of RGB transfers, making the marginal cost of each one close to zero
- RGB on Lightning was already being designed in 2022, built on the same principle: a channel update is just another place to commit a state transition
Why Does RGB Run Contracts Client-Side Instead of on a Global Network?
Federico opened not with RGB, but with the term “smart contract” itself, coined by Nick Szabo in 1994, long before blockchains existed, to describe “a computerized transaction protocol that executes the terms of a contract.” Bitcoin’s own scripting language fit that definition from day one in 2009. Ethereum later popularized a narrower reading of the term: code pushed to a blockchain and redundantly re-executed by every node in a global consensus network.
The global-execution model has a real advantage: deploying even complex contracts is easy, because the entire network absorbs the complexity. But Federico laid out three structural costs.
- No scalability without sacrificing decentralization. If everyone must validate the same code, the amount of code the network can run is capped by what an ordinary computer can handle. The moment a supercomputer becomes necessary to keep up, most people can no longer participate, and decentralization is gone.
- No privacy. Every observer of the chain sees every contract’s execution, whether or not they’re a party to it.
- No easy upgrades. Once a network is genuinely decentralized, made up of people who don’t know each other and are mostly anonymous, getting broad agreement to change the rules becomes very hard.
The alternative Federico proposed: contracts that run only on the devices of the people actually involved, the founding idea behind client-side validation. A wallet only validates the contracts relevant to its own activity, not the 99.999% of a network’s transactions that have nothing to do with it.
He grounded the idea in something older than any blockchain: English property law. Until 1998, registering a real estate transaction in England’s central land registry wasn’t compulsory, and even today, about 15% of English land remains unregistered. Buyers of unregistered property don’t check a central database; they check a paper chain of title deeds going back roughly 15 years, confirming an unbroken line of ownership and that any past mortgages were paid off. Only the parties to each sale ever need to see the chain of title, and no registry’s permission is required to transact, but the process demands more manual verification work than a central registry would.
RGB’s proposal: keep those same properties, but upgrade the process with technology. Standardize the validation logic so a computer runs it instead of a human, and commit each transfer to a public ledger to prevent double-spending, without ever putting the transfer’s contents on that ledger. The full mechanics of how this works are laid out in how RGB Protocol on Bitcoin works.
How Does Bitcoin Work as RGB’s Commitment Layer?
In RGB’s asset issuance model, the main use case Federico focused on, each token is allocated to an existing Bitcoin UTXO, which acts as a single-use seal, a concept promoted by Peter Todd (in the room that day). Moving the token means proving ownership of the UTXO, by spending it. Spending it also guarantees the owner can’t move the same token twice, because Bitcoin itself already guarantees a UTXO can’t be double-spent.
The mechanics: spending the UTXO creates a Bitcoin transaction that carries a commitment, a hash of the transfer’s contents (specifically, the root of a Merkle tree combining multiple commitments, since multiple transfers can be committed at once). Federico described the two ways RGB implements the commitment.
- Opret: the hash goes in the first OP_RETURN output. Less elegant, but simpler to implement for wallet developers.
- Tapret: the hash is embedded in the Taproot output’s script tree. More elegant, and it makes the transaction indistinguishable from an ordinary Bitcoin payment, with no way to even suspect it’s carrying an RGB transfer.
Both options were kept, precisely to give wallet developers a choice between simplicity and stealth.
Federico illustrated why Bitcoin, and not, say, the front page of the New York Times, is the right place for this commitment: printing a hash in a newspaper would require trusting an editor not to tamper with it, wouldn’t scale as more users needed their own “spot,” and could be censored or corrupted at the editor’s discretion. Bitcoin removes all three problems, since only the UTXO’s owner can ever produce the transaction that spends it, so no third party can interfere with or fake a commitment.
Bitcoin is also the choice over Ethereum for a simple reason: RGB doesn’t need programmability on-chain at all. The protocol only needs to record a hash as securely as possible. Turing completeness and on-chain smart-contract flexibility are irrelevant to that job, so RGB picks the ledger that maximizes security, not the one with the most on-chain features.
One consequence Federico highlighted: issuing an asset costs nothing on-chain. Creating a contract, with a name, ticker, max supply, and first owner UTXO, doesn’t require a Bitcoin transaction; the genesis contract operation exists only client-side. The first fee is paid only when the asset is actually moved for the first time, via a state transition. Issuing a token on Ethereum, by contrast, requires paying gas up front regardless of whether anyone ever buys it.
Because every recipient must validate the full history of an asset back to its genesis contract, and only the chain of transfers relevant to what they received rather than the entire network’s activity, RGB gets both better scalability, since a recipient validates only what they need, and better privacy, since nobody sees more of the asset’s history than the part they were involved in.
What Privacy and Scalability Features Did RGB Build in from Day One?
Three features stood out in the 2022 design.
- Blinded UTXOs. A payment doesn’t reference a UTXO directly; it references the hash of the UTXO concatenated with a random number. The sender has no idea which UTXO they’re actually paying, and therefore no way to monitor what the recipient does with those funds afterward.
- Bulletproofs. A cryptographic mechanism that keeps the actual token amounts hidden throughout the chain of transfers, even from later owners who must validate that history to confirm the asset is genuine. They can confirm validity without learning how much moved at each step.
- Transaction batching. An arbitrary number of RGB transfers, even across different assets, can be committed inside a single Bitcoin transaction, as long as the assets sit on the same UTXO, using the same multi-protocol commitment mechanism described above. Federico’s example: an exchange processing a thousand withdrawals at once, all settled in one Bitcoin transaction with the fee of a single input/output payment, pushing the marginal cost of each transfer toward zero.
As Federico put it, with an ordinary Bitcoin address the sender can still watch when the recipient eventually moves the coins. With a blinded UTXO, that visibility disappears:
“I have no way to monitor future activity of the people I’m paying.”
How Does RGB Work with the Lightning Network, and Where Are the Limits?
Federico described RGB-on-Lightning, still under development at the time of the talk and now tracked on the RGB Lightning Network roadmap and built as the RGB Lightning Node, as a natural extension of the same idea: a channel update can commit a new RGB balance between two parties, and the update may or may not ever be settled on-chain. The current state of this integration is documented in RGB Protocol on Bitcoin and the Lightning Network.
The limitation he flagged directly: Lightning is built on an assumption of fungibility, treating everything inside a channel as interchangeable with everything in every other channel. Fungible RGB tokens fit that model. Non-fungible tokens structurally don’t, since a channel can’t treat unique assets as interchangeable balance.
A second limitation: since asset-specific channels can’t reuse existing Bitcoin liquidity, only sufficiently popular assets are likely to develop a routing network comparable to Bitcoin’s own. Smaller or less popular assets, Federico predicted, would more likely end up in a hub-and-spoke model with a few centralized routing nodes. He also dismissed one commonly proposed workaround, routing an asset payment by swapping it to Bitcoin, routing the Bitcoin, then swapping back, as unlikely to work well in practice, since an asset too illiquid to have a direct route to a counterparty is also too illiquid to offer a decent spread on two separate conversions.
Asked in Q&A whether RGB information could travel over Lightning’s existing gossip protocol, Federico confirmed it: gossip messages can carry extra metadata that non-RGB nodes don’t need to understand, but will still propagate on behalf of the nodes that do. Full Lightning Network compatibility details are in the technical docs. Critically, RGB adds no extra liveness or backup requirements beyond what Lightning already demands. An RGB backup isn’t “toxic” the way an old Lightning channel state is: losing it is a privacy problem, not a path to losing funds via a penalty transaction.
How Does RGB Compare to Taproot Assets?
Asked directly to compare RGB to Taproot Assets, which had launched earlier that year, Federico noted the two protocols share much the same underlying trade-offs; the difference is mostly implementation, plus timing, since RGB had been in development for years and already had working, if experimental, products before Taproot Assets was even announced.
The distinction he drew wasn’t technical so much as organizational. Taproot Assets, in his view, is primarily a Lightning Labs project built around Lightning Labs’ business goals, which he considered a perfectly reasonable approach. RGB, by contrast, was a community effort from the start, with multiple companies and many independent contributors, the same multi-company model that today includes the RGB Protocol Association and the wider RGB ecosystem. His read: the community model made RGB likely to end up as the more flexible protocol across a wider range of use cases, while Taproot Assets would likely be more tightly optimized for one company’s roadmap.
What Did the RGB Ecosystem Look Like in 2022?
By the time of this talk, Federico counted a small but real ecosystem already forming around RGB.
| Company / Project | Role in 2022 |
|---|---|
| Bitfinex | Federico’s own team, building RGB tooling and Iris Wallet |
| Diba | US company building NFTs on Bitcoin via RGB |
| Fulgur Ventures | Funding RGB development |
| Pandora Core | Maxim Orlovsky’s company, then RGB’s lead developer |
| LNP/BP Standards Association | Nonprofit funding RGB development |
| Iris Wallet | Bitfinex’s Android wallet, testnet and a limited mainnet, just released |
| BitMask | Diba’s wallet |
| rgb-lib | Rust library (with Kotlin, Swift, and Python bindings) abstracting RGB’s complexity for wallet developers, built on top of BDK |
Iris Wallet, demoed live at the conference, only ran on Android, had no automated backup yet, since every RGB operation generates new data that must be backed up, so recovery isn’t as simple as restoring a seed phrase, and was explicitly labeled experimental: attendees were given free collectible tokens to try, rather than asked to risk real value. The schemas it supported at the time, RGB20 and RGB21, are documented today as part of the full list of supported RGB schemas.
See the current RGB wallets ecosystem for how the ecosystem has grown since, with wallets, exchanges, and infrastructure now spanning far beyond this original 2022 list.
What Use Cases Did Federico Tenga See for RGB in 2022?
Asked what he’d like to actually see built on RGB, Federico ranked stablecoins first, for their everyday utility and for what they could unlock: truly decentralized exchange between a stablecoin and Bitcoin, via atomic swaps within a single transaction rather than hashlock-coordinated swaps across two chains, since atomicity comes for free when both assets change hands in the same Bitcoin transaction. It’s a prediction that materialized years later when Tether chose RGB Protocol on Bitcoin to issue USDT; see the current RGB use cases for the full picture of what’s been built since.
He was more measured about collectibles, a use case he called cute without expecting it to carry major value, and gaming, an area of visible interest though not his area of expertise, and flagged security tokens as blocked less by technology than by regulatory complexity.
On decentralized exchange specifically, he sketched a model where market makers propose a partially signed transaction exchanging two assets, publish the proposal wherever they choose, such as a website or a Telegram group, and any taker who wants the trade simply completes and broadcasts it: an order-book model without a network that needs to validate every quote that never gets filled, which he saw as the only genuinely scalable path to decentralized trading.
Where Does the Name “RGB” Come From?
Not an acronym: a nod to Color Coins, one of the earliest attempts to tokenize assets on top of Bitcoin. The name “RGB” borrows from the language of color, in homage to that earlier project. When someone in the audience asked for an expansion of the letters, Federico had no official answer to offer, and the crowd settled, only half-joking, on this:
“Really Groundbreaking.”
Why This Talk Still Matters
Watching Federico explain RGB in 2022 is a reminder of how little the core idea has changed: client-side validation, Bitcoin as a commitment layer, single-use seals, privacy and scalability designed in from the start. The scale of the project is what changed since: schemas evolved from RGB20/RGB21 into today’s NIA, IFA, UDA, CFA, and PFA; Iris Wallet grew past an Android testnet demo into a broader wallet ecosystem; RGB on Lightning moved from a stated goal into active development; and the protocol reached mainnet, with Tether choosing it to issue USDT on Bitcoin.
To see where that foundation stands today: start with what RGB Protocol on Bitcoin is, check the glossary and FAQ for quick answers, or go build with the developer get-started guide and the full technical documentation at docs.rgb.info.
Talk given by Federico Tenga (Bitfinex team) at Plan ₿ Forum 2022 in Lugano. Archival footage, republished for its historical and technical value.
