LNP/BP Standards Association presented a new generation of RGB smart contracts (version 0.12) 10 days ago with release candidate 1. Over this period of time we have received several improvement requests from the companies already integrating it into their products and tried to fulfill them with release candidate 2.

Alongside candidate 2 we release the updated version of fungible and non-fungible token standards, namely RGB-20 and RGB-21.

What's new

Consensus-level

This release introduces significant enhancements to the Ultrasonic contract execution layer, focusing on improved security, flexibility, and code organization. The primary goal is to enable more complex and secure contract logic by providing mechanisms for input-specific lock conditions and operation-level witnesses.

• Codex Structure Modification: The Codex struct is updated to include a features field for enabling/disabling certain functionalities. This allows for future extensibility and configuration options.
• Two-Phase Verification: The contract verification process is split into two distinct phases: a main verification script and input-specific lock script verification. The main verification script can now focus on the overall operation logic, while the lock scripts can handle input-specific access control. This allows for more granular control over input access conditions.
• CellLock Structure: A new CellLock struct is introduced to encapsulate the lock script and auxiliary data associated with a destructible state cell, which provides a cleaner and more structured way to manage lock conditions.
• Operation Witness: An operation-level witness field is added to the Operation and Genesis structs, allowing for data that applies to the entire operation, rather than just individual inputs.
• Ultrasonic Instruction Set Expansion: New instructions (LdW, LdIW, LdIL, LdIT) are added to the Ultrasonic instruction set to facilitate access to the operation witness, input-specific witness, lock auxiliary data, and authorization token within the VM.

Standard library

This release refactors the RGB smart contracts library to improve its persistence layer, enhance security, and streamline consignment handling.

• Replaced the fs feature with a binfile feature, providing more granular control over binary file format support.
• Introduced a new rgb-persist-fs crate to encapsulate filesystem persistence logic, improving code modularity and separation of concerns.
• Introduced the way to programmatically import contracts via consignments.
• Improved spam prevention, which included creation of a dedicated guideline to contract developers (RCP-250528A), its implementation, and the addition of an embedded mechanism limiting the maximal number of operations in a consignment.
• Added more aggregators producing computed contract state.
• Replaced ImmutableApi and DestructibleApi with GlobalApi and OwnedApi, respectively, for clearer semantics.
• Introduced Semantics struct to group API definitions, codex libraries, and type systems.
• Added ApisChecksum and ArticlesId for improved API versioning and identification.
• Implemented signature validation in Articles::with and Issuer::with using a provided validator function.
• The test suite has been updated to include more comprehensive validation of the new API and consignment handling mechanisms.

Runtime and command-line

Runtime and the rgb command-line tool has got complete implementation for:

• Contract import and export;
• Contract backups;
• Purging of non-used contracts.

Read the full announcement on the official website: https://rgb.tech/blog/release-v0-12-rc-2/

LNP/BP Standards Association announces that RGB version 0.12 has reached the release candidate stage.

All RGB protocol developers and integrators are recommended to start the integration with v0.12 RC1. Due to the consensus-level changes, contracts issued before this release will not be compatible with the new RGB version.

TL;DR

RGB just got one step from production with the first release candidate of its most tested and robust version (0.12). Over the last half of the year, the 0.12 version has brought zk-STARK readiness to the RGB (making it "zk-STARKy"), a huge performance boost, and a lot of simplification and security improvements. The release candidate is for all developers working with RGB, so they can integrate it into their software, having guarantees of consensus and low-level API freeze.

What's new

The version 0.12 of RGB represents a result of 7 months of protocol re-design, aimed at the following:

1. Make protocol ready for zk-STARK compression;
2. Simplify the protocol as much as possible, reducing any potential attack surface and helping protocol adoption;
3. Ensure security of the protocol with thorough unit and integration test coverage, including tests for potential attacks;
4. Make protocol fully production-ready by freezing consensus level changes and ensuring robustness and performance.

1. zk-STARKky RGB

The new RGB architecture for the first time introduces zk-AluVM, which is a compact and performant Turing-complete zk-VM made for client-side validation. While being universal, it offers a non-von-Neuman architecture with an extra-reduced instruction set, made of just 40 instructions and provides read-once memory compatible with single-use seals.

