RGB Ownership Explained: No Liveness Required

This clip is from an interview with Stefano Pellegrini, a developer on the RGB Protocol Team, recorded at the Tuscany Lightning Summit 2025 in Viareggio, Italy. He walks through what client-side validation on RGB Protocol on Bitcoin actually requires from a wallet, and why RGB ownership works differently from Lightning.

In Brief

• No liveness required: unlike Lightning, which relies on watchtowers, an RGB wallet just needs reliable backups, with no fixed schedule for staying online
• Ownership lives on a UTXO: spending it transfers the asset, giving RGB double-spend prevention for free
• RGB transitions form a DAG, which can follow the Bitcoin transaction graph or run separately, depending on wallet design
• On-chain, RGB transfers look ordinary: the only trace is a commitment (OP_RETURN or Taproot) that reveals nothing about the asset or amount
• Forward privacy, not backward: a receiver sees an asset’s full history, but a blinded UTXO hides where it goes next

Why Doesn’t RGB Need a Wallet to Stay Online?

Client-side validation means a wallet has to keep track of more than just its master private key, so a mnemonic phrase alone isn’t enough to restore a wallet, since the wallet has to back up the extra validation data too. Lightning shares that part of the tradeoff, since its wallets also need to store more than the Bitcoin master key.

Instead, RGB Protocol on Bitcoin and Lightning diverge on liveness. A Lightning wallet has to check in periodically to catch a channel counterparty trying to broadcast an outdated state and steal funds, and watchtowers exist for this reason. An RGB wallet carries no such requirement. It just needs a reliable way to back up its extra data, as it doesn’t need to follow any schedule to stay online.

How Does RGB Ownership Work?

RGB ownership of an asset (or more generally, of any RGB contract state) is tied directly to a Bitcoin UTXO. In practical terms, giving up that ownership means spending the UTXO that carries it, and nothing more. That single rule is what lets RGB inherit Bitcoin’s double-spend prevention without building anything new: a UTXO can’t be spent twice, so the assets tied to it can’t be either.

Every RGB state transition assigns ownership to another UTXO, which can already exist in the Bitcoin UTXO set, or can be created by the very same Bitcoin transaction that spends the old one. Because of this design choice, the resulting graph of RGB transitions is a directed acyclic graph (DAG) that may track the graph of Bitcoin transactions one-to-one, or run separately from it: a decision made by the wallet developer, or even the user.

“A Bitcoin transaction that includes an RGB transaction is basically indistinguishable from any other Bitcoin transaction on-chain, apart from the fact that it may include an output which has a commitment — but the commitment doesn’t reveal anything about what the assets that are moved are, or the amounts, or whatever.”

An OP_RETURN or a Taproot output (opret or tapret) carries that commitment. Practically, this setup also means a payer can reach a recipient two ways: by sending to a Bitcoin address, or by sending directly to one of the recipient’s existing UTXOs.

Does RGB Offer Forward or Backward Privacy?

Receiving an RGB asset comes with an obligation: the receiver has to validate, client-side, the entire history of that asset back to genesis, back to the moment it was first issued. As a result, this validation implies that a receiver learns about every previous owner of that allocation, since each one is tied to a specific UTXO.

However, RGB hides where the asset goes next. For instance, a receiver can accept assets on an existing UTXO, blinded with a private value only they know. The payer knows they’re paying that person, but not which UTXO receives the funds: that detail only becomes visible to future owners, and only after the current receiver spends it forward.

RGB doesn’t offer much backward privacy, but it does offer forward privacy.

Further Reading

• Client-side validation — docs.rgb.info
• Single-use seals — docs.rgb.info
• RGB Protocol on Bitcoin, Explained From the Start: Federico Tenga at Plan ₿ Forum 2022

---