|

RGB Protocol v0.11.2-rc.1: First Release Candidate After v0.11.1

ByRGB Team
Isometric illustration of a Formula 1 wind tunnel, with a prototype car tagged rc.1 under test and a finished car tagged v0.11.1 stable parked beside it, under the RGB Protocol logo and the title RGB Protocol Ships v0.11.2-rc.1

RGB Protocol on Bitcoin has a new version in testing. On October 9, 2026, five core libraries tagged 0.11.2-rc.1, the first release candidate of v0.11.2, and three supporting libraries shipped 1.0.5 with security fixes. v0.11.1 remains the latest stable release.

In Brief

  • 0.11.2-rc.1 is a test version. v0.11.1 remains the latest stable release, with no change to the consensus rules.
  • Five core libraries move to 0.11.2-rc.1, three supporting libraries to 1.0.5, with three security fixes.
  • The most critical bugs reported by @0xaudron are fixed, and the tests for all of them are now public.
  • The main changes: lighter transfer packages, validation with less dependence on external servers, and a single database for contract data.
  • IFA contracts issued with the previous schema become invalid.

0.11.1 and 0.11.2-rc.1: Two Versions, Same Consensus Rules

Both numbers now appear in the repositories. Here is the status of each one.

Library Stable release In testing
rgb-aluvm, rgb-consensus, rgb-ops, rgb-schemas, rgb-api 0.11.1 0.11.2-rc.1
rgb-strict-encoding, rgb-ascii-armor, rgb-strict-types 1.0.5 none

RGB has no single “current version”. Each project is free to choose the version of the libraries in its software. As with Bitcoin Core, nodes running different versions can work side by side, as long as they follow the same consensus rules. Between 0.11.1 and 0.11.2-rc.1 the consensus rules stay the same. The main difference lies in the format of the consignments: software based on 0.11.1 cannot read the new v1 consignments (see below). In theory, a project staying on 0.11.1 could implement a converter from v1 to v0 consignments and keep its existing code.

v0.11.1 is the latest stable release of the five core libraries. Wallets, tools, and guides based on v0.11.1 stay valid.

0.11.2-rc.1 is a release candidate. Software projects publish release candidates, marked with the -rc suffix, so developers can try new code before a stable version. Cargo, the tool Rust developers use to download libraries, skips -rc versions by default: a project asking for version 0.11.1 keeps receiving 0.11.1, and the release candidate arrives only on explicit request.

The higher-level tools are not using v0.11.2 yet. rgb-lib, the library for wallet development, and rgb-lightning-node remain on the v0.11.1 line. Wallet users and application developers relying on those tools have nothing to change today.

Three Security Fixes in the Supporting Libraries

Contract data reaches an RGB wallet as a plain sequence of bytes, sent by someone else. Before checking a contract, the wallet has to re-transform the bytes into structured values such as names, amounts, and lists. The three supporting libraries take care of that step, called decoding. Since the bytes come from another party, the decoder has to stay safe even with data crafted on purpose by an attacker. Version 1.0.5 closes three gaps in decoding.

1. A limit on memory reserved in advance (rgb-strict-encoding 1.0.5)

Every encoded list opens with a number: the count of its elements.

  • Before: to save time, the decoder reserved memory for the whole list right after reading that number. An attacker could exploit the shortcut with a forged file declaring millions of elements and containing almost none. A wallet or a server opening the file would then reserve a large amount of memory for an almost empty list, enough for a denial-of-service attack.
  • Now: the decoder reserves at most 64 KiB in advance, and adds more memory only for the elements that are actually present in the data.

2. Declared limits are now enforced (rgb-strict-types 1.0.5)

RGB data types can declare limits. A ticker, for example, can be defined as 1 to 8 characters from a fixed alphabet.

  • Before: the decoder ignored those limits, so a contract could carry a 255-character ticker made of symbols and still pass validation.
  • Now: the decoder rejects text, byte sequences, lists, sets, and maps outside their declared size, and text with characters outside the declared alphabet.

3. One valid encoding for maps and sets (rgb-strict-types 1.0.5)