The contract state was also transformed. Previously, RGB contracts had three variants of state data: fungible (with Pedersen commitments and Bulletproofs), non-fungible structured state and binary attachments. To make the contract state zk-compressible, version 12 unified state into a single type, made of finite field elements.

The whole consensus validation was reduced to just a few hundred lines of code, which can be represented as an arithmetic circuit for a zk prover, allowing recursive history compression.

All these changes not just make RGB ready for zk-STARK provers and verifiers, but also allow use of RGB with the future client-side validation layer 1 codenamed [Prime].

2. Protocol simplification

RGB so far has been notoriously infamous for the protocol complexity. Version 0.12 should shift that impression, since most of the changes in it were an actual simplification of the protocol.

Overall, we have achieved x4 reduction in the size of the consensus code and x2 reduction in standard libraries, as well as a significant reduction in the number of data types, and removal of ~30% of generic type parameters in the APIs.

Such simplification provides several gains:

• much reduced attack surface;
• better auditability;
• better performance;
• better developer experience;
• which opens a way for building simpler UX with improved user experience.

Below, we cover some of the technical details of the main simplifications which has happened in v0.12.

2.1. Seal unification

RGB uses single-use seals, a cryptographic primitive, to prevent double-spending by "anchoring" into a UTXO-based blockchain or a sidechain.

Previously, there were two different types of single-use seals, which can be used by an RGB contract: so-called tapret and opret-based. Tapret seals can't be seen inside a bitcoin transaction, but require a taproot wallet, which still is not fully supported by all exchanges, hardware wallets or Lightning nodes. Opret is an answer to that; it utilizes old OP_RETURNs to put a 32-byte commitment into a bitcoin transaction; which has many drawbacks (higher transaction price), exposure to chain analysis, etc., but helps when a wallet or a user can't use taproot.

However, the presence of two distinct seal types, where a user chooses one of the variants, had created tremendous complexity, both in code, APIs and in user experience, and resulted in a large attack surface.

In v0.12 we found a beautiful way how to unify two distinct seal types into a single-one, yet still supporting OP_RETURN fallback option.

2.2. Removal of Pedersen commitments and Bulletproofs

Since the inception of RGB protocol, it was using confidential assets by Blockstream for providing contracts with a fungible state. While the idea of confidential assets has been great, it was lacking an efficient implementation, postponing use of RGB in production.

The problem was that the original Blockstream implementation of confidential assets for Liquid (and the Elements project) used older range proofs instead of bulletproofs, which are much larger and longer to validate. On the other hand, Bulletproofs were never implemented for the Bitcoin SECP256K1 curve, while the RGB community and devs have been waiting for this implementation for more than 5 years.

With the introduction of zkVM and zk-STARK compatibility, Bulletproofs and Pedersen commitments have become unneeded, since zk-STARK can provide much better performance and offers a range of ready-to-use implementations.

2.3. State unification

With the removal of Pedersen commitments and Bulletproofs, and the introduction of zkVM, we were able to simplify and unify the state of RGB contracts. Previously, an RGB contract may have three forms of a state: fungible, structured (non-fungible) and blob attachments. In v0.12, this state is unified under a single state type, which, again, reduces the codebase and the attack surface.

2.4. No more schemata

zk-AluVM has changed a lot: with zk-STARKs, we need to be able to represent everything in the consensus in an arithmetized form. Thus, we got rid of the old way of writing RGB contracts with schemata and unlocked the real potential for smart contract programming with Turing-complete zk-AluVM assembly and higher-level languages on top, like Contractum.

From the point of view of contract issuers, now, instead of importing schemata, interfaces and other components, they will be using so-called issuers, provided by the contract developers. The users will be also less confused with an obscure terminology.

2.5. Removed interfaces and implementations

The way how interfaces work was also fully refactored, mostly due to zkVM. Most importantly, it has become much simpler.

Previously, software devs integrating RGB were lost in multiple types related to interfaces: interfaces, standards, implementations, schemata, etc. Many of them were also made with generic type parameters, which made it much harder to integrate and fully support their functionality.

