Presentation of the first multisig wallet on RGB - specially for companies and issuers - on the stage of #BH2025

10 thousand followers - in just two weeks after the launch of our Consortium. Thanks to the community for such an interest to the technology! Let’s grow the community together: follow @rgbconsortium and join the revolution!

An official security notice on RGB fork claimed to be 'RGB v0.11.1' It has come to our attention that the recently announced "release" of "RGB protocol version 0.11.1" runs a fork of RGB v0.11 from unreleased last year codebase, with heavily modifications to the consensus, affecting its security. These modifications were proposed to the main RGB repositories but didn't meet our security requirements and were of poor code quality. Specifically, its unit test coverage is nearly absent (compared to the full test coverage of v0.12 released by us recently, see the image in the full announcement below); it lacks a lot of functionality specific to zk support; it has removed smart contracting capabilities; has heavy performance and scalability issues etc. Thus, while as a free (libre) software project we do not oppose experiments and fork, we can't prevent possible malicious fork code from entering these forks, nor can't prevent users from using the forked code. Thus, we do not advise any production use of version 0.11.1; the only version recommended by us for the production is v0.12 from github.com/RGB-WG organization. Companies may check whether the forked and changed consensus is used in their dependency trees by running cargo tree -i rgb-consensus, which will show whether the forked and modified version of official rgb-core consensus crate is being used. If this is the case, we recommend to update the software or do not use in production. We also advise users NOT to use products built with version v0.11.1 and modified consensus for any assets or purposes with any real value. We also recommend to change the name of the forked version from RGB Protocol, to avoid user confusion and misguidance. In any case, if a loss of assets would happen, neither the real RGB protocol, nor LNP/BP Standards Association or RGB Consortium can be blamed for it (with claims alike "it is based on your code"), giving the facts that that code was never released and recommended by us for the production, and dramatic scale of consensus modification and code changes made in the fork. We will also not support the forked version of RGB as we do not have any resources to perform its audit or analysis; and the fork maintainers are not interested in our critics, rejecting a normal route of PR peer reviews. You can also read this announcement here: rgb.tech/blog/on-rgb-fork-by…

We are happy to announce formation of the RGB Consortium: the official non-profit body acting as an industrial consortium, which will take over the maintenance of RGB protocol and will steward its further development.