A map is a collection of key-value pairs, such as “token number → attached file”.

  • Before: the decoder accepted keys in any order, and even repeated keys, so the same content could exist in several different encodings.
  • Now: the decoder requires keys in strictly ascending order with no duplicates, so each content has a single valid encoding. The same rule applies to sets.

The same release makes rgb-strict-types reject a type definition pointing to a missing type, and rgb-ascii-armor 1.0.5 picks up the fixed rgb-strict-encoding.

Who receives the fixes? The 1.0.5 libraries are a regular, stable release. Projects built directly on the 0.11.1 core libraries receive them with a routine dependency update. The 0.11.2-rc.1 libraries already include them.

Three decoding fixes in the 1.0.5 supporting libraries, where the decoder turns bytes sent by another party into names, amounts, and lists. Memory reserved in advance: before, a list declaring millions of elements made the decoder reserve memory for all of them; now at most 64 KiB in advance. Declared limits: before, a ticker of 255 symbols passed validation; now size and alphabet limits are enforced. Maps and sets: before, keys in any order or repeated allowed many encodings of the same content; now keys must be strictly ascending with no duplicates, for a single encoding

Reported Bugs: Fixes and Public Tests

@0xaudron reported a set of bugs in the RGB libraries, and wrote for each one a test reproducing the problem, which are now public in the rgb-tests repository (the shared test suite of the RGB libraries).

The most critical bugs are fixed. Priority went to the bugs with a possible effect on the schemas ready for mainnet, or with a possible use in denial-of-service attacks. Two of @0xaudron’s eight tests correspond to fixes 2 and 3 above (declared limits, ordering of maps). Both now run with the rest of the suite at every code change, so a regression would show up immediately.

The other six tests are open and public. The bugs are about identifiers that can collide with specially crafted inputs, two instructions of the virtual machine, the comparison of enumerated types, and the text export of oversized transfer packages. Each test comes with a short note on the problem, so any developer can read it, run it, and follow the work on the fix.

What Is New in 0.11.2-rc.1?

0.11.2-rc.1 is a release candidate: a test version, published so developers can try the new code and report problems. v0.11.1 remains the stable release, and none of the changes below applies to software built on v0.11.1.

The release candidate brings seven main changes to the five core libraries, plus a group of smaller ones.

1. Lighter Transfer Packages

In RGB, the sender of an asset hands the receiver a package of data called a consignment, and the receiver checks it on their own device. rgb-ops introduces a new consignment format: consignments move from v0 to v1.

  • Before: every v0 consignment included the full schema of the contract: the template with the rules of the asset, its data types, and the scripts for the AluVM virtual machine.
  • Now: in v1 consignments, the schema does not travel with every transfer. A wallet imports the schema once, verifies it, and stores it; from then on, each consignment only names the schema by its identifier. Consignments get smaller, and the validator works from rules already verified on the local device.

For the import of schemas, the release replaces the Kit with a SchemaDefinition. The Kit did not carry enough information for the validation of the strict types; a SchemaDefinition allows the validation of the types before the import.

The new format also carries the full Bitcoin transaction for each step of the history (the witness transaction). v0 consignments stay readable, with a conversion to v1.

2. Validation in Two Phases

Checking a consignment involves two types of actions. The first is deterministic computation: are the contract rules respected at every step of the history? The other needs the Bitcoin blockchain: is each witness transaction really confirmed in a block? The answer to the second question is not fully deterministic: with few confirmations, a reorganization of the chain could change the result.

  • Before: validation was a single operation. The validator checked the contract rules and searched the blockchain for the transactions in the same run, so it needed a network connection from the start.
  • Now: in rgb-consensus, the two kinds of actions are separate phases. Phase one runs with no network connection and returns all the witness transactions listed in the consignment. Phase two searches the blockchain for those transactions and delivers the final verdict.

A wallet can therefore reject an invalid consignment before contacting any server, and organize the blockchain queries in the way best suited to its setup. The single-step validation of v0.11.1 is still available.

3. Compact Proofs for Confirmed Transactions

Every step in the history of an asset points to a Bitcoin transaction, and the validator has to confirm its presence in a block.

  • Before: the validator always asked an indexer, a server with a searchable copy of the blockchain, for each transaction.
  • Now: a consignment can include SPV proofs: short pieces of data showing the inclusion of a transaction in a specific block. With the proof, the validator only needs the block header in which the transaction was mined, which can be provided by a light node instead of a full indexer. The change also improves privacy: with no request for each transaction, the indexer cannot infer which transactions move RGB assets. If a proof fails verification, the validator signals a warning and returns to the regular query to the indexer.