Now, with v0.12, the only thing a developer using RGB should know about is so-called contract API: a simple non-generic object explaining to a wallet how to operate with a contract.

Interfaces are still present, but not in the standard library: they live solely now in the world of Contractum language and are used only by contract developers, and the Contractum compiler will be taking care of compiling them into the contract APIs.

2.6. Single-blockchain protocols

Since v0.11, RGB supported multiple blockchains. In v0.12 we made it simpler: instead of allowing a contract to operate on multiple blockchains, each blockchain will have its own version of the contract, which significantly reduces possible attack surface and API complexity.

2.7. No more blank state transitions

One of the concepts that were hard to grasp in RGB was the concept of blank state transitions. In v0.12, because of new and better way to build contract API, they are gone.

3. Payment improvements

3.1. Invoicing

The invoices have become much richer: they may specify any forms of a fungible- and non-fungible state and allow providing more accessory information in a better structured way.

3.2. Multiple-asset contracts

Contracts now may expose multiple tokens, which may interact, and these tokens can be accessed independently or jointly via both invoices and APIs.

3.3. Payment scripts

Version v0.12 for the first time introduces a concept of payment scripts, which is a powerful tool helping to construct and execute complex payments, which may include multiple beneficiaries, multiple contracts and even multiple consequent transactions or a transaction graph.
The functionality helps in:

• multisig wallets;
• coinjoins and payjoins;
• transaction batching at aggregation in wallets and exchanges;
• lighting channel operations;
• future Ark applications.

3.4. Re-org support

As any blockchain-based system, RGB depends on what happens there, and one of the main issues with blockchain deep reorgs, which may lead to the loss of funds by the users. The problem was never properly addressed in RGB, until in 2024 we discovered a type of attack which can leverage even shallow reorgs.

For the version v0.12 we have developed and implemented a mathematical model, formally proving how the system can be protected from such attacks, even if multiple and deep re-orgs happen or got combined.

4. Performance

Performance was one of the pain points of the past RGB release. In version 0.12 we did a huge work to bring it up to the production requirements.

4.1. Consignment streams

Transfer of client-side data during RGB payment is made in the form of a binary data sent from a payer to a beneficiary, possibly via a relay. These binary data packs are named consignments.

Before, consignments were distributed in the form of files, a...

LNP/BP Standards Association is happy to announce the eight beta release of RGB version 0.11.

Beta 8 comes just three weeks after Beta 7, and mainly finalizes on work which has started before,
and contains bugfixes for the issues known before Beta 7 or discovered recently.

With Beta 8 RGB comes closer to API stabilization: we announce a freeze to any changes in API unless
they are required by a fix of a security-critical bug, putting at risk client's funds. All other
bugs and feature requests from now on will be deferred to v0.11.x maintenance versions, after the
completed v0.11.0 release cycle.

All users of RGB protocol, developers and integrators are urged to update and test their software
with Beta 8 as soon as possible. Due to the consensus-level changes contracts issued before this
release would not be compatible with the released RGB version.

What's new in Beta 8

Consensus-level change

Beta 8 amends implementation of RCP-240731A, a new consensus-level feature we introduced in beta 7.
Specifically, it changes the type of nonce from u8 to u64, in order to be able to support
Lightning eltoo and other protocols which may have many more offchain state updates as a part
of one transaction graph comparing to the modern-day Lightning BOLT approach.

Improved persistence

In Beta 7 we have introduced an improved persistence APIs. In Beta 8 we complete this epic by
separating persistence providers from the data, such that users of RGB and BP libraries can now
integrate blocking storage code into async apps by using dedicated threads abstracted away through
these providers.

What's next

Beta 8 release continues a phase of preparation for a public preview of the RGB v0.11. All parties
are strongly recommended switching to this latest beta, which contains a number of bugfixes and a
consensus-breaking change, and provide us feedback their feedback.

Beta 8 starts a period of codebase freeze: only critical vulnerability changes will be accepted to
the codebase. Once there were no critical vulnerabilities discovered, a Preview 1 version of RGB
will be released.

Beta 8 was a result of internal audit and testing effort, we do together with [Bitfinex Labs], which
will continue with external audit in the following week. In this way we plan to ensure the system
security and safety before the final release.

