RGB Protocol on Bitcoin Ships RC11
RGB Protocol on Bitcoin has shipped v0.11.1 RC11, a maintenance release across the protocol’s 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(discovered and reported by 0xaudron), and a correction to howrgb-opsrevalidates operations after a Bitcoin reorg. rgb-schemasandrgb-apiare tagged alongsidergb-consensusandrgb-opsto keep version numbers aligned across the stack.rgb-strict-encoding,rgb-ascii-armor,rgb-strict-types, andrgb-aluvmshipped the same day as RC11, each on its own version track, carrying maintenance updates only: an MSRV bump to 1.85.0, dependency updates, and lint fixes for Rust 1.97.- Integrators and node operators running RC10 or earlier should update to RC11.
What’s New in RGB Protocol 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 protocol libraries keep shipping numbered candidates like this one. 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 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. In fact, elsewhere in the codebase, the tree depth is encoded as a 5-bit value capped at 31. The encoding limit meant a path of exactly 32 was structurally valid Rust, but it would “panic” the instant it got cast down to that narrower type. This kind of off-by-one bug 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.
Thanks to 0xaudron, who discovered and reported the issue.
In any case, 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, a theoretical panic on malformed or maliciously oversized input now surfaces as an ordinary, catchable validation error.
Correct Revalidation After a Bitcoin Reorg
RGB relies on Bitcoin to order and finalize state transitions, meaning that an operation is confirmed by the related witness transaction, and a chain reorganization can temporarily orphan that transaction. When that reorg happens, a node has to mark the affected operation (and anything built on top of it) as invalid, then turn 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.
Thus, when a new consignment arrives, the code checks each of its operations against the set of previously invalid ones. Any match gets revalidated together with everything built on top of it. The code calls this pattern a “diamond chain”: one possible shape a dependency chain can take in RGB’s UTXO-based state graph, when a branch splits and later reconverges. The same code path now also rejects a consignment 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 protocol 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. Both are tagged alongside
rgb-consensusandrgb-opsto keep version numbers aligned across the stack.
The same day, rgb-strict-encoding, rgb-ascii-armor, and rgb-strict-types shipped version 1.0.2, and rgb-aluvm shipped 0.11.1-rc.4. Each of them has its own version track, separated from the four repositories above. None of the four carry functional changes: the updates cover an MSRV bump to 1.85.0, dependency bumps, and lint fixes for Rust 1.97.
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 application uses to run operations correctly.
Anyone building on RGB Protocol on Bitcoin (like 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 protocol 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.
Release Notes
rgb-consensus, rgb-schemas, rgb-ops, rgb-api, rgb-strict-encoding, rgb-ascii-armor, rgb-strict-types, and rgb-aluvm.
