Interview with Cipher, the Proposer of RGB++: RGB++, UTXO, and BTCFi in My Eyes
TechFlow Selected TechFlow Selected
Interview with Cipher, the Proposer of RGB++: RGB++, UTXO, and BTCFi in My Eyes
Cipher discusses his personal background, the unique significance of RGB++ Layer and the UTXO model for BTCFi, as well as some questions and perspectives regarding CKB and the Bitcoin ecosystem.
Navigating Web3 tides with focused insightsGuest: Cipher
Interviewer: Geek Web3
On July 22, 2024, Geek Web3 had the privilege of inviting Cipher, co-founder of CKB and proposer of RGB++, for an in-depth discussion on RGB++ and the UTXO system, CKB itself, and the Bitcoin ecosystem. Cipher shared insights into his personal journey, the unique significance of the RGB++ Layer and UTXO model for BTCFi, as well as his perspectives on CKB and the broader Bitcoin ecosystem. The specific topics covered in this interview include:
-
Cipher’s personal background
-
The relationship between UTXO Stack and RGB++ Layer
-
Views on Bitcoin Layer2 and BTCFi, especially EVM-based Layer2 solutions
-
Unique use cases and development philosophy of RGB++ Layer compared to EVM-based systems
-
Interpretation of CKB's core design principles
-
How to address certain limitations of the UTXO model in DeFi ecosystem development
-
Why CKB chose RISC-V and related smart contract language choices
-
Comparison of decentralization in Bitcoin and Ethereum ecosystems
Below is the full transcript of the interview. We welcome you to read it carefully.
Faust: Let's start with Cipher introducing yourself?
Cipher: I first got into blockchain back in 2013 through Bitcoin mining. At that time, mining wasn’t as competitive—unfortunately, my first ASIC purchase was from a dishonest vendor. By 2014–2015, due to Bitcoin's high volatility, I wrote an automated trading bot and made some profits. When the bear market hit at the end of 2015, I temporarily left the crypto space—I didn't have strong conviction then; it was purely speculative.
In 2016, I officially entered the blockchain industry, joining a state-affiliated blockchain research institute where I worked on the central bank's digital currency and consortium chains as a product lead. During that time, I authored several whitepapers, early privacy protection frameworks, and patents related to digital property rights.
By 2018, I realized consortium chains were fundamentally flawed: every consortium has a dominant leader, and if there's a central authority, there's no real need for blockchain. State-backed consortium chains are even less meaningful—they’re just centralized monologues. After that, I shifted focus to permissionless public blockchains. By coincidence, I joined the early development team of CKB, where I handled product and some research work.
Around 2021, I gradually spun out from the CKB Foundation and founded my own company to build peripheral projects within the CKB ecosystem, such as JoyID. Today, JoyID has over 500,000 users and is arguably the most complete Passkey wallet in the industry. Although Passkey has some device compatibility limitations, our wallet works seamlessly—no phone number, email, or seed phrase required—and operates as a non-custodial solution in terms of security model.
During the "Ordinals Summer" of 2023, the Bitcoin ecosystem began to revive, almost experiencing a renaissance. In mid-February this year, I introduced a new concept called RGB++, aiming to create a native smart contract environment for BTCFi without compromising Bitcoin's security. We quickly formed a dedicated team and launched the RGB++ protocol before Bitcoin’s halving in April. The results have been promising. Meanwhile, various projects within the CKB ecosystem—including DEXs, launchpads, and algorithmic stablecoins—have also gone live. Overall, the RGB++ ecosystem is entering a phase of rapid growth.
After addressing functional expansion for BTC, we turned our attention to scalability. In April, we established a new company focused on launching UTXO public chains or Bitcoin L2s via the UTXO Stack. Why UTXO? Because Bitcoin itself uses the UTXO model, which differs greatly from Ethereum. If we're building a Layer2 on Bitcoin, how should we implement state transition proofs, cross-chain transfers, forced exits, and data availability? Copying Ethereum’s account model and Rollup approach rarely yields good results. This has always been my stance: imitating Ethereum’s architecture on Bitcoin rarely ends well.
UTXO Stack has completed its first funding round, with a second underway. Despite recent cooling in Bitcoin ecosystem activity, we remain confident and committed to leading the charge in building a near-native functional extension and programmable ecosystem for BTCFi. We’re now focusing more on market and business development, and upcoming ecosystem initiatives will follow soon—stay tuned.
MistMonth: What is the relationship between UTXO Stack and RGB++Layer? Do they have a hierarchical structure? Could you elaborate?
Cipher: Their relationship can be explained from two angles. From a branding perspective, RGB++Layer is a product under the broader UTXO Stack brand; from a technical standpoint, RGB++Layer adds a smart contract execution layer to BTCFi using homomorphic binding. This homomorphic binding isn’t limited to BTC and CKB—it applies broadly to other UTXO-compatible chains like Cardano, Fuel, and Sui.
UTXO Stack is somewhat analogous to OP Stack, enabling rapid deployment of BTC Layer2s, and comes natively with homomorphic binding to allow BTCFi assets to leap between mainchain and Layer2 via Leap. While OP Stack runs smart contracts on Ethereum, UTXO Stack runs them on RGB++ Layer.
Regarding their hierarchical relationship and priority, it boils down to a logical point: the fundamental premise for any L2 is that the L1 must either be congested or functionally insufficient to meet user needs.
Currently, the smart contract layer formed by Bitcoin + RGB++ hasn’t yet attracted significant assets or applications. Therefore, we aim to first guide developers and users to RGB++Layer to build DeFi apps, trading platforms, and issue assets—growing the BTCFi ecosystem before diving deeper into L2 development. Only when BTCFi gains enough traction will BTC scaling become a real demand, making the rollout of UTXO Stack a natural next step.
Faust: You mentioned BTC Layer2 here. Recently, we’ve heard from multiple sources that BTC Layer2 has hit a cyclical low, with more individuals and institutions shifting focus to BTCFi. But many BTCFi projects still rely on WBTC-like models—bridging Bitcoin to other chains or sidechains—hardly BTC-native. In your view, what truly differentiates BTCFi from WBTC-style approaches?
Cipher: My consistent view is that EVM-based BTC Layer2s have very low ceilings. Simply put, using EVM doesn’t grow Bitcoin’s ecosystem—it imports BTC into other ecosystems. We know Bitcoin’s mainnet struggles with smart contracts and low TPS. A common workaround is bridging BTC elsewhere. This seems to solve the problem but sidesteps the core issue:
With this method, Bitcoin’s own ecosystem sees no growth. Miners’ revenue, on-chain data—nothing changes. You’re merely doing asset bridging. Can you really unlock new narratives or use cases this way? Clearly not. Everything you do has already been done by WBTC and the Ethereum ecosystem. There’s no innovation—just another bridged BTC asset. So what’s your value proposition?
Even within the same EVM framework, can you possibly surpass Ethereum’s existing DeFi infrastructure? EVM-based Bitcoin L2s might experience short-term artificial booms driven by airdrop farming, but long-term sustainability is doubtful. The solutions that will genuinely empower and impact the Bitcoin ecosystem must be more native—UTXO-based Layer2s.
And “native” BTC L2s aren’t appealing because of purity—they enable more interesting use cases for the Bitcoin ecosystem. For example, RGB++ features a technology called Leap, a bridgeless cross-chain mechanism allowing BTCFi assets to jump freely between L1 and L2 or across L2s. Unlike traditional lock-and-mint bridges, Leap avoids many associated risks and offers superior speed and liquidity aggregation, greatly benefiting DeFi. Leap went live in April, and many users are already enjoying its convenience. This is one of the innovations enabled by a truly native Bitcoin approach.
Another point: whether something is BTC-native affects its audience. Many BTC holders dislike tools like MetaMask and prefer mainstream Bitcoin wallets. Some so-called Account Abstraction (AA) schemes let Bitcoin wallets interact with EVM dApps, but these come with issues that hinder BTC holder adoption. Our UTXO-based L2 solution allows direct interaction using standard Bitcoin wallets. Our AA implementation is closer to the base layer—users barely notice it—making it simpler, easier, and more seamless.
Additionally, the UTXO model follows “off-chain computation, on-chain verification,” which is ideal for intent-driven transactions. With intents, you only tell the system what input you’re willing to provide and what output you want—the system figures out the rest: which contracts to call, parameter settings, etc. You just submit your desired input-output pair for on-chain validation. Implementing intents on Ethereum requires complex components like Operators and Aggregators, making it bulky. But in the UTXO world, it’s much simpler. This is a key differentiator of UTXO L2s versus EVM ones. Overall, we believe UTXO holds great potential to unlock novel DeFi scenarios on Layer2.
Faust: What are the main integration points between RGB++Layer and BTC? Which use cases are most important? And what are the core roadmap and ecosystem plans for RGB++ and CKB going forward?
Cipher: Integration mainly revolves around practical use cases—some of which I’ve touched on. Let me expand. Flash loans are prominent in Ethereum’s ecosystem: you can call multiple contracts within one transaction, repay principal and interest instantly, and prove solvency to lenders. While UTXO doesn’t support flash loans, it enables other mechanisms.
For instance, UTXO supports nested contract scripts, allowing a sequence of transactions to be chained together, simplifying user interactions. The output of one transaction becomes the input of the next. Using this, we can generate a series of connected transaction instructions in one go. For example, suppose you want to execute a cross-chain DeFi operation: transfer assets from Chain A to Chain B, sell half on a DEX, then combine the remaining tokens with the proceeds to form an LP pair and deposit into a liquidity pool. These four steps can be executed atomically in one click via RGB++Layer’s smart contract framework. Users initiate once, and decentralized smart contracts handle the rest automatically.
Another clear integration point is IB0—Initial Bitcoin Offerings for fundraising. This isn’t new—Ethereum itself started this way, with early investors getting thousands of ETH per BTC. But past IB0s had a flaw: despite being fundraising events, the resulting assets lacked utility. For example, ICOs often featured structured pricing curves: prices rising or falling in steps after the first 100–200 blocks. Some required early buyers to lock for one month, later buyers for three months. Others offered 50% more tokens for an extra month of lock-up, 100% more for a year—many creative variations existed.
Previously, such nuanced rules couldn’t be implemented in IB0s, but RGB++Layer changes that. A major issue with Bitcoin assets is lack of programmability—limiting them to Meme coins. Once combined with smart contracts, however, these assets gain functionality. Only with such capabilities will projects be incentivized to build on Bitcoin.
For BTCFi—or any finance—to thrive, you need diverse assets and rich use cases. If assets are limited to BTC alone, you’re stuck with remote staking or cross-chain—very narrow. To foster a vibrant ecosystem, you need a wide variety of issued assets. On Ethereum today, ERC-20 assets and ETH itself are roughly comparable in market cap—sometimes ERC-20s even exceed ETH. In contrast, non-BTC assets in the Bitcoin ecosystem likely represent less than 1% of BTC’s market cap. So creating new assets within the Bitcoin ecosystem is critical.
So I believe the biggest synergy between RGB++Layer and Bitcoin lies in leveraging RGB++Layer’s programmability to create truly empowering, decentralized asset classes native to Bitcoin. This has never happened on Bitcoin before—only Meme coins or centralized assets. We’re highly optimistic about the potential of smart contract layers to unlock new asset creation on Bitcoin.
Faust: Back in 2018–2019, CKB positioned itself as a 'Layer1 designed for Layer2,' making numerous architectural choices tailored for Layer2 state settlement—essentially serving as a decentralized verification layer for Rollups. In your view, what are CKB’s core advantages compared to general-purpose blockchains?
Cipher: It’s actually hard to define what “L1” or “L2” means within the Bitcoin ecosystem. I don’t think CKB or RGB++Layer exist solely to validate or settle for some other Layer2. CKB, as a UTXO chain, excels at verifying off-chain computation rather than performing computation directly on-chain. This was a core principle championed by Jan, CKB’s chief architect, from day one—he believed blockchain resources—compute, storage, bandwidth—are too precious to waste on complex tasks, and should instead be used for minimal, essential functions.
In practice, both L1s and L2s need consensus on state changes. There are only two ways: first, everyone runs the same state transition logic and arrives at the same result—this is the account model approach. Second, you perform the state change off-chain and submit a proof of validity. I verify the proof instead of re-executing everything—this is exactly the Rollup paradigm.
When we proposed this in 2018, people thought it odd—verifying vs computing seemed like the same thing. But Jan insisted they’re fundamentally different. Take sorting algorithms: verifying a sorted list is far cheaper than sorting it from scratch. At the time, many argued simple ERC-20 transfers didn’t need this. But history proved otherwise—ZK and Rollups alike rely on off-chain compute, on-chain verify. Now we see this approach is more efficient and valuable.
UTXO also brings big benefits for parallel computation. Ethereum is now pushing “parallel EVM,” but from what I’ve heard, actual parallelism often doesn’t exceed 2x in practice. UTXO, by contrast, naturally supports full parallelization—one thread per CPU core. This efficiency is unmatched by EVM-based systems.
We’ve been on the UTXO path for five years. In all the use cases described earlier, UTXO inherently outperforms account models. Plus, sharing the UTXO model with Bitcoin enables homomorphic binding, further simplifying integrations. So yes, our main advantage lies in architecture: using UTXO to interface with Bitcoin makes us far more efficient.
Faust: Some argue UTXO isn’t suitable for DeFi—for example, different UTXOs can’t easily share state, and building DeFi directly on CKB or RGB++ may face resistance. How do you respond to such criticisms? And what solutions have you developed?
Cipher: These concerns are somewhat valid. Account models are more intuitive—they resemble traditional single-threaded programs, where you just guard against edge cases. UTXO is different. The contracts you write on-chain are verifiers—you also need an off-chain component to compute new states, typically called an Aggregator or Generator. The Generator computes off-chain and submits the result for on-chain verification. This is inherently more complex.
Take a UTXO-based DEX like UTXOSwap: it’s hard to know trade outcomes upfront because hundreds of users might submit actions simultaneously. But UTXO’s nature means only one person can update a given state at a time—leading to contention. Without proper handling, 99 out of 100 transactions could fail, leaving only one successful. This poses a massive challenge for product design, which is why people say UTXO isn’t DeFi-friendly.
Yet, we see new UTXO chains emerging even recently—like Fuel. Why keep pursuing UTXO despite the complexity? Because the advantages outweigh the hurdles, as I’ve noted. So how do we overcome these issues? After five years of refinement, we now have mature solutions enabling Uniswap-like functionality on UTXO chains. UTXOSwap recently launched on mainnet and already has active LPs and trading pairs. If you try it, you’ll find it feels nearly identical to Uniswap.
The design is actually quite simple: we split each trade into two steps. First, users submit their intent on-chain. Then, an Aggregator batches all intents and executes a single transaction with the liquidity pool. The pool processes all intents at once and generates a final UTXO reflecting the outcome.
There might be a block delay since Step 1 requires users to post intent individually before the Aggregator bundles them. But in practice, users can send intents off-chain directly to the Aggregator, who batches and submits them—eliminating response lag, similar to Rollup mechanics. We now have robust solutions for UTXO’s DeFi challenges, and CKB is actively implementing such workflows.
Another aspect: UTXO is well-suited for order book models. Order book DEXs existed on Ethereum but eventually disappeared, largely because account models make it costly—each order or cancellation incurs gas, even if unfulfilled, which is unsustainable for product-market fit. That’s why AMMs emerged. But UTXO changes this: you can place 100 orders in one transaction linking to 100 UTXOs—easy and cheap. You could place even more. Thus, order book DEXs have greater potential in UTXO environments.
Moreover, we have PSBT (partially signed transactions)—orders don’t even need to be submitted on-chain. You send a compact signature, and the matcher aggregates multiple signatures before submitting the final transaction. This makes order books even more compatible with UTXO. Even AMM models can adopt advanced features like Uniswap V3’s concentrated liquidity—placing liquidity at discrete price intervals instead of smooth curves.
These are uniquely powerful DeFi scenarios enabled by UTXO—high-level innovations unlikely to emerge on EVM chains, which are mostly filled with copycat projects lacking originality. We aim to attract native Bitcoin developers and those passionate about UTXO—creatives with strong skills and innovative drive. We believe this model can give rise to entirely new BTCFi paradigms.
Faust: CKB uses the RISC-V instruction set and supports multiple programming languages. Yet some argue that supporting too many languages can fragment a blockchain’s developer ecosystem. In your view, what’s the preferred language for development on CKB today?
Cipher: Currently, Rust is the top choice, followed by C—both have solid tooling and support. RISC-V is now a mainstream CPU architecture, expected to surpass ARM within 5–10 years, with broad compiler support. However, official CKB support focuses on Rust and C, though scripting languages are also possible. We’ve built runtimes for LUA and JavaScript, but performance loss is significant—potentially 30% to 300% slower. So for compute-intensive tasks, we recommend Rust or C. And contrary to concerns, multiple language options won’t fragment the ecosystem.
Let me highlight RISC-V’s strengths: in 2018, when we launched CKB, we were the only project globally using RISC-V as a public chain VM. The reason? RISC-V is a hardware-grade instruction set designed with two core principles: simplicity and caution. Being hardware-targeted, it’s stable—unlike EVM, which adds or removes opcodes yearly. This conservatism is exactly what open protocols need.
Second, for smart contract platforms or blockchains, we believe core functionality should stabilize—like Bitcoin—rather than constantly evolve. Frequent changes increase failure risk. Our philosophy differs sharply from Ethereum’s. EVM iterates opcodes annually—affecting compatibility and stability. We actively avoid this. Choosing RISC-V was visionary, and time has proven us right.
Now that ZK is gaining momentum, many projects are adopting RISC-V as their VM backend. As a RISC-V-native public chain, integrating new ZK infrastructure is effortless for us—no instruction translation needed, making us vastly more efficient than running RISC-V atop EVM.
Faust: From CKB’s perspective, how do you view the Bitcoin ecosystem? For example, is there a centralized entity like the Ethereum Foundation? Some claim Blockstream acts unilaterally. Does CKB have a stance on this?
Cipher: I think the Bitcoin and Ethereum ecosystems are structurally very different. The Ethereum Foundation holds immense influence. In contrast, while Bitcoin has core developers with notable sway, the Bitcoin ecosystem features clear checks and balances among miners, developers, and large holders. Miners don’t blindly accept developer proposals—if a proposal goes too far, pools and miners will push back.
This differs from Ethereum, where decisions like POW-to-POS or EIP-1559 sparked huge debates, yet were largely pushed through by EF or Vitalik alone—widely acknowledged. Moreover, Ethereum hosts many centrally issued assets—RWA, stablecoins, etc.—and in a true fork, these issuers would ultimately decide the network’s future.
So both subjectively and objectively, centralized forces in Ethereum—led by EF—hold far more power than any group in Bitcoin’s ecosystem. Another difference: Bitcoin lacks a unified ideology. Core devs lean maximalist, resisting changes like OP_CAT or Ordinals. Peripheral devs may support OP_CAT. Further out, teams like Lightning Network and RGB are more open to innovation. Then there are groups like ours—actively driving change. Finally, others embrace multisig bridges and EVM-based L2s.
Because of this diversity, Bitcoin’s ecosystem is highly inclusive. You don’t have to fear one faction steering the whole ecosystem astray—errors by one group won’t doom the rest. As long as one group turns out right, the ecosystem survives. Ethereum may move faster on the surface, but Bitcoin moves more steadily—no single group can drag it into ruin. From this angle, we’re highly bullish on Bitcoin—it’s a resilient melting pot with strong self-correction.
Take BTC L2s: your site BTCEden lists wildly different approaches—client-side validation like Lightning and RGB, sidechains, even hybrid L2s bridging Ethereum and Bitcoin. It’s a true showcase of diversity. Contrast that with Ethereum: sharding is dead, state channels and Plasma abandoned—only Rollups remain. That’s why we prefer Bitcoin’s ecosystem: freer, more robust.
The CKB Foundation is also moving toward more decentralized governance. I’m no longer part of the foundation, so I can’t speak officially, but I observe increasing community-driven evolution. CKB is still small—demands for decentralized decision-making aren’t urgent yet. People mostly want faster progress. But from what I know, CKB’s core decision-makers are highly open, unwilling to hoard power, and committed to transitioning to full decentralization at the right moment.
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
@godrealmx