You can track us on our journey towards v0.11 release with this GitHub dashboard.

Acknowledgements

We are grateful to Fulgur Ventures, continuing their multi-year support for our efforts in
developing RGB, as well as other Association members, including Bitlight Labs, who had become a
major contributor to RGB development. We are grateful to all commercial companies, building on RGB,
and providing their support, contributions and feedback, including Bitfinex, Pandora Prime, and
DIBA. We are also grateful for individual contributors, who do their small -- but still highly
valuable and welcomed input in making RGB better.

LNP/BP Standards Association is happy to announce the seventh beta release of RGB version 0.11.

What's new in Beta 7

Consensus-level changes

Beta 7 completes an important feature which will be required by any DeFi smart contract:
introspection of the contract state from inside AluVM scripts. While before it was possible to
access state from the current operation only, in this release we have implemented a new engine
for dynamically computing and updating global contract state during the validation itself, such
that scripts can also access global state and outputs known to the contract.

This feature comes hand-in-hand with an improved ordering of the global state data. We introduce a
new nonce field in RGB operations, which allows to enforce the same deterministic ordering for
mempool, lightning channel and on-chain transactions. You can read more about this feature in
RCP-240731A proposal.

Improved persistence

Previously, the state for each contract have to be fully stored in the memory. Beta 7 introduces a
new contract state engine, which works with the consensus level, but allows to keep the state in
some external storage, like file, database etc., not fully loading it into the memory. This allows
to ensure that validation can run efficiently in all environment, from enterprise setups to
restricted embedded systems, like hardware wallets.

Beta 7 adds support for automatic detection of contract and stash data changes and automated saving
of the modified data, as well as recovery from the I/O failures, ensuring that the persisted state
is always consistent. This should work well with database environments and their transaction-commit-
rollback workflows.

Support for re-orgs and RBFs

For the first time we added ability to the RGB wallet library to support both RBF transactions and
properly react on blockchain re-orgs, whenever they happen. This was achieved due to the complete
refactoring of how the RGB wallet operates. Previously, wallet was tracking only bitcoin
transactions belonging to the wallet descriptor; however in RGB validity of operation also depends
on a second bitcoin transaction, called "witness transactions", which contain the commitment for the
single-use seals -- the mechanism by which RGB prevents double-spending of the client-side state.
In order to be valid, RGB state must belong to an operation output for which all previous history
of the operation graph is commited by the witness transactions included into the blockchain and
lightning state channels. As you see, a re-org, RBF transaction change or Lightining channel update
changes that validity, and the new wallet engine allows us to efficiently track those changes in
automatic fashion without creating excessive blockchain indexer requests.

Support for hot wallets

Since RGB uses a novel type of bitcoin transaction commitments, taprets (OP_RETURN commitments
residing inside taproot tree), RGB taproot wallets are not supported by rust-bitcoin, miniscript and
BDK libraries. Thus, starting from 2022, LNP/BP Association was working on new and modern
rust implementation of bitcoin protocol named BP libraries. This release for the first time
ships with new version of BP supporting creation of hot wallets, which removes the last obstacle
in working with RGB in taproot.

Improved Lightning functionality

Support of the Lightning network was significantly improved in this release; including ability to
efficiently handle RGB assets after a non-cooperative channel closings and ability to handle
state channel updates which doesn't modify RGB state -- a feature important when you perform a
bitcoin payment inside an RGB channel, or when the channel operates multiple RGB assets.

Invoice changes

RGB20 fungible assets, alike many other token standards, may have a different precision, defining
the asset divisibility. For instance, Bitcoin has precision of 8 digits (1 sat = 0.00000001 BTC),
USDT -- 6 digits etc. RGB invoices specify the amount of the assets to transfer as an integer, i.e.
as an amount of the smallest asset units. This may confuse users, since the transfer of 100 USDTs
will specify 100000000 as the amount. In order to avoid the confusion, starting the beta 7 the
specific asset amount in the RGB invoices is encoded in a non-human readable form.

Other wallet improvements

Beta 7 adds support for Mempool extensions to the Esplora REST APIs, allowing using it as a backend
indexer for RGB wallets.