Validation in RGB Protocol v0.11.2-rc.1: in phase 1, offline, the wallet checks the contract rules of the consignment and rejects an invalid one before contacting any server; in phase 2, each witness transaction is checked with an SPV proof and a block header, which can come from a light node, or with a query to the indexer when the proof is missing or fails, the second case with a warning.

4. A Stricter Check on Transfer Terminals

Every consignment declares its terminals: the outputs receiving the assets in the latest transfer.

  • Before: validation did not check the declared terminals against the content of the consignment.
  • Now: validation fails if a terminal does not match an unspent assignment inside the consignment. A receiver gets a clear error for a package with a missing or already spent destination. Terminals can now be trusted as new allocations proven by the consignment.

5. One Database for Contract Data

  • Before: rgb-ops kept contract data in three separate components, always saved as files: the wallet loaded them into memory (RAM) while in use, and wrote them back to the files on closing.
  • Now: a single storage layer replaces the three components, with SQLite, a widely used embedded database, as its first implementation. A reader for the previous files remains, for the migration of existing data.

rgb-api follows the same change, including its command-line tool.

6. A Schema for Assets Bridged from Other Chains

rgb-schemas adds the Bridged Fungible Asset (BFA) schema, marked as not production-ready. BFA describes a fungible asset arriving from another blockchain: new units can be minted on the RGB side only after the confirmation of a matching event on the original chain. rgb-consensus adds the contract instruction behind the check, and rgb-ops adds the components for the confirmation of those events on EVM chains.

7. Burn Records in the IFA Schema

IFA (Inflatable Fungible Asset) is the schema for fungible assets with inflate, burn, and link operations.

  • Before: the burned amounts were recorded in the metadata of the single operation.
  • Now: each burn is recorded in the contract’s global state, together with a reason.

Because of the change, the IFA schema receives a new schema identifier, and IFA contracts issued with the previous schema become invalid. The IFA schema has never been ready for mainnet: rgb-schemas marks it as not production-ready, and rgb-lib blocks IFA issuance on mainnet. The other schemas supported by rgb-lib remain valid.

8. Smaller Changes

  • Invoices can carry two new optional fields: a public key and an encryption parameter (rgb-ops).
  • Bitcoin Core as a data source: rgb-ops and rgb-api can query a Bitcoin Core node directly, next to the existing Electrum and Esplora options.
  • A fix in the Electrum connection (rgb-ops). Before: a transaction reporting more confirmations than the current height of the blockchain caused a calculation error. Now: the library handles the case correctly.
  • The command-line tool in rgb-api can prepare a transfer without an indexer, with the proofs already in storage. Its description now says explicitly: for testing and development only, never as a production wallet.
  • rgb-aluvm only updates its dependencies to the 1.0.5 supporting libraries.

Should You Update?

  • Wallet users: no action needed. v0.11.1 remains the stable release.
  • Developers building on rgb-lib or rgb-lightning-node: no action needed. Those tools are not using v0.11.2 yet.
  • Developers building directly on the 0.11.1 core libraries: update your dependencies to receive the 1.0.5 supporting libraries, with the three security fixes.
  • Developers interested in testing 0.11.2-rc.1: expect some adaptation work, because code written for 0.11.1 needs changes to run on the release candidate. Schemas are imported in a new format, and contract data moves to the new database layer. Some programming interfaces in rgb-consensus have new names, and others are gone. The command-line tool starts from an empty database, without the data saved by earlier versions. The IFA schema and two internal type libraries also have new identifiers, and IFA contracts issued with the previous schema are no longer valid. Feedback from testing is welcome in the issue tracker of each repository.

Release Notes

For the complete list of changes, the release notes of each library are available on GitHub.

Core libraries, 0.11.2-rc.1:

Supporting libraries, 1.0.5:

Tests: rgb-tests, changes for 0.11.2-rc.1

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 eight updated in this release, and the rgb-tests repository.
  • 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

Similar Posts