The LNP/BP Standards Association is excited to announce the final production-ready release of the RGB smart contracts consensus layer (v0.12)!
From today, all RGB contract developers and issuers can deploy contracts on both testnet and Bitcoin mainnet using this stable consensus release.
⚠️ Important: For security and ecosystem consistency, we strongly recommend re-issuing any contracts created with pre-release versions using this final v0.12.
🛠️ Please note:
This is a consensus layer release. It will be followed by releases of the standard library and applications. The consensus layer is unique among RGB libraries because it defines contract stability: only changes at the consensus level can break backward compatibility for contracts. Therefore, with this final v0.12 release, contracts are now forward-compatible.
Read the full release details on https://rgb.tech/blog/release-v0-12-consensus/
I'm curious about RGB. It's been around for a long time now, and while I can find a number of articles that explain what it is, it seems like adoption hasn't been very strong. I'd be interested to read a fair critique of it. Why isn't it more widely in use?
The main reason of its not being used is the fact that it was not released for production (until today). Consensus in client-side validated systems (RGB belongs to them) is kind of ossified from the day one when you start using in production; it is much harder to change that than blockchain consensus. Thus, it took many years to build a system which has everything needed, including zk-STARK readiness.
I am quite sure we will see a boost in RGB adoption over the next months after the release.
Wow, this is pretty exciting! I'll be quite interested to see what kind of consumer applications take it up.
My money is on more shitcoins, but I hope to be mistaken
Not just shitcoins. Also:
With Prime (client-side validation layer 1):
And yes, there is bitcoin trustless bridging to RGB and Prime - with Radiant and/or BitVM (whatever happens first).
cool, thanks! I've been trying to follow this some time ago. will look more closely now.
Can you speak more about this?
The problem solved by Alice sending BTC to Dan via USDT on the route is utilization of additional liquidity which will be present in LN only with RGB.
PPM fee still will be lower than onchain tx fee if liquidity is just not there and Alice can't pay Dan
Free option problem is always there in any atomic swap protocols; the way to mitigate it is just to set a proper CTV timeout and experience more failures.
There is no free option in atomic swaps on sideswap.io
on LN, even 1 block CTV is enough to be exploited
Right now the only liquidity present in Lightning network is BTC liquidity.
Yet stable coins (like USDT) has much more liquidity (most of BTC is on long-term holding and thus non-liquid, and would never touch LN). Once they come into lightning channels payments can be routed through channels with no BTC liquidity (but with USDT etc), converting on-the-fly; so BTC payment may pass through such channels in a transparent way.
This on-the-fly converting idea is nonsense. Who would want to cross two bid/ask spreads to receive x% less? And who would dare to be an exit node and be picked off by free option? I will be the first to game them. Maybe native USDT channels will work, but that will require a whole alternative LN, with rebalancing pain etc. USDT on Liquid does the job great right now, with cheap confidential payments and atomic swaps to/from BTC.
Why is that? Is it a technical reason?
Yes, there is a pure technical reason.
In client-side validation there is no P2P network like in blockchain; you validate only part of the global history and state directly related and interested to you. Thus, if somebody in that history uses something which was valid for him, and you have a newer software in which this have become invalid (like in soft-fork in bitcoin blockchain), you will decline these data, meaning that that part of the history will be lost forever after such a change.
Also, in bitcoin blockchain you can target update events using blockchain as a Time Machine; in client-side validation there is no full order of events and you can't say that "After time point X a thing becomes valid/invalid", so no means of coordinating updates.
I am also first time hearing about the term.
How does client-side validation work?
I vaguely remember that one critique was that true consensus is impossible because there is no global state. One asset can be sold to two other participants, and they won't know it is a double-spend unless they talk to each other.
But later, I read somewhere you said you solved this.
Do you know what I am referring to? If so, can you elaborate a bit?
Yes, there is clearly a global state; first right in the contract you have its explicit, and you may distribute information about it with any data availability layer (without additional consensus), like Nostr (we also work on a dedicated DA called Storm)
Where can we read more on RGB and how it helps? I don't know anything about this.
https://rgb.tech
Thank you!
Great! Excited to see RGB contracts now stable on mainnet. Looking forward to the upcoming standard library and app releases.
This is exciting tech. With level of maturity, I can see a new wave of federated stablecoins forming—assets like USDT or precious metals, but without the centralization risk. Built on Bitcoin is the icing on the cake. Curious who else here is building in this direction?
This is not just a version release. This is the moment smart contracts on Bitcoin become unbreakable. v0.12 isn’t an update — it’s a declaration of stability. RGB just crossed the Rubicon.
Thanks Chad Orlovsky
Props to the RGB team for making this a reality. This is a game changer and will be huge for asset issuance on Bitcoin/Lightning. Can't wait to use this - so many possibilities
Awaiting iOS apps that use RGB!
At https://pandoraprime.ch we plan to launch https://raywallet.app iOS wallet in August for internal testing and around September for public.
Ahh I had the test flight of that Wallet I had nothing to do with it
Yes, it was an early demo during Lugano Plan B which was working only peer-to-peer through QR code or mesh network (i.e. when you are next to each other).
The new version will support remote invoicing.
I’m excited let us know when it drops I will test it and provide feedback
I have seen that RGB has gone through several iterations to reach its current version. Are the available documentation and other resources (e.g., youtube videos) still all relevant to the v0.12 production release?
It got outdated. But we are working on new - and here are some of the results: #1061436
Good
Sounds interesting. Never looked this deep into this. Can't wait to try it.
Good
In non-technical terms, how does the zk-Stark keep information private for users?
Well, the privacy is one of the purposes why we use zk-STARKs :)
A major milestone for the RGB ecosystem! Having stability at the consensus layer paves the way for real adoption without fear of breaking changes. Congrats to the team!
estou apredendo sobre o que é bitcoin e estou gostando da ideia
🚀 Huge milestone for the RGB ecosystem! Congratulations to the LNP/BP Standards Association on the stable release of the RGB smart contracts consensus layer (v0.12)! This marks a major step toward scalable, privacy-preserving smart contracts on Bitcoin. 🔒⚡
A reminder to all devs: re-issue any contracts created on pre-release versions to ensure compatibility and security. Looking forward to the upcoming releases of the standard library and apps! 👏💥
I'm a total noob at this. How would you convince me to use this tech? What kind of guarantees do people get from the data stored on the Bitcoin blockchain, and how does that even work?
For real
Fake
Wow that’s wonderful
oh wow
I'm very curious
RGB smart contracts are finally live and stable with the v0.12 release — devs can now deploy on both testnet and mainnet confidently. If you used any earlier versions, it’s best to re-issue your contracts to stay secure and future-proof. This is the foundation layer, so big things are coming next.
Big news the RGB smart contract consensus layer (v0.12) is finally out and ready for mainnet! If you’ve been testing or issuing contracts with earlier versions, it’s best to re-issue them now to stay secure and compatible going forward. This release locks in the core rules, so contracts built on it won’t break with future updates. Excited to see what devs build from here!
Huge milestone for the RGB ecosystem! This final v0.12 consensus layer release brings true stability and forward compatibility — a big win for developers and future contract issuers. Kudos to the team for pushing Bitcoin smart contracts forward the right way. Can’t wait for the upcoming standard library and apps!
This is a major milestone for Bitcoin-based smart contracts! With RGB v0.12 now production-ready, we're finally seeing a stable foundation for truly scalable, private, and off-chain smart contracts .. all secured by Bitcoin.
The emphasis on reissuing pre-v0.12 contracts is a crucial reminder: consensus-level stability matters more than flashy dApps. Looking forward to how builders will now push innovation forward, especially as the standard library and app layers follow soon.
RGB isn't just catching up .. it's redefining how we think about smart contracts on Bitcoin.
#Bitcoin #RGB #SmartContracts #DecentralizedFuture