Many developers experience issues with Bitcoin Testnet, due to its spam pollution. A new proposal
of testnet re-load, named Testnet4, gains more and more traction. The current release adds support
of Testnet4 network to all RGB and wallet libraries.

In this version we also added ability to automatically resolve collisions between different
commitment methods which may happen due to user mistakes. Now, if your taproot-based wallet will
receive an RGB payment with non-tapret single-use seal (which may happen also due to an adversarial
payee) the wallet will be able to see and use those funds with no manual recovery or adjustments.

What's next

Beta 7 release continues a phase of preparation for a public preview of the RGB v0.11. All parties
are strongly recommended switching to this latest beta, which contains a number of critical bugfixes,
and provide us feedback their feedback.

Beta 7 was a result of internal audit and testing effort, we do together with [Bitfinex Labs], which
will continue with external audit in the following week. In this way we plan to ensure the system
security and safety before the final release.

You can track us on our journey towards v0.11 release with this GitHub dashboard.

Acknowledgements

We are grateful to Fulgur Ventures, continuing their multi-year support for our efforts in
developing RGB, as well as other Association members, including Bitlight Labs, who had become a
major contributor to RGB development. We are grateful to all commercial companies, building on RGB,
and providing their support, contributions and feedback, including Bitfinex, Pandora Prime, and
DIBA. We are also grateful for individual contributors, who do their small -- but still highly
valuable and welcomed input in making RGB better.

New Contributors

• @will-bitlight made their first contribution in #221

LNP/BP Standards Association is happy to announce the sixth beta release of RGB version 0.11.

The release marks a reference point for public audit of RGB v0.11. The APIs are now stable, and
feature-freeze has been reached: no further consensus-level or standard library breaking changes are
planned (unless they would become required as a result of newly discovered bugs/issues by the
community or auditors).

Our main focus with Beta 6 was:

• ensure with end-to-end tests that any execution routes and user stories doesn't contain bugs and
  preform correctly;
• refactor consensus and security-critical code in order to decrease its size and reduce potential
  attack surface as much as possible;
• make sure that RGB will be able to evolve in the future without introducing backward-incompatible
  changes.

All developers working with RGB are urged to update to the new version and use it to ensure
cross-application interoperability between assets, invoices, consignments and other RGB exchange
data.

Unless required, no further beta releases are planned and RGB v0.11 enters public testing and
pre-production preview cycle.

What's new in Beta 6

Beta 6 contain one of the largest changelog: we have fixed, closed and merged more than 120 issues
and pull requests. More than 20 engineers, both from LNP/BP Standards Association member companies
and independent third-parties has contributed since last Beta 5 release by reviewing, discussing and
proposing PRs to the RGB codebase across ~50 repositories related to the project.

The complete list of all closed issues and pull requests can be found on the [public RGB roadmap
page][proj]; below we review the most important of them:

Consensus-level changes

Beta 6 implements four proposals for consensus-level changes coming from the
[RGB change proposals][RCP]:

• [RCP-240227A]: Make timestamp part of genesis
• [RCP-240227B]: Make issuer identity part of genesis
• [RCP-240313B]: Move script and type libraries outside of schema, interfaces and operations
• [RCP-240326A]: Multiple metadata fields in contract operations

Other than that, we have:

• Moved information about asset tags, used in homomorphic encryption of the contract state, from
  standard library to contract genesis and adding them to the contract commitments; also
  significantly simplifying making contract operations which involve these tags;
• Improved multichain support, such that RGB contracts can run on top of multiple layer 1 soultions.
  This gives contract users ability to do cheaper and faster transactions using Liquid network,
  and benefit from the new client-side validated layer 1 called Prime, scheduled for the release
  later;
• New virtual machine op-codes for introspecting smart contract state and simplified branching
  op-codes making scripts more streamlined;
• More RGB macro assembly instructions allowing to write complex verification code;
• Improved checking and handling of strings with restricted character set, like the ones used for
  RGB20 asset tickers and names;
• Refactored mechanism for combining different types of single-use seals (like tapret- and
  opret-based) in inputs of a state transitions;
• Removed legacy schema inheritance feature in favor of new advanced interface inheritance, which
  is implemented outside of consensus code (see below).

