RGB v0.11.1 vs v0.12: Why Developers Are Building on v0.11.1

RGB v0.11.1 vs v0.12 — production ready comparison for developers

Comparing RGB v0.11.1 vs v0.12? If you are building on RGB Protocol on Bitcoin, the answer is v0.11.1. Here is why.

Is RGB v0.11.1 production ready?

RGB v0.11.1 is already running in real-world applications: Iris Wallet, BitMask, KaleidoSwap, LNFI, and Utexo are all built on it and are actively used on mainnet. The rgb-lib library makes integration straightforward, with support for multiple programming languages beyond Rust.

v0.12, by contrast, has not been integrated in any Lightning Network application. Critical Lightning-related tests remain disabled in the v0.12 test suite, including ln_transfers, collaborative_transfer, mainnet_wlt_receiving_test_asset, and UDA support tests. The PR updating rgb-tests to v0.12 is still a draft and does not run CI. Lightning compatibility is a core use case of RGB: not being tested on it represents a significant gap.

What is RGB v0.12 and why isn’t it ready for production?

Every major rewrite in RGB’s history — v0.9, v0.10, v0.11 — introduced bugs and regressions. v0.12 is another substantial rewrite of core logic, introduced without a sufficient suite of integration tests to validate the new architecture. Many integration tests from v0.11.0-beta.9 were removed or rewritten in v0.12, reducing confidence in detecting regressions.

The rgb-protocol team had spent years auditing the codebase up to v0.11.0-beta.9. Switching to v0.12 would have required months of re-auditing a substantially different codebase, with no clear technical benefit to justify the cost.

How does RGB v0.11.1 compare to v0.12’s claimed improvements?

“zk-STARK integration” — to our knowledge, only preparatory work has been done. Actual ZK integration still requires substantial development and may involve breaking changes. It is not a working feature today.

“Protocol simplification” — v0.12 removed features that are essential in v0.11.1: multiple transitions per contract and concealed transitions. They are critical for schema expressiveness and user privacy. The code reduction is approximately 7%, not enough to justify removing them. We are working on a 0.11 code cleanup, which should make the resulting codebase smaller than the current v0.12.

“Better auditability” — the rgb-protocol team disagrees. v0.12 is harder to audit because consensus and validation logic are now spread across multiple repositories. In v0.11.1, critical logic is centralized, which makes it easier to review and test rigorously.

“Better performance” — no benchmarks, test results, or technical metrics have been provided on v0.12 to support this claim.

“Better developer experience” — v0.12 introduced incompatible changes that forced existing integrations to be largely rewritten. v0.11.1, by contrast, has a growing ecosystem of libraries and tools that lower the barrier to adoption.

How does RGB v0.11.1 approach test coverage and security?

The rgb-protocol team prioritizes validation attack tests over unit test coverage. In a multi-repo ecosystem like RGB, integration tests are more reliable indicators of correctness than isolated unit tests. Unit tests are useful for anti-regression during refactoring, but they are not a meaningful security metric.

The v0.12 unit tests currently in rgb-core, despite achieving high code coverage, do not adequately cover consensus-critical logic or potential validation attack vectors.

v0.11.1 validation attack tests are actively developed at github.com/rgb-protocol/rgb-tests. Meanwhile, we are also building up unit test coverage, but with slightly lower priority.

RGB v0.11.1 vs v0.12: which version should developers build on?

The choice in the RGB v0.11.1 vs v0.12 debate comes down to one factor: production readiness. v0.11.1 is audited, tested in production, and supported by the RGB Protocol Association.

Documentation: docs.rgb.info

Start building:

Core repositories: github.com/rgb-protocol · github.com/RGB-Tools

Similar Posts

Leave a Reply