REE introduces a decentralized Bitcoin execution layer that enables Turing-complete smart contracts for BTCFi applications. Without the need for cross-chain asset transfers, REE enhances programmability for the Bitcoin mainnet while retaining the native Bitcoin user experience.
As BTCFi is gaining momentum, Omnity has released a new Bitcoin layer 1 programmable extension protocol, 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 field.
Official website: https://www.omnity.network/
In my opinion, Omnity Network is exploring a technical solution for “scaling and enhancing programmability” in the bitcoin ecosystem that is efficient, highly composable, and highly fault-tolerant:
1. For high-frequency trading scenarios, use Omnity Hub, a Trustless-level Bitcoin asset cross-chain solution, to go to Bitlayer, Solana, Base and other high-speed smart contract chains with more complete ecological construction facilities;
2. For DeFi businesses with large capital scenarios and normal transaction frequencies, REE is used to build directly on the Bitcoin layer.
Hub and REE are independent and flexibly combinable, which can be said to have laid a solid foundation for developers’ innovation. We look forward to disruptive innovation in the BTCFi field!
Interested friends can read this article first. If you want to read the original English version, please see the link⬇️
REE Whitepaper: https://x.com/louisliubj/status/1861588938475086166
The following is the Chinese translation, Enjoy~
REE: Turing-complete, cross-chain-free Bitcoin execution layer
REE introduces a decentralized Bitcoin execution layer that enables Turing-complete smart contracts for BTCFi applications. Without the need for cross-chain asset transfers, REE enhances programmability for the Bitcoin mainnet while retaining the native Bitcoin user experience.
What is REE?
Runes Exchange Environment (REE) is a decentralized execution layer for Bitcoin that provides composable smart contracts for Bitcoin L1 without cross-chain assets. REE enhances Bitcoin’s multi-signature transaction mechanism through smart contracts on the decentralized execution layer and directly participates in Bitcoin mainnet transactions.
Figure 0. Bitcoin multi-signature transaction
A multi-signature transaction is a Bitcoin transaction that contains inputs from multiple participants, a technique used by the Bitcoin ecosystem for many years. Typically, one participant acts as a coordinator and uses PSBT (Partially Signed Bitcoin Transaction) to aggregate signatures from each party and then broadcast the transaction to the Bitcoin network. Some notable use cases for multi-signature transactions include CoinJoin, multi-signature wallets, and custodians.
In a multi-signature scenario, participants can be programs in addition to humans. In the DeFi environment, traders usually trade with protocols (smart contracts) as counterparties. The idea of REE is to allow the BTCFi protocol to participate in Bitcoin multi-signature transactions and move the entire signing process to the public blockchain, thereby achieving decentralization.
Figure 1. Decentralized Multi-Signature Coordination (DMSC)
Figure 1 shows the general flow of Decentralized Multi-Signature Coordination (DMSC). The 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 stage
Traders initiate trades by negotiating terms with multiple protocols. Each protocol represents an entity that holds Bitcoin assets and is prepared to trade according to specific rules. Examples of protocols include decentralized exchanges, lending protocols, stablecoins, etc.
2. Signing stage
After negotiation, 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 part of the transaction and approves its inclusion by signing.
3. Broadcasting stage
Once the PSBT is fully signed, the Coordinator converts it into a Bitcoin transaction and broadcasts it 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 world’s most secure and decentralized blockchain, 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 L2s, 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 the cross-chain bridge. They interact with smart contracts by signing PSBT with their Bitcoin wallets and instantly complete transaction settlement on Bitcoin.
On the other hand, among the known Bitcoin L1 programmability enhancement solutions, DMSC has significant advantages over other solutions. It uses modern public blockchains to enhance Bitcoin programmability instead of relying on new OP code. In addition, DMSC is compatible with all UTXO-based meta-protocol assets without upgrading meta-protocols and indexers.
Table 1. Comparison of Bitcoin L1 programmability technology solutions
In the end, ICP may be the most suitable blockchain for DMSC. REE leverages 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 indexer, REE is compatible with Runes (the most widely accepted UTXO-based Bitcoin meta-protocol) in a trust-minimized way.
How does REE work?
Influenced by Ethereum, the state model of most smart contract platforms is account-based, which also affects the mindset of smart contract developers. However, Bitcoin’s on-chain state is based on UTXO. REE introduces the Exchange-Pool model to bridge the difference. 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 3 simple concepts:
1. Coin is the unit of Bitcoin assets based on UTXO. BTC and Runes are accepted as Coin in REE.
2. Exchange is an instance of the BTCFi protocol operating on the REE platform, used to facilitate Coin exchanges.
3. The fund pool is the public key (Chain Key) used by the Exchange to hold coins and sign Bitcoin transactions. According to the exchange logic, the user puts a bag of coins into the pool and gets another bag of coins from it. Usually, an exchange manages multiple pools, each of which has data for coins and status.
Bitcoin builders can now create diverse BTCFi protocols using REE’s Exchange — an ICP smart contract that implements several public methods.
Figure 3. REE architecture
Figure 3 shows the process of completing a Bitcoin transaction on REE, which involves multiple components such as two exchanges, the REE coordinator, and the front-end interface. The following is a step-by-step breakdown of the process:
1. Inquiry: The trader initiates the process through the front-end interface and makes a transaction inquiry. This may involve selecting the type of transaction or operation he wants to perform, such as exchanging on ExchangeA and then staking on ExchangeB.
2. Build PSBT: Once the trader agrees to the terms of the transaction, the front-end builds the PSBT with the help of REE Typescript SDK.
3. Trader signs the PSBT: The trader reviews and signs the PSBT with his Bitcoin wallet, essentially approving the transaction for subsequent processing.
4. Calling Orchestrator: The front end sends the PSBT to the REE Orchestrator. The REE Orchestrator acts as a coordinator and supervises the transaction execution.
5. Check inputs: Before the Orchestrator executes a REE transaction, all PSBT inputs must be verified to ensure that they are spendable and do contain the assets they claim to contain. The Orchestrator relies on the Ord Canister (on-chain Runes Indexer) to accomplish this.
6. Exchange signs PSBT: After verification, REE Orchestrator communicates with the relevant Exchange to sign the PSBT. The Exchange verifies that the PSBT data meets its transaction conditions and signs them one by one.
7. Broadcast 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 the Exchanges to roll back the state if any Exchange refuses to sign.
Before anyone uses an Exchange, it must be initialized by its builder:
1. Deployment (step 0.1): The builder deploys Exchangecanister on the same ICP subnet as the REE Orchestrator. Although canister can be called across subnets, it will bring unnecessary delays.
2. Registration (step 0.2): The builder registers the Exchange with the REE Orchestrator.
Exchange builders are responsible for exchange maintenance, including upgrades and recharge cycles to keep it running. Omnity will provide common facilities for exchange builders to use, but they are all optional and replaceable.
System Features
Programmability
REE Exchange is an independent ICP smart contract that can fully utilize the capabilities of the underlying blockchain. Readers are advised to visit the ICP technical documentation to learn more about ICP smart contract development.
ICP Technical Documents:
https://internetcomputer.org/docs/current/home
Here are a few tips:
1. Intensive computing such as face recognition can be run within the ICP smart contract:
https://medium.com/dfinity/the-next-step-for-deai-on-chain-inference-enabling-face-recognition-589183203fc2
2. ICP’s Bitcoin container may be the world’s largest smart contract, occupying 500GB of on-chain storage and costing only $2,500 per year.
https://github.com/dfinity/bitcoin-canister
3. Omnity Hub is a full-chain interoperability stack on ICP, which means no off-chain relays or indexers are required. Omnity Hub directly connects dozens of heterogeneous blockchains through the RPC interface.
https://explorer.omnity.network/
Composability
REE smart contract composability ensures seamless integration across protocols, enabling innovative financial protocols by combining liquidity and logic units in a trust-minimized framework.
REE provides Bitcoin-style composability. Each exchange only cares about what it receives (inputs) and what it provides (outputs); as long as the inputs/outputs make sense, it agrees to participate in the transaction. A REE transaction may involve multiple exchanges, each of which receives and contributes some coins. In conjunction with the exchanges, the coordinator is responsible for ensuring the atomicity of multi-signature transactions. Atomic composability means that multi-signature transactions either succeed completely or roll back completely if any part fails. This is critical in DeFi applications.
Typically, a trader provides initial input to the first exchange; the output of the first exchange goes to the second exchange, and so on until the final output of 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 more than that. Any entity (trader or exchange) can provide input to other entities without regard to order. For example, a trader’s input is given to a second or later exchange; the exchange provides the initial input and the Bitcoin network fee on behalf of the trader.
Furthermore, the trader does not have to be an individual; it can be an off-chain process or an ICP smart contract. This opens up the possibility for on-chain or off-chain yield aggregators or arbitrage bots. Through the powerful Chain Fusion stack, REEExchange can interact with other blockchains. For example, state changes on Ethereum or Solana can trigger REE transactions, and vice versa.
Risk Profile
The taker (the trader who transacts with the pool) reviews the PSBT containing all the terms of the transaction, represented by the inputs and outputs, before signing. Once signed, no one, including the trader himself, the exchange, REE, ICP nodes, and Bitcoin miners, can change the transaction. In other words, the taker does not bear any custody risk.
Typically, the execution of each REE transaction results in a change in the state of a specific pool, which invalidates the transaction terms obtained from previous queries. Considering that the latency of REE transaction execution (in seconds) is much lower than Bitcoin (in minutes), REE transactions are usually processed sequentially. However, transaction failures may occur when multiple traders trade with the same pool at the same time.
Failed trades do not result in loss of assets; traders can simply re-query and try to execute again.
Market makers (traders who provide liquidity to a pool) take on custody risk when they hand over control of their assets to an exchange. As a result, they are exposed to smart contract risk associated with the exchange’s logic, which underscores the importance of audits and the reputation of exchange builders.
The security assumptions of the market maker include ICP and REE platforms. However, the security of ICP (worth billions of dollars) meets the security requirements of the BTCFi protocol under all known circumstances.
Bitcoin State Consistency
Bitcoin scripts are limited in supporting BTCFi 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 are able to conveniently maintain and manage states. However, the REE exchange state must eventually be consistent with Bitcoin; otherwise, REE transactions cannot be settled on Bitcoin.
To prevent settlement failures, the coordinator verifies that all transaction inputs have not been spent. Each exchange also verifies that transaction inputs and outputs meet its criteria. This approach ensures that only valid and verified inputs are used to settle transactions.
However, even if these inputs are validated before a transaction is executed, settlement is not guaranteed afterwards. A trader could intentionally or accidentally use the same input for another Bitcoin transaction.
REE must sense real-time changes in the Bitcoin network and respond accordingly. Powered by Bitcoin native integration and on-chain Runes Indexers, REE may be the only Bitcoin execution layer that can achieve this without relying on centralized off-chain processes.
Figure 4. REE Tx status
REE Orchestrator is the component that manages the lifecycle of all REE transactions. It is responsible for notifying Exchange of relevant state change events.
Figure 5. Funding pool status management
Exchanges manage state based on the pool. Specifically, the state of the pool should be organized as a state chain linked by the sequence of transactions executed on the pool. The pool always processes query requests and executes new transactions based on the head of the state chain. Based on the event notification from the Orchestrator/coordinator, the pool executes finalization or rollback.
In addition, given the high volatility of Bitcoin network fees, there is no economically feasible way to ensure that transactions are included in blocks within a specific time frame. In the event of a surge in Bitcoin network fees, there are two ways to speed up settlement: RBF (Replace-By-Fee) and CPFP (Child Pays for Parent). RBF requires rebuilding transactions, which results in a poor user experience.
REE uses CPFP, which means that when Bitcoin network fees soar, subsequent transactions need to subsidize previously unblocked transactions on the same pool. Fee subsidies are still a free market mechanism: traders will only initiate subsequent transactions if they expect to make a profit despite the increased costs.
performance
The performance of the execution layer is usually measured by two indicators: throughput (measured in TPS) and latency. On REE, traders can execute transactions sequentially with a latency of only a few seconds, without having to wait for block confirmation to proceed to the next step. In terms of latency, REE improves Bitcoin’s performance by 100 times.
REE serial transactions will be settled in batches on the Bitcoin chain. Since a memory pool 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 regarded as the throughput limit of a single REE transaction pool.
Different trading pools enable parallel trade execution. When price competition is not necessary, 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 possibility of transaction failures due to multiple users claiming at the same time.
In a single transaction pool, intra-pool concurrency can be achieved by managing multiple UTXOs holding the same type of currency. However, this requires more complex UTXO selection, splitting, and merging algorithms. Future exchanges may explore these advanced technologies 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 the P2TR address type.
Builders bear the cost of running an Exchange on ICP (cycles). Although ICP is very cost-effective, builders need to generate revenue inside or outside the protocol to ensure the economic sustainability of their Exchange.
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 an ICP subnet node to extract MEV by reordering transactions.
More importantly, there is no concept of slippage on REE; when a trader signs a PSBT, all transaction inputs and outputs are already set, and if the input from the Exchange pool has been spent, the transaction will fail. Therefore, if a REE transaction is front-run, it will automatically fail, leaving the front-runner alone to bear the price risk.
Governance
REE will be managed by the Omnity SNS DAO, which will oversee protocol upgrades, parameter adjustments, and development roadmaps. SNS on-chain governance ensures transparency and community-driven decision-making for the sustainable development of the REE ecosystem.
Use Cases
Copying DeFi protocols from Ethereum or Solana to Bitcoin is a straightforward way to leverage REE. Here are a few examples to explain in detail.
AMM DEX (Automated Market Maker Decentralized Exchange)
RichSwap, an AMM DEX built by Omnity, will be launched simultaneously with the REE mainnet. As the first exchange on REE, RichSwap serves the following purposes:
1. RichSwap verifies the functionality and performance of the REE platform
2. RichSwap is open source and provides a complete example for BTCFi builders
3. Other BTCFi protocols can use RichSwap to accelerate liquidity bootstrapping
4. RichSwap has a built-in token value capture mechanism that other BTCFi protocols can leverage
Although RichSwap is the first exchange, it does not enjoy any privileges. After the mainnet is launched, REE will quickly transition to an open platform, accepting any BTCFi protocol (including AMM DEX) that meets the technical specifications without permission.
Borrowing
REE-based lending protocols can support multiple pools, each with different configurations, risk parameters, and asset backing types. Each pool that supports borrowing BTC with Blue Runes collateral may have different interest rates, collateral ratios, and liquidation thresholds. It may choose to return atokens to liquidity providers (LPs). By integrating with oracles on ICP, lending protocols can determine collateral value or trigger liquidation processes in a decentralized manner.
Liquidity Staking Tokens
Implementing Bitcoin L1 staking on REE is feasible, but integrating existing staking protocols such as Babylon is a more interesting possibility. Users deposit Bitcoin into the Exchange and receive LST in Runes format. The LSTExchange is then combined 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 been integrated with Osmosis through a full-chain architecture and light client verification. Therefore, the interaction between ICP smart contracts and Cosmos application chains no longer faces technical barriers.
Roadmap
1. Release the REE white paper in the fourth quarter of 2024
2. Launch REE mainnet with RichSwap in Q1 2025
3. Open Exchange registration to Omnity partners in Q2 2025
4. In the second half of 2025, Exchange registration will be fully open
in conclusion
REE represents a breakthrough in Bitcoin programmability, enabling secure, Turing-complete smart contracts without relying on asset cross-chain or forks. This cross-chain-free execution model has the potential to foster a BTCFi ecosystem that leverages Bitcoin’s liquidity and security in a completely trustless and permissionless environment.
Author：Runes中文社区
This content is only to provide market information and does not constitute investment advice.