Additionally, we have put a consensus changes required to make the following proposals
fast-forwards, which means that they can be implemented in a future releases (like v0.12 etc)
without consensus-breaking changes:

• [RCP-240313A]: SPV proofs for anchor transactions
• [RCP-240327A]: Computed state
• [RCP-240406A]: Fallback single-use-seal

We have also adjusted the complexity counter for reserved RGB op-code values, which ensures that
adding more op-codes to the virtual machine can be done in a backward-compatible manner.

Overall, with all those changes the size of consensus code in RGB Core library has decreased from
7170 to 6726 lines of Rust code (LORC), excluding comments and blank lines, which is
>6% reduction.

Interfaces and inheritance

Interface inheritance is the brand-new way of designing RGB smart contract interfaces which brings
much better modularity, audibility and upgradeability for the contracts.

Interfaces are defined at the level above consensus and specify how software or a user can interact
with a given contract. Interface defines a semantic for a business logic of a contract, and
contract developers write an implementations linking that business logic to the semantics. In
other words, interface explains to the user the meaning of a smart contract. One example is RGB20:
an interface (which becomes a family of interfaces in beta 6) which all contracts with a fungible
tokens can implement to be supported by any RGB wallet. The fact that interfaces are not a part of
the consensus level allows contract developers to gradually provide more and more advanced APIs
without a need to re-issue an assets or create new contract versions. On the other hand, users may
interact with smart contracts using newly released interfaces without the need of a wallet software
to be upgraded.

Previously RGB v0.11 beta 6 there were no interface inheritance, meaning that a contract can
implement a given interface only once; and must provide all of its functionality at once. Now, with
interface inheritance, this can become a gradual process. For instance, today RGB20 standard defines
what fungible assets can do. In a future a new features can be added to the standard (like reserves
or vesting), implemented as a new interfaces inheriting existing RGB20 interfaces and implemented
by existing assets which had that functionality in their business logic – and wallets will be able
to handle them in a correct way without any software upgrades.

As a part of the work on interfaces and inheritance, we have refactored the way errors can be
reported from smart contract validation scripts. Now, you can provide detailed error messages as
strings inside interface definitions and link them to raised errors via integer codes in
implementations.

At the same time interface inheritance brings much better modularity and audibility: you can compare
RGB20 standard
before the inheritance was introduced
and [now][RGB20].

We have re-implemented all previosly-defined interface standards (RGB-20, 21 and 25) as standard
sets ("families") of related interfaces and re-designed the APIs for working with them.

Finally, with beta 6 we added a number of interface and implementation integrity and validity
checks, which should simplify the work of developers and debugging.

The details of how the inheritance works can be found in
[RCP-240325A: Interface inheritance][RCP-240325A] proposal.

Invoicing

We also have made few changes to the invoicing. In RGB, invoices are form of URIs (like URLs), and
thus can be opened with one-click in your favorite wallet.

With beta 6 we changed the format for displaying asset amount inside the invoice. RGB20 standard,
like many other asset standards in other systems (ERC20 etc) allow to specify a precision for asset
amounts. Invoices contain information about the amount with no precision, creating a lot of
confusion for users, as well as a attack surface. Starting from the current release we hide the
amounts behind custom latin letter encoding (modified Base32 encoding with no numbers used),
removing the problem. To read an invoice a user must use wallet or other software, which will parse
it for the user using correct precision from the contract information. To simplify working with such
amounts we provide a new CoinAmount type which embeds information about precision and is handy for
presenting asset values in the UI.

Finally, invoices has changed they way a pay-to-address requests are handled. Previously, an
explicit bitcoin address was used; now we standardized that with usual blind seal definitions using
the same encoding, chunking and supporting incorporation of custom seal close method information.

Last, but not least, we have optimized identities we use across RGB (like contracts, interfaces etc)
– it was switched from Baid58 to Baid64 encoding, which resulted in shorter fixed-length identifiers,
robust chunking, and solved few issues with its URI standard compatibility and chunking.

Data containers

With client-side validation, all the contract state, new state transitions and history are sent
between peers, in a P2P way. This is quite different from the blockchain-bases systems and require
specific methods of storing and sharing the data: data containers.

