Can RGB replicate the Ordinals craze?
TechFlow Selected TechFlow Selected
Can RGB replicate the Ordinals craze?
This article compares Ordinals and the RGB protocol in terms of security, scalability, transaction fees, and transaction speed, and analyzes potential future developments of the RGB narrative.
Navigating Web3 tides with focused insightsAuthor: Jerry Luo
Reviewers: Mandy, Joshua
TL;DR
There are currently multiple smart contract schemes on the Bitcoin network, with the most mainstream being the Ordinals protocol and the RGB protocol.
The emergence of the Ordinals protocol enables smart contract development on the Bitcoin network, binding its security to the Bitcoin blockchain. However, Ordinals asset transfers are confirmed and recorded directly on the Bitcoin mainnet, tied to the transfer of a single satoshi. This results in high transaction fees and further congests the already low-TPS Bitcoin mainnet.
The RGB protocol introduces off-chain channels and batched transaction packaging, significantly reducing transaction fees and increasing speed for asset transfers. Additionally, client-side validation greatly reduces the amount of data required to maintain network operations, improving scalability.
However, while RGB improves upon Ordinals, it also introduces new challenges. Off-chain channels optimize cost and speed but raise concerns about the security of off-chain records. Client-side validation reduces data storage needs but significantly slows down verification speed.
This article compares the Ordinals and RGB protocols from dimensions such as security, scalability, transaction fees, and transaction speed, and analyzes potential future developments of the RGB narrative.
1. Market Overview
Currently, BTC accounts for around 49% of the total cryptocurrency market capitalization. However, due to its scripting language lacking Turing completeness, absence of native smart contracts on the mainnet, and slow transaction speeds, its long-term development faces serious obstacles. To address these issues, Bitcoin developers have made extensive attempts at scaling and speeding up the network, primarily through the following four solutions:
RGB Protocol: RGB is a Layer-2 protocol built on the Bitcoin network, with core transaction data anchored on the BTC mainchain. Leveraging Bitcoin's security model, RGB supports creating tokens with customizable attributes and smart contract functionality on Bitcoin. Initially proposed by Peter Todd in 2016, the RGB protocol regained attention in 2023 amid growing enthusiasm for smart contract ecosystems on Bitcoin.
Segregated Witness (SegWit): In August 2017, Bitcoin implemented the SegWit upgrade. By separating transaction data from signature data, it effectively increased block capacity from 1MB to 4MB, partially alleviating congestion. However, limited by Bitcoin’s inherent block size constraints, this method of expanding block storage has reached its limits.
Lightning Network: The Lightning Network is a Layer-2 scaling solution enabling off-blockchain transactions, greatly enhancing throughput. It has been deployed on the Bitcoin mainnet, with existing implementations including OmniBOLT and Stacks. However, the Lightning Network faces significant centralization risks.
Sidechain Technology: Sidechains operate external chains pegged 1:1 to BTC. They offer improved transaction performance compared to the mainnet but can never match the security level of the Bitcoin mainchain.
Since March this year, both transaction fees on the Bitcoin network and trading volumes of BRC20 assets have surged. In early May, BTC mainnet transaction fees peaked. Although fees have since declined, BRC20 trading volume remains high. This indicates that developer interest in building smart contract ecosystems on Bitcoin has not waned despite cooling excitement around inscriptions, and efforts continue to find optimal approaches for Bitcoin-based smart contract development.
2. Ordinals Protocol
2.1 Satoshi Numbering
Satoshi units on the Bitcoin network differ from Ethereum's wei, which are recorded purely as data. Instead, sats are calculated based on the UTXOs held by each address. To distinguish individual sats, we must first differentiate between UTXOs, then identify sats within the same UTXO. Differentiating UTXOs is relatively straightforward—each mined UTXO corresponds to a unique block height. Since mining creates the initial sats, only coinbase transaction UTXOs need numbering. The real challenge lies in numbering sats within a single UTXO. The Ordinals protocol proposes a novel solution using a first-in-first-out (FIFO) principle.
Differentiation of UTXOs: BTC Builder tracks UTXOs from their creation, where each UTXO belongs to a specific block with a unique block height on the Bitcoin network. These distinct heights allow differentiation between UTXOs.
Differentiation of Sats Within a UTXO: Block height determines the approximate range of sats within a UTXO. For example, the earliest block could mine 100 BTC, or $10^{10}$ sats. Thus, sats in block height 0 are numbered \[0, 10^{10}-1\], those in block height 1 are \[10^{10}, 2×10^{10}-1\], and block height 2 contains sats numbered \[2×10^{10}, 3×10^{10}-1\], and so forth. To precisely identify a specific sat within a UTXO, the spending process must be tracked. According to the FIFO rule in the Ordinals protocol, earlier outputs in a transaction consuming this UTXO receive sats with lower ordinal numbers. For instance, if miner A, who mined block height 2, transfers 50 BTC out of 100 to B, with A receiving the latter output, A retains sats numbered \[2×10^{10}, 2.5×10^{10}-1\] while B receives sats numbered \[2.5×10^{10}, 3×10^{10}-1\].
2.2 Ordinals Inscription
Bitcoin originally allowed an 80-byte data space per transaction via the OP_RETURN opcode. However, this small space cannot accommodate complex logic, and writing data to the blockchain increases costs and risks network congestion. To resolve this, two soft forks were introduced: SegWit and Taproot. Using a Tapscript script prefixed with the OP_FALSE opcode (which does not execute), Bitcoin now provides a 4MB space within transactions. This area allows inscription of ordinals data, enabling text, images, or BRC20 token issuance on-chain.
2.3 Limitations of Ordinals
While Ordinals greatly enhance Bitcoin’s programmability, breaking limitations in BTC’s ecosystem narrative and development, several issues remain heavily criticized by BTC developers.
Centralization Risks of Ordinals: Although state recording and updates occur on-chain, the security of the Ordinals protocol itself cannot be equated with that of the Bitcoin network. Ordinals cannot prevent duplicate inscription uploads, and identifying invalid inscriptions relies on external Ordinals protocol layers. As a relatively new protocol lacking long-term testing, many potential vulnerabilities exist. Moreover, failures in the underlying Ordinals infrastructure could lead to user asset losses.
Limited Transaction Fees and Speed: Since inscription engraving occurs within the segregated witness area, transferring an Ordinals asset requires spending a UTXO. Given Bitcoin’s ~10-minute block time, transaction acceleration is impossible. Furthermore, inscription recording inherently increases transaction costs.
Compromising Bitcoin’s Original Properties: Because Ordinals assets are tied to valuable sats on the Bitcoin network, their usage inherently alters Bitcoin’s native assets. Additionally, inscription minting drives up miner fees. Many BTC supporters fear this may undermine Bitcoin’s original payment functionality.
3. RGB Protocol
Under conditions of surging network traffic, the shortcomings of the Ordinals protocol become evident. Long-term, without proper resolution, Bitcoin’s smart contract ecosystem will struggle to compete with Turing-complete public chains. Among various alternatives to Ordinals, many developers have turned to the RGB protocol, which achieves significant breakthroughs over Ordinals in scalability, transaction speed, and privacy. Ideally, Bitcoin-based assets built on RGB could achieve performance levels comparable to assets on Turing-complete blockchains.
3.1 Core Technologies of RGB
Client-Side Validation
Unlike Bitcoin’s broadcast model for transaction data, RGB moves this process off-chain, transmitting information only between sender and receiver. After validating a transaction, the recipient does not need to synchronize across all nodes or store every transaction like on Bitcoin. Instead, receiving nodes only record data relevant to the transaction—just enough to support future on-chain verification. This improvement dramatically enhances network scalability and privacy.
One-Time Seals
In real-world document submissions, materials often pass through multiple hands, threatening authenticity and integrity. To prevent tampering before verification, physical seals are used—integrity of the seal implies content integrity. The one-time seal in RGB serves a similar purpose, implemented practically via Bitcoin’s naturally one-time-use digital seals: UTXOs.
Similar to Ethereum smart contracts, issuing tokens under RGB requires specifying name and total supply. However, unlike Ethereum, there is no dedicated blockchain hosting RGB tokens. Each RGB token must correspond to a specific UTXO on the Bitcoin network. Owning a particular UTXO on Bitcoin means owning the corresponding RGB token recorded under RGB. To transfer an RGB token, the holder must spend that UTXO. Due to the one-time nature of UTXOs, once spent, they are gone—equivalent to “spending” the RGB asset. Spending the UTXO is thus equivalent to breaking the one-time seal.
UTXO Blinding
On the Bitcoin network, every transaction clearly links input and output UTXOs. This improves traceability and prevents double-spending, but full transparency compromises user privacy. To enhance privacy, RGB introduces blinded UTXOs.
During an RGB token transfer, sender A does not learn the actual receiving UTXO address. Instead, A receives only the hash of the receiving address concatenated with a random secret value. When receiver B wants to use the received RGB token, B must provide both the UTXO address and the secret value to the next recipient C, proving that A indeed sent the token to B.
3.2 Comparison Between RGB and Ordinals
Security: Every Ordinals smart contract transaction or state transition requires a UTXO spend on-chain. In contrast, RGB leverages Lightning Network or off-chain RGB channels extensively. Most RGB transaction data is stored locally on clients (local cache or cloud servers), introducing high centralization risk—data could be exploited by centralized entities. Additionally, server outages or local cache loss could result in irreversible asset loss. From a security standpoint, Ordinals holds an advantage.
Verification Speed: Since RGB uses client-side validation, verifying a transaction requires reconstructing its entire history from scratch, confirming every prior step in the RGB asset transfer chain. This process consumes substantial time, significantly slowing verification. Therefore, Ordinals outperforms RGB in verification speed.
Privacy: RGB asset transfers and validations occur entirely off-chain, establishing a private channel between sender and receiver. Combined with UTXO blinding, even senders cannot trace the destination of UTXOs. In contrast, Ordinals transfers rely on visible UTXO spends on Bitcoin, where inputs and outputs are publicly queryable—offering no privacy. Hence, RGB offers superior privacy.
Transaction Fees: RGB transfers largely occur via client-managed RGB channels or the Lightning Network, incurring nearly zero fees. Regardless of intermediate transactions, only one final UTXO spend anchors the state on-chain. In contrast, every Ordinals transfer must be recorded in tapscript, plus inscription costs, leading to significant fees. Additionally, RGB supports batched transactions—one tapscript can designate multiple recipients—while Ordinals defaults to one-to-one transfers. RGB’s batching capability drastically reduces per-transfer costs. Thus, RGB has a clear fee advantage.
Scalability: In RGB smart contracts, transaction validation and data storage are handled by clients (receiving nodes), not on the BTC chain. There is no need for broadcasting or global consensus on the mainnet—each node only stores minimal, relevant data. Conversely, Ordinals requires all inscription data to be permanently on-chain. Given Bitcoin’s inherent processing speed and scalability limits, its capacity to handle transaction volume is severely constrained. Therefore, RGB excels in scalability.
4. RGB Ecosystem Projects
Following the release of RGB v0.10.0, developer experience on the RGB network has improved significantly. As such, large-scale development of the RGB ecosystem has only begun within the past six months, and most projects listed below are still in early stages:
Infinitas – Infinitas is a Turing-complete application ecosystem on Bitcoin, combining the strengths of the Lightning Network and RGB protocol to create a more efficient Bitcoin ecosystem. Notably, Infinitas proposes recursive zero-knowledge proofs to address inefficiencies in client-side validation. If successfully implemented, this could substantially resolve RGB’s current verification speed bottleneck.
RGB Explorer – One of the earliest browsers supporting RGB asset queries and transfers (for fungible and non-fungible tokens), supporting RGB20, RGB21, and RGB25 standard assets.
Cosminmart – Essentially a Bitcoin Lightning Network compatible with RGB, aiming to build a new smart-contract-enabled Bitcoin ecosystem. Unlike other single-purpose projects, Cosminmart offers wallet services, derivatives markets, and early-stage project discovery—providing end-to-end support from development to product launch and trading.
DIBA – Leveraging both Lightning Network and RGB, DIBA aims to build an NFT marketplace on Bitcoin. Currently operating on Bitcoin testnet, it is expected to launch on mainnet soon.
5. Future Outlook for RGB
With the release of RGB v0.10.0, the protocol’s overall framework has stabilized, and backward-incompatible changes during updates are being gradually resolved. Developer tools and APIs are maturing, significantly lowering the barrier to building on RGB.
Today #Tether announces the ending of the support of 3 blockchains $USDt: OmniLayer, BCH-SLP and Kusama. Customers will be able to continue to redeem and swap $USDt tokens (to another of the many supported blockchains), but Tether won’t issue any new additional $USDt on those 3 blockchains.
Recently, Tether officially announced migrating its USDT contract deployment from OmniLayer to RGB on the Bitcoin Layer-2 network. This move is seen as a signal of major crypto players entering the RGB ecosystem. RGB now boasts a mature development protocol, a growing developer community, and recognition from industry giants. Finally, RGB developers are exploring recursive zero-knowledge proofs to compress client-side validation data. If successful, this would greatly accelerate verification speed and alleviate network latency issues under large-scale adoption.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Kernel Ventures
