RGB Protocol v0.11.1 update: Core Libraries Drop the RC Tag

RGB Protocol v0.11.1 is built using several open-source code libraries that software developers use to issue assets, build wallets, and validate transactions. Five of the core libraries have now tagged v0.11.1 without the release-candidate suffix they carried through the RC cycle, and three supporting libraries updated how their documentation is built, the same day.

In Brief

• Five core libraries (rgb-aluvm, rgb-consensus, rgb-ops, rgb-schemas, rgb-api) are now at 0.11.1, no longer marked as test versions (September 16, 2026).
• rgb-ops now checks Bitcoin transactions with one request instead of two, thanks to @Jainakin.
• rgb-aluvm drops two features that never worked and could crash the program.
• Three supporting libraries (rgb-strict-encoding, rgb-ascii-armor, rgb-strict-types) move to 1.0.4, with updates to how their documentation is built.

What Changed in RGB Protocol v0.11.1?

These five libraries are the same ones running RGB Protocol on mainnet. Software projects commonly publish a series of “release candidates” (test versions marked with an -rc suffix and a number) before finally arriving at a version that other developers can use with confidence. Through the recent release-candidate cycle, these five libraries carried that suffix in their version tags; as of September 16, 2026, all five carry the plain 0.11.1 tag instead, with no -rc attached.

The same day, three supporting libraries updated how their documentation is built, fixing the docs.rs builds of two of them.

What Was Updated?

Documentation Build Updates in Three Supporting Libraries

RGB’s code libraries are written in Rust, and their reference documentation is published automatically on docs.rs, a website that generates the material directly from the source code.

rgb-strict-encoding, rgb-ascii-armor, and rgb-strict-types shipped version 1.0.3 with changes to how their documentation is built. Their documentation, however, still failed to build on docs.rs: in rgb-strict-encoding and rgb-strict-types, the docs.rs configuration applied an extra build flag to every one of their dependencies, causing the build to fail further down the chain.

Thus, version 1.0.4 removed that flag and changed how the documentation gets built in the project’s automated pipeline. Now, documentation for rgb-strict-encoding and rgb-strict-types is available on docs.rs again. rgb-ascii-armor 1.0.4 picked up the fixed rgb-strict-encoding and the same pipeline change.

In plain terms: before docs.rs can publish a library’s documentation, it has to compile the library’s code, following any extra instructions provided by the library. In this case, one instruction reached beyond the library itself, extending to every external library in its dependency chain. A cryptography library several levels down could not compile under that instruction, so the whole build failed and no documentation appeared. Now the issue is fixed.

Five Core Libraries Tag Plain v0.11.1

rgb-aluvm, rgb-consensus, rgb-ops, rgb-schemas, and rgb-api all tagged 0.11.1 on September 16, dropping the release-candidate suffix the five had carried. Beyond the version tag itself, some of the five changed internally too:

• rgb-aluvm, the virtual machine RGB uses to run and check contract logic, removed a feature and an instruction set that were not actually working and could crash the program if triggered. It also dropped three outside code libraries it no longer needs (paste, curve25519-dalek, getrandom).
• rgb-ops changed how it looks up witness transactions, the Bitcoin transactions that close a single-use seal and carry the commitment to an RGB operation, using Esplora, a Bitcoin blockchain lookup service. It now sends one request instead of two per transaction, checking both the transaction itself and whether it is confirmed in the same call. If that request comes back malformed, or reports a confirmation height of zero (which is not a valid value), the library now flags it clearly as an error. The fix was contributed by @Jainakin.
• In rgb-aluvm, rgb-consensus, and rgb-ops, the code that converts data for storage and network transfer was changed to rely on rgb-strict-encoding‘s own tools instead of a separate outside library, and a documentation build fix was applied for docs.rs. In rgb-aluvm and rgb-consensus, the cryptography library secp256k1 was updated to 0.33.1. All five now build their documentation in the automated pipeline with the same configuration docs.rs uses.
• Each library also updated its internal dependencies to the new versions: the other core libraries it relies on now point to 0.11.1, and the supporting libraries to 1.0.4.
• All five repositories also updated their security policy documentation.

Where Did These Changes Land?

RGB Protocol on Bitcoin’s core libraries are maintained under github.com/rgb-protocol, each with a distinct role:

• rgb-aluvm is the virtual machine, essentially the engine that runs and checks contract logic, that RGB uses for contract validation. The removed features and the dependency cleanup landed here.
• rgb-consensus carries RGB’s core validation rules, the code that decides whether a given state transition is allowed.
• rgb-ops builds on rgb-consensus and provides the tools applications use day-to-day to check and store contract data. The fix for looking up Bitcoin transaction data landed here.
• rgb-schemas is the set of templates developers use to issue assets, while rgb-api is the library wallets and other apps use to connect to RGB.
• rgb-strict-encoding, rgb-ascii-armor, and rgb-strict-types are the three supporting libraries that received the documentation-build updates, now at 1.0.4.

Should You Update?

Anyone building on RGB Protocol on Bitcoin should update to the new versions: 0.11.1 for rgb-aluvm, rgb-consensus, rgb-ops, rgb-schemas, and rgb-api, and 1.0.4 for rgb-strict-encoding, rgb-ascii-armor, and rgb-strict-types.

Why does dropping the -rc suffix matter?

Rust developers use a tool called Cargo to download the libraries their project needs. Cargo treats versions marked -rc as test versions and skips them unless asked for by their exact name. Before this release, a developer who simply requested rgb-consensus = "0.11.1" would get an error, because no version with that plain number existed yet; to use the library, they had to type the full test-version name, rgb-consensus = "0.11.1-rc.11". With the plain 0.11.1 tag now published, the simple request works as expected.

With the 1.0.4 releases, the documentation for rgb-strict-encoding and rgb-strict-types is also available on docs.rs again.

RGB Protocol on Bitcoin Is Under Active Development

Updates 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 changes landed, rgb-aluvm and rgb-ops, and to contribute.

Any type of involvement is valuable, whether you report an issue, suggest a code change, or simply follow along with how the protocol evolves.

Where to Find the Code

You can find RGB open-source code in two main GitHub organizations:

• rgb-protocol hosts the core protocol libraries, including the five updated in this release, and the three supporting libraries.
• RGB-Tools hosts the higher-level tools built on top of them, such as rgb-lib for wallet development and rgb-lightning-node for RGB assets on the Lightning Network.

Further Reading

• RGB Protocol on Bitcoin Ships RC11
• AluVM — docs.rgb.info Glossary
• Get Started Building on RGB Protocol on Bitcoin