There are several types of data containers in RGB. In v0.11 beta 6 we have put a lot of
optimizations into the way containers work, making them more compact and secure.

Previously, information for smart contract developers – interfaces, schemata and interface
implementations were always present as a separate files. With beta 6 we introduce kits: new data
container type which may store multiple interfaces, schemata, implementations and other data in one
single package. We have also made sure that repeated information – like data type or script
libraries which can be re-used by different interfaces and contracts – is shipped only once,
reducing the size of data containers for about a dozen of percents.

Another type of data containers are consignments, used to distribute smart contracts, assets and do
transfers. Consignments has also become smaller, since they also include all related interfaces and
implementations and thus do benefit from aggregation of data type and script libraries.

Previosly containers were packed with mechanism called bindles. With beta 6, we deprecate...

LNP/BP Standards Association is happy to announce the fifth beta release of RGB protocol version 0.11.

This is another milestone on the stabilization of the new v0.11 RGB version. It is the first
complete beta release of both consensus-level libraries, standard libraries and tools happening
in 2024, opening a way for independent developers integrating with RGB to test all the new
functionality.

What's new in Beta 5

In preparing Beta 5 release we were focusing on performing internal audit of all consensus-critical
code, ensuring both its security and ability to do a protocol upgrades in the future versions
without introducing any incompatibilities with the assets and software using v0.11.

The internal audit was performed by two teams: the dev team and documentation team. The developer
team was reviewing the source code and modelling different types of attacks; while the doc team
was independently creating formal specification explaining how the protocol actually works (basing
on the source code), which was later compared to the expected protocol behaviour.

Let's walk through the major areas of the improvements shipping in v0.11 beta 5.

Commitments

Cryptographic commitments, which go into Bitcoin blockchain in hidden form, are the core of RGB
security and anti-double-spending protection. They are a part of so-called “single-use seals”,
which you may have heard of before.

During the last three months (since Beta 3) we have passed through an extensive internal audit
of the commitment procedures and wrote a lot of tests. We have improved the security and safety
of many aspects of them and made sure they will be a proper foundation for the RGB.

One of the main changes which the end-users will notice is that now contracts (and assets) will
commit to the issuer identity, simplifying the verification by the wallets and preventing scam
attacks.

Contractum language and scripting

With v0.11 one of our main focuses was simplification of RGB developer experiences.

First, we have introduced more opcodes allowing scripts in RGB contracts to access the contract
state and use that information in validation. We have also developed RGB assembly, which can be
compiled using macro rgbasm directive right from the Rust!

Finally, we are moving fast in finalizing the initial Contractum version: the language intended
for RGB smart contract developers. In this release we add a Contractum representation for all
standard interfaces used by RGB (RGB20 fungible assets, RGB21 NFTs and RGB25 fungible collections).

Wallet functionality

With v0.11 RGB is integrated with wallet functionality out of the box. This solves one of the
major dev and user headaches.

With Beta 5, we are going even further: now the command-line tool and RGB runtime can filter and
present the information specific to a wallet of user choice and ignore the rest of the contract
state.

Another new feature is the support for legacy Electrum RPC API, in addition to Esplora REST APIs,
supported before.

Containers

In this beta we have refactored the concept of containers. Containers are they way user exchange
RGB data, for instance when they do distribute assets, perform transfers, -- or when developers
distribute new code and interfaces for asset issuers.

In Beta 5 we have improved ASCII armoring of container data, so all of them now use more compact
Base85 encoding and standard set of headers. We have simplified programming API for working with
containers, and made sure their IDs are uniquely reflect their content - such that even the same
contract disclosing different parts of information will have a distinct id.

We also simplified a life of devs and testers by providing an ability to convert any container
into a human-readable YAML representation, edit it and convert back into a binary form, which
can go into RGB system. This will simplify audit and debugging, allowing us to model different
kinds of attacks on the system.

Details on changes in this repository:

