BTCFi is experiencing a surge, and Omnity has launched a brand new Bitcoin Layer 1 programmable expansion protocol called REE. Coupled with the team's years of experience in cross-chain interoperability (Omnity hub), Omnity has become one of the most important and exploratory players in the BTCFi space.
Official website: https://www.omnity.network/
In my opinion, Omnity Network is exploring a highly efficient, highly composable, and fault-tolerant technical solution for the Bitcoin ecosystem that enhances "scalability and programmability":
For high-frequency trading scenarios, the Trustless-level Bitcoin asset cross-chain solution Omnity Hub connects to more developed high-speed smart contract chains like Bitlayer, Solana, and Base;
For large fund scenarios and normal trading frequency DeFi businesses, REE is used to build directly on Bitcoin Layer 1.
The Hub and REE are independent and possess flexible composability, laying a solid foundation for developer innovation. I look forward to disruptive innovations emerging in the BTCFi field!
Interested friends can read this article first; for the English version, see the link below ⬇️
REE White Paper: https://x.com/louisliubj/status/1861588938475086166
Below is the English translation, Enjoy～
REE: Turing-complete Cross-chain-less Bitcoin Execution Layer
REE introduces a decentralized Bitcoin execution layer that enables Turing-complete smart contracts for BTCFi applications. Without the need for asset cross-chain, REE enhances the programmability of the Bitcoin mainnet while preserving the native user experience of Bitcoin.
What is REE?
The Runes Exchange Environment (REE) is a decentralized execution layer for Bitcoin that provides composable smart contracts for Bitcoin Layer 1 (Bitcoin L1) without requiring asset cross-chain. REE enhances Bitcoin's multi-signature transaction mechanism through smart contracts on a decentralized execution layer, directly participating in Bitcoin mainnet transactions.
Figure 0. Bitcoin Multi-signature Transactions
Multi-signature transactions are Bitcoin transactions that include inputs from multiple participants, a technique used in the Bitcoin ecosystem for many years. Typically, one participant acts as a coordinator, using PSBT (Partially Signed Bitcoin Transaction) to aggregate each party's signatures and then broadcasts the transaction to the Bitcoin network. Some notable use cases for multi-signature transactions include CoinJoin, multi-signature wallets, and custodians.
In multi-signature scenarios, participants can be programs in addition to humans. In a DeFi environment, traders typically transact with protocols (smart contracts) as their counterparties. The idea of REE is to allow BTCFi protocols to participate in Bitcoin multi-signature transactions and to move the entire signing process onto a public blockchain, thus achieving decentralization.
Figure 1. Decentralized Multi-signature Coordination (DMSC)
Figure 1 illustrates the general process of Decentralized Multi-signature Coordination (DMSC). This setup involves a trader, multiple BTCFi protocols (A, B, and C), and a coordinator on a public blockchain. The coordinator aggregates signatures and broadcasts the final transaction.
The DMSC process is as follows:
1. Negotiation Phase
The trader initiates a transaction by negotiating terms with multiple protocols. Each protocol represents an entity holding Bitcoin assets and prepared to transact under specific rules. Examples of protocols include decentralized exchanges, lending protocols, stablecoins, etc.
2. Signing Phase
After negotiations, a PSBT is constructed to reflect the transaction. The coordinator then calls each protocol to sign the PSBT. Each protocol (A, B, and C) verifies its transaction portion and approves its inclusion through signatures.
3. Broadcasting Phase
Once the PSBT is fully signed, the Coordinator broadcasts it as a Bitcoin transaction to the network. Thus, the transaction is settled on Bitcoin.
REE chooses ICP (Internet Computer Protocol) as the public blockchain for DMSC. In other words, REE is the Bitcoin DMSC infrastructure on ICP.
Why REE?
Bitcoin is the most secure and decentralized blockchain in the world, but its limited programmability restricts its use in complex financial applications. REE complements existing Bitcoin L2 solutions by providing advanced programmability and Turing-complete smart contracts while maintaining self-custody and minimizing trust assumptions.
Figure 2. REE is not Bitcoin L2
Unlike most L2 solutions, REE smart contracts interact directly with Bitcoin's UTXO model, achieving advanced programmability while maintaining self-custody. Traders do not need to lock their Bitcoin assets on cross-chain bridges. They interact with smart contracts by signing PSBTs with their Bitcoin wallets and settle transactions instantly on Bitcoin.
On the other hand, among known Bitcoin L1 programmability enhancement solutions, DMSC has significant advantages over others. It leverages modern public blockchains to enhance Bitcoin programmability rather than relying on new OP codes. Additionally, DMSC can be compatible with all UTXO-based meta-protocol assets without requiring upgrades to the meta-protocol and indexers.
Table 1. Comparison of Bitcoin L1 Programmability Technical Solutions
Finally, ICP may be the most suitable blockchain for DMSC. REE utilizes ICP's Chain Fusion technology to securely manage private keys and Bitcoin signatures, enabling DMSC while maintaining Bitcoin's security model. Through ICP's native Bitcoin integration and on-chain indexers, REE is compatible with Runes (the most widely accepted UTXO-based Bitcoin meta-protocol) in a trust-minimized manner.
How does REE work?
Influenced by Ethereum, the state model of the vast majority of smart contract platforms is account-based, which also affects the mindset of smart contract developers. However, Bitcoin's on-chain state is UTXO-based. REE introduces the Exchange-Pool model to bridge the gap. The Exchange-Pool model adapts to Bitcoin's UTXO state management and can be easily implemented on account-based public chains like ICP. The model consists of three simple concepts:
Coin is the unit of Bitcoin assets based on UTXO. BTC and Runes are accepted as Coin in REE.
Exchange is an instance of a BTCFi protocol operating on the REE platform, facilitating Coin exchanges.
A pool is the public key (Chain Key) used by the Exchange to hold Coins and sign Bitcoin transactions. According to Exchange logic, users deposit a bag of Coins into the pool and receive another bag of Coins in return. Typically, an Exchange manages multiple pools, each with its own Coins and state data.
Bitcoin builders can now create diverse BTCFi protocols using REE's Exchange—realizing several public methods of ICP smart contracts.
Figure 3. REE Architecture
Figure 3 illustrates the process of completing Bitcoin transactions on REE, involving multiple components such as two Exchanges, the REE coordinator, and the front-end interface. Here is a step-by-step breakdown of the process:
Price Inquiry: The trader initiates the process through the front-end interface, making a trade inquiry. This may involve selecting the type of trade or operation they wish to execute, such as exchanging on Exchange A and then staking on Exchange B.
Constructing PSBT: Once the trader agrees to the trade terms, the front-end constructs the PSBT with the help of the REE Typescript SDK.
Trader Signs PSBT: The trader reviews and signs the PSBT with their Bitcoin wallet, essentially approving the transaction for further processing.
Calling Orchestrator: The front-end sends the PSBT to the REE Orchestrator. The REE Orchestrator acts as the coordinator, overseeing the execution of the transaction.
Input Verification: Before the Orchestrator executes the REE transaction, all PSBT inputs must be verified to ensure they are spendable and indeed contain the assets they claim. The Orchestrator relies on the Ord Canister (on-chain Runes indexer) to complete this.
Exchange Signs PSBT: After verification, the REE Orchestrator communicates with the relevant Exchange to sign the PSBT. The Exchange verifies that the PSBT data meets its trading conditions and signs one by one.
Broadcasting Transaction: After all relevant Exchanges sign the PSBT, the REE coordinator broadcasts the fully signed transaction to the Bitcoin network. The transaction is then confirmed on the Bitcoin blockchain, completing the entire process.
The REE Orchestrator is responsible for ensuring state consistency by notifying Exchanges to roll back the state if any Exchange refuses to sign.
Before anyone uses an Exchange, it must be initialized by its builder:
Deployment (Step 0.1): Builders deploy the Exchange canister to the same ICP subnet as the REE Orchestrator. Although canisters can call across subnets, it introduces unnecessary latency.
Registration (Step 0.2): Builders register the Exchange with the REE Orchestrator.
Exchange builders are responsible for maintaining the Exchange, including upgrades and recharging cycles to keep it operational. Omnity will provide general facilities for Exchange builders to facilitate usage, but these are optional and replaceable.
System Features
Programmability
REE Exchange is an independent ICP smart contract that can fully leverage the capabilities of the underlying blockchain. Readers are encouraged to visit the ICP technical documentation for more information on ICP smart contract development.
ICP Technical Documentation:
https://internetcomputer.org/docs/current/home
Here are a few tips:
- Intensive computations like facial recognition can run within ICP smart contracts:
https://medium.com/dfinity/the-next-step-for-deai-on-chain-inference-enabling-face-recognition-589183203fc2
- The Bitcoin canister on ICP may be the largest smart contract in the world, occupying 500GB of on-chain storage, with an annual cost of only $2,500.
https://github.com/dfinity/bitcoin-canister
- Omnity Hub is a fully on-chain interoperability stack on ICP, meaning no off-chain relayers or indexers are needed. Omnity Hub connects directly to dozens of heterogeneous blockchains via RPC interfaces.
https://explorer.omnity.network/
Composability
The composability of REE smart contracts ensures seamless integration across protocols, enabling innovative financial protocols by combining liquidity and logic units within a minimized trust framework.
REE provides Bitcoin-style composability. Each exchange only cares about what it receives (input) and what it provides (output); as long as the input/output is reasonable, it agrees to participate in the transaction. REE transactions may involve multiple exchanges, each receiving and contributing some coins. With the cooperation of exchanges, the coordinator is responsible for ensuring the atomicity of multi-signature transactions. Atomic composability means that a multi-signature transaction either fully succeeds or completely rolls back if any part fails. This is crucial in DeFi applications.
Typically, the trader provides the initial input to the first exchange; the output from the first exchange goes to the second exchange, and this continues until the final output from the last exchange is given to the trader. The signing order of the PSBT follows this logic: the first exchange will only agree to provide its input and sign the PSBT if the trader has signed its input, and so on.
Conceptually, exchange composability looks like pipelined Unix commands. However, it is not limited to that. Any entity (trader or exchange) can provide input to other entities without regard to order. For example, a trader's input can go to the second or later exchanges; exchanges can provide initial inputs and Bitcoin network fees on behalf of the trader.
Moreover, the trader does not necessarily have to be an individual; it can be an off-chain process or an ICP smart contract. This opens up possibilities for on-chain or off-chain yield aggregators or arbitrage bots. With the powerful Chain Fusion stack, REE Exchange can interact with other blockchains. For instance, state changes on Ethereum or Solana can trigger REE transactions, and vice versa.
Risk Profile
The recipient (the trader transacting with the liquidity pool) reviews the PSBT containing all transaction terms, represented by inputs and outputs, before signing. Once signed, no one, including the trader, exchanges, REE, ICP nodes, and Bitcoin miners, can alter the transaction. In other words, the recipient bears no custodial risk.
Typically, the execution of each REE transaction results in a state change of a specific liquidity pool, rendering the transaction terms obtained from previous queries invalid. Given that the delay in executing REE transactions (measured in seconds) is far less than that of Bitcoin (measured in minutes), REE transactions are usually processed sequentially. However, transaction failures may occur when multiple traders transact with the same liquidity pool simultaneously.
Transaction failures do not result in asset loss; traders simply need to re-query and attempt to execute again.
Market makers (traders providing liquidity to the pool) bear custodial risk when transferring asset control to the exchange. Therefore, they face smart contract risks associated with Exchange logic, emphasizing the importance of audits and the reputation of Exchange builders.
The security assumptions of market makers include the ICP and REE platforms. However, the security of ICP (valued in billions of dollars) meets the security requirements of BTCFi protocols in all known cases.
Bitcoin State Consistency
The limitations of Bitcoin scripts in supporting BTCFi are not only due to the functional limitations of opcodes but also largely because they cannot maintain complex on-chain states. In contrast, exchanges in REE can conveniently maintain and manage states. However, the state of REE exchanges must ultimately remain consistent with Bitcoin; otherwise, REE transactions cannot settle on Bitcoin.
To prevent settlement failures, the coordinator verifies that all transaction inputs have not been spent. Each exchange also verifies that the transaction inputs and outputs meet its standards. This approach ensures that only valid and verified inputs are used to settle transactions.
However, even if these inputs are verified before transaction execution, settlement cannot be guaranteed afterward. Traders may intentionally or unintentionally use the same inputs for another Bitcoin transaction.
REE must be aware of real-time changes in the Bitcoin network and respond accordingly. With the support of Bitcoin native integration and on-chain Runes indexers, REE may be the only Bitcoin execution layer that achieves this without relying on centralized off-chain processes.
Figure 4. REE Tx State
The REE Orchestrator is the component that manages the lifecycle of all REE transactions. It is responsible for notifying Exchanges of relevant state change events.
Figure 5. Liquidity Pool State Management
Exchanges manage state based on liquidity pools. Specifically, the state of a liquidity pool should be organized as a state chain linked by a sequence of transactions executed on that pool. The liquidity pool always processes query requests and executes new transactions based on the head of the state chain. Based on event notifications from the Orchestrator, the liquidity pool executes finalization or rollback.
Additionally, given the high volatility of Bitcoin network fees, there is no economically viable way to ensure that transactions are included in blocks within a specific timeframe. In cases of soaring Bitcoin network fees, there are two methods to accelerate settlement: RBF (Replace-By-Fee) and CPFP (Child Pays for Parent). RBF requires rebuilding the transaction, which leads to a poor user experience.
REE uses CPFP, meaning that when Bitcoin network fees soar, subsequent transactions need to subsidize previously unconfirmed transactions in the same liquidity pool. Fee subsidies remain a free market mechanism: traders will only initiate subsequent transactions if they expect to profit despite the increased costs.
Performance
The performance of the execution layer is typically measured by two metrics: throughput (in TPS) and latency. On REE, traders can execute transactions sequentially with only a few seconds of latency, allowing them to proceed to the next step without waiting for block confirmations. In terms of latency, REE improves Bitcoin's performance by 100 times.
REE's serial transactions will settle in bulk on the Bitcoin chain. Since a mempool transaction can have up to 25 subsequent transactions, each Bitcoin block can settle up to 25 transactions for a single REE transaction pool. Therefore, 25 can be seen as the throughput limit for a single REE transaction pool.
Different transaction pools can achieve parallel transaction execution. When price competition is unnecessary, Exchange builders can add redundant pools to enhance concurrency. For example, distributing tokens across 10 pools for an airdrop with 100,000 recipients can significantly reduce the likelihood of transaction failures due to multiple users claiming simultaneously.
Within a single transaction pool, concurrency can be achieved by managing multiple UTXOs holding the same type of coins. However, this requires more complex UTXO selection, splitting, and merging algorithms. Future Exchanges may explore these advanced techniques to provide a better user experience.
Cost
The main cost of REE transactions to users comes from Bitcoin network fees. REE minimizes the size of settlement transactions by using P2TR address types.
Builders bear the operational costs (cycles) of Exchanges on ICP. Although ICP is very cost-effective, builders need to generate revenue internally or externally to ensure the economic sustainability of their Exchanges.
MEV
REE is an execution layer that delegates transaction ordering to the ICP subnet where the REE Orchestrator container resides. While theoretically possible, it is unheard of for ICP subnet nodes to extract MEV by reordering transactions.
More importantly, there is no concept of slippage on REE; when traders sign the PSBT, all transaction inputs and outputs are already set. If inputs from the Exchange liquidity pool have been spent, the transaction will fail. Therefore, if a REE transaction is front-run, it will automatically fail, leaving the front-runner to bear the price risk alone.
Governance
REE will be managed by the Omnity SNS DAO, responsible for overseeing protocol upgrades, parameter adjustments, and development roadmaps. On-chain governance via SNS ensures transparency and community-driven decision-making for the sustainable development of the REE ecosystem.
Use Cases
Replicating DeFi protocols from Ethereum or Solana to Bitcoin is a direct way to leverage REE. Here are a few examples to elaborate.
AMM DEX (Automated Market Maker Decentralized Exchange)
RichSwap, an AMM DEX built by Omnity, will launch simultaneously with the REE mainnet. As the first exchange on REE, RichSwap serves the following purposes:
RichSwap validates the functionality and performance of the REE platform.
RichSwap is open-source, providing a complete example for BTCFi builders.
Other BTCFi protocols can leverage RichSwap to accelerate liquidity bootstrapping.
RichSwap has a built-in token value capture mechanism that other BTCFi protocols can utilize.
Although RichSwap is the first exchange, it does not enjoy any privileges. After the mainnet launch, REE will quickly transition to an open platform, accepting permissionless registration of any BTCFi protocol (including AMM DEX) that meets the technical specifications.
Lending
Lending protocols based on REE can support multiple liquidity pools, each with different configurations, risk parameters, and asset support types. Each liquidity pool that supports borrowing BTC against blue-chip Runes may have different interest rates, collateral ratios, and liquidation thresholds. It may choose to return an atoken to liquidity providers (LPs). By integrating with oracles on ICP, lending protocols can decentralize the determination of collateral value or trigger liquidation processes.
Liquid Staking Tokens
Implementing Bitcoin L1 staking on REE is feasible, but integrating existing staking protocols (such as Babylon) presents a more interesting possibility. Users deposit Bitcoin into the Exchange and receive LST in Runes format. The LST Exchange then combines with the Babylon staking protocol on Bitcoin L1, while managing delegation and staking rewards on the Babylon chain through a trustless cross-chain protocol. Omnity Hub has already integrated with Osmosis through a fully on-chain architecture and light client verification. Therefore, interactions between ICP smart contracts and Cosmos application chains no longer face technical barriers.
Roadmap
Q4 2024, release the REE white paper.
Q1 2025, launch the REE mainnet alongside RichSwap.
Q2 2025, open Exchange registration to Omnity partners.
H2 2025, fully open Exchange registration.
Conclusion
REE represents a breakthrough in Bitcoin programmability, achieving secure, Turing-complete smart contracts without relying on asset cross-chain or forks. This cross-chain-less execution model has the potential to foster a BTCFi ecosystem that leverages Bitcoin's liquidity and security in a completely trustless and permissionless environment.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
