RGB Protocol on Bitcoin Ships RC11
RGB Protocol on Bitcoin has shipped v0.11.1 RC11, a maintenance release across the protocol’s core libraries that tightens two specific behaviors inside the validation logic.
In Brief
- RGB Protocol RC11 is now tagged across the core protocol repositories (
rgb-consensus,rgb-schemas,rgb-ops,rgb-api) under github.com/rgb-protocol. - Two fixes are included: a tightened bound on multi-protocol commitment proofs in
rgb-consensus, and a correction to howrgb-opsrevalidates operations after a Bitcoin reorg. - RC11 does not change the protocol’s public interfaces or break compatibility with existing integrations.
rgb-schemasandrgb-apicarry no code changes in this release — they’re tagged alongside the other two libraries to keep version numbers aligned across the stack.- Integrators and node operators running RC10 or earlier should update to RC11.
What’s New in RGB Protocol v0.11.1 RC11?
“RC11” is the eleventh release-candidate tag of the v0.11.1 line.
As fixes and improvements land on top of that same protocol version, the core libraries keep shipping numbered candidates like this one, without touching the consensus rules or breaking compatibility with existing integrations. RC11 tightens two specific behaviors inside the core validation logic.
What Was Fixed?
A Tighter Bound on Multi-Protocol Commitment Proofs
RGB anchors its state transitions to Bitcoin through a multi-protocol commitment (MPC): multiple protocols share a single Bitcoin output, each one hashed into its own leaf of a Merkle tree and proven back to the root via its own Merkle path. Tree width scales with the number of protocols committing together, and a wider tree means a longer path, so RGB’s code enforces a hard cap on how long that path can be.
RC11 tightens that cap from 32 to 31 nodes, directly in MerkleProof, the type that represents a Merkle path, so the limit is enforced at construction and decoding time instead of being checked separately downstream.
That number isn’t arbitrary: elsewhere in the codebase, the tree depth is encoded as a 5-bit value capped at 31, so a path of exactly 32 was structurally valid Rust that would panic (crashing the process handling the decode, instead of returning a controlled error) the instant it got cast down to that narrower type. It’s the kind of off-by-one that slips past review easily but turns into a real problem the moment a node decodes a proof from an untrusted consignment sent by a counterparty.
Client-side validation for ordinary transfers was not affected by this bug: such a long path never occurs in practice, since it would take dozens of protocols committing to the very same output. For anyone whose code constructs or decodes MPC proofs directly, that’s exactly what the fix delivers: a theoretical panic on malformed or maliciously oversized input now surfaces as an ordinary, catchable validation error, which is how any parser handling untrusted input should behave in the first place.
The issue was discovered and reported by the developer @ValkyriSecurity.
Correct Revalidation After a Bitcoin Reorg
RGB relies on Bitcoin to order and finalize state transitions: an operation is only as good as the witness transaction that confirms it, and a chain reorganization can temporarily orphan that transaction. When that happens, a node has to mark the affected operation (and anything built on top of it) as invalid, then flip it back to valid once a confirming transaction (the original one, or a new one carried by a fresh consignment) lands on the chain again.
RC11 fixes a gap in that second half of the process. Previously, rgb-ops tracked invalidity at the level of the whole transition bundle: the group of operations sharing a single confirming transaction. That granularity meant a node could easily lose track of which individual operations inside a bundle still needed revalidating. RC11 moves the tracking down to the single operation. When a new consignment arrives, the code checks each operation it contains against the set of previously invalid ones; any match gets revalidated together with everything built on top of it. The code calls it a “diamond chain,” since dependencies in RGB’s UTXO-based state graph can branch and later converge. The same code path now also rejects a consignment outright if none of its operations carry a valid confirming witness, closing a related gap.
The update does not affect Bitcoin’s own security guarantees, as client-side validation still catches any state that a node would reject.
Instead, the fix matters for the bookkeeping: without the update, a node’s local view of “what state currently exists” could stay out of sync with what the Bitcoin chain has actually reconfirmed. In fact, this information matters directly to anyone running node infrastructure, since it’s the layer that decides what balances and contract states get shown to users and applications.
Where Did the RC11 Fixes Land?
RGB Protocol on Bitcoin’s codebase is split across a set of core libraries maintained under github.com/rgb-protocol, each with a distinct role:
- rgb-consensus carries RGB’s consensus-critical and validation code. It contains the rules that determine whether a state transition is valid. The multi-protocol commitment proof bound was tightened here.
- rgb-ops builds on
rgb-consensusand provides the non-consensus-critical APIs that applications use to validate and store contract state, including how a node tracks operations and revalidates them over time. The reorg revalidation fix landed here. - rgb-schemas is the contract schemata that developers use to issue assets, while rgb-api is the client-facing library wallets and desktop apps use to integrate RGB. They carry no code changes in RC11, but they’re tagged alongside the other two libraries purely to keep version numbers aligned across the stack.
Should You Update to RC11?
Both fixes close edge cases in RGB’s validation logic: one at the boundary of the maximum supported commitment-proof size, the other in how invalid operations get revalidated after a reorg. Neither of them changes everyday behavior for most integrations, but both sit on code paths that any RGB node or application uses to run operations correctly.
Anyone building on RGB Protocol on Bitcoin — wallet backends, node operators, application developers — should update to RC11 across rgb-consensus, rgb-schemas, rgb-ops, and rgb-api on github.com/rgb-protocol.
RGB Protocol on Bitcoin Is Under Active Development
Fixes like the ones above are part of ongoing, public work on RGB’s core libraries. The code, the commit history, and the open issues are all visible to anyone who wants to look. External developers interested in the protocol are welcome to check out the repositories where this release’s fixes landed, rgb-consensus and rgb-ops, and to contribute.
Any type of involvement is valuable, whether you report an issue, open a pull request, or simply follow along with how the protocol evolves.