• Release v0.10.1 by @dr-orlovsky in #28
• Fix force accept of invalid consignments by @dr-orlovsky in #29
• Initial work on v0.11 by @dr-orlovsky in #25
• Support for YAML export for consignments and stash dumps by @dr-orlovsky in #31
• fixed crates.io link by @ftdgoodluck in #34
• Support for asset tags by @dr-orlovsky in #36
• Use automatic asset tags by @dr-orlovsky in #38
• Command-line improvements by @dr-orlovsky in #37
• Select correct assignment name by @crisdut in #68
• Ongoing bugfixing work for v0.11 release by @dr-orlovsky in #80
• Update secret seals to be cross-chain by @dr-orlovsky in #81
• Support WPKH descriptors by @dr-orlovsky in #88
• Fungible operation history by @dr-orlovsky in #92
• invoice error for blind with no outpoint by @nicbus in #123
• Fix opret support in construct_psbt() by @dr-orlovsky in #130
• Add electrum support by @dr-orlovsky in #131
• Complete YAML inspection for consignments and stash by @dr-orlovsky in #140
• Support reconstruction of consignments using new ASCII armoring by @dr-orlovsky in #143
• replace electrum-client with bp-electrum by @zoedberg in #150
• complete electrum support by @nicbus in #142
• replace panic with error for unsupported layer1 by @zoedberg in #152
• docs: RGB Wallet (CLI) Manual by @bitlightlabs-dev in #153
• Pay: fix duplicated PSBT inputs by @dr-orlovsky in #136
• Update to match the refactored interfaces by @dr-orlovsky in #154

About RGB v0.11

RGB v0.11 is an evolution of the protocol coming with a lot of bug fixes and improvements, further
enhancing RGB smart contracting capabilities. It will be the first version which will be audited by
independent auditors, after which it can be considered by third-party issuers for the use in
production.

The main features shipping in v0.11 will be:

• Wallet integration right into RGB runtime and command-line tool;
• Basic support for Liquid sidechain, with ability to add more alternative scalability layers in the
  future;
• Scripting, with new state introspection codes and RGB assembly compiler;
• Initial support for Contractum language;
• Ability to inherit interfaces (multiple inheritance!);
• Support of Electrum RPC additionally to Esplora REST, present before;
• Commitments to issuer and developer identities embedded into contracts, interfaces, libraries;
• More compact consignments and better ASCII armoring.

What's next

With Beta 5 release RGB development enters a new phase of preparation for a public preview of
the RGB v0.11. The public preview will be a feature-complete version which will be used by
external auditors for evaluating the safety of the protocol. At the same time app devs and users
will be able to complete integration of RGB without expecting major API or consensus break with
the release.

Once there will be results of an audit, the preview version will become an official release (if
the audit will find any major issues however, they will be fixed even if the fixes will contain
a breaking changes).

You can track us on our journey towards v0.11 release with this GitHub dashboard.

Acknowledgements

We are grateful to Fulgur Ventures, providing another year of support for our efforts in
developing RGB. This year they were joined by Bitlight Labs, who had become a new full member of
the Association.

We have received a number of important contributions and bugfixes coming from commercial
companies, such as Pandora Prime, Bitfinex and DIBA. We are also grateful for individual
contributors, who do their small -- but still highly valuable and welcomed input in making RGB
better.

New Contributors

• @ftdgoodluck made their first contribution in #34
• @bitlightlabs-dev made their first contribution in #153

Full Changelog: v0.10.0...v0.11.0-beta.5

It's been 5 month since the first alpha of RGB v0.10 - and today we a thrilled to make a final release of the RGB command-line tool and runtime library for desktop and mobile integration. The library was extensively tested by several independent teams and powers three different wallets (MyCitadel on Desktop, Iris on Android, BitMask in Web); it also has stable results on end-to-end tests, including performing multiple complex transfers of multiple assets.

What's Changed since alpha:

• Get correct server parameters by @crisdut in #6
• Add default resolver for regtest by @nicbus in #7
• Fix spelling by @rct-k in #11
• Add set-host command by @nicbus in #14
• Fx for consecutive transfers (dependency update) by @dr-orlovsky in #13
• Resolver Height (get by spent script) by @crisdut in #15
• Update to the resolver new APIs by @dr-orlovsky in #21
• Remove required electrum resolver by @dr-orlovsky in #23
• Update README.md by @Dimi8146 in #5

Full Changelog: v0.10.0-alpha.1...v0.10.0

Initial release of RGB library and command-line tool