Omnity Network Deep Dive

Introduction

In today’s increasingly interconnected digital landscape, interoperability across blockchain networks has become a key enabler for scalable, user-friendly applications. Omnity introduces a multi-chain coordination model through its expanding suite of non-custodial, open-source, on-chain Bitcoin products.

Designed to enhance Bitcoin interoperability, Omnity’s Hub can integrate leading chains, such as Ethereum and Solana, as well as various Bitcoin layer 2s, introducing a scalable and verifiable framework for cross-chain transactions. On the other hand, Omnity’s Runes Exchange Environment (REE) focuses specifically on enhancing Bitcoin’s programmability in a trust-minimized, open-source execution environment, offering BTCFi developers the opportunity to design comprehensive financial products on Bitcoin.

Omnity distinguishes itself by integrating the Internet Computer Protocol (ICP) to facilitate cross-chain transactions between heterogeneous blockchains. Unlike conventional solutions that often rely on external validators or centralized servers, Omnity integrates ICP’s Chain Fusion and Chain-key cryptography solutions to reduce system-level complexity and costs.

History of Omnity

Omnity's journey into cross-chain innovation began with Cosmos IBC (Inter-Blockchain Communication protocol), a field-tested standard from early cross-chain technology. IBC pioneered trustless and efficient cross-chain transactions by enabling native block verification on two Tendermint blockchains, reducing the need for external validators. Omnity's early developments drew heavily from IBC TAO to establish Adaptive IBC, extending IBC to any heterogeneous blockchain with verifiable light clients. Today, IBC is used by over 100 blockchains and has more than 420 forks.

Three Major Cross-Chain Solutions

To better understand Omnity's cross-chain solution, let’s first explore the three types of blockchain bridges. Cross-chain designs can generally be categorized into three main types that are distinguished by the way they validate cross-chain transactions.

External Validators Network

In a network of external validators, a number of servers monitor the target blockchain and, upon consensus, execute an operation on the destination chain. These validators operate independently and are not part of the source or destination chains. Typically, such an asset transfer requires locking the asset into the source chain and then minting an equivalent value of wrapped assets on the destination chain. The security of this cross-chain bridge is ensured by validators, secondary to the security of the source or destination chains. This frequently adds another scope of application-layer risk in smart contracts on one or both blockchains.

This type of bridge can facilitate a theoretically unlimited number of source and destination chains and enable a broad spectrum of functionalities, including the transfer of tokens, smart contract calls, and general messaging. However, this security model compounds the risk on two or more validator sets, rather than a single source or destination chain.

Light Clients

Light clients verify an event or condition on a blockchain to instruct a corresponding action on another monitored chain. Under this approach, a group of actors monitors the events on the source chain and generates cryptographic proofs for witnessed events, such as block height or smart contract data. These proofs are recorded in smart contracts or raw blockspace on both blockchains. This model only utilizes validators directly connected to consensus and economic security for those blockchains.

This type of bridge minimizes trust assumptions by relying solely on cryptographic proofs validated on the source and destination chains. As a result, the security of a cross-chain transaction is bounded by the consensus integrity of both chains and the correctness of the light client implementations that connect them. Light clients on both the source and destination chains must be maintained, including any updates to maintain compatibility with both blockchains. This raises complexity and development costs, diluting risk by increasing visibility of the code used.

Liquidity Networks

Liquidity networks enable cross-chain transfers by coordinating pre-funded pools of native assets across multiple blockchains. Rather than minting wrapped tokens, they route transactions between users based on the liquidity available at each endpoint. When a user sends an asset on one chain, the network fulfills the transfer by releasing an equivalent amount of the corresponding native asset from its pool on the destination chain. No new tokens are minted; the exchange is fully backed by deposited liquidity.

While this model avoids wrapped assets, it introduces custodial risk by concentrating control in the hands of liquidity managers, who must secure vaults or manage private keys. These systems tend to favor large-cap assets and struggle to scale support for long-tail tokens, where liquidity fragmentation makes routing unreliable. Additionally, liquidity networks generally only support asset transfers, not arbitrary message passing or contract calls.

Cosmos IBC as the Standard and Its Limitations

The Cosmos IBC protocol uses a template light client to verify cross-chain messages. In this setup, both the source and destination chains maintain a light client of the opposite chain on their respective networks, starting from a universal point of similarity. This architecture does not require third-party verification outside the connected light clients, though it’s common to involve relayers as tools to enhance user experience. While IBC strikes a balance between security, cost, and speed, implementing it outside the Cosmos ecosystem introduces non-trivial complexity, as the default Tendermint light client template applies only to chains built on the Cosmos SDK.

The Cosmos SDK provides a Tendermint light client implementation for all blockchains based on the Tendermint consensus, easing development costs with a default template. Unfortunately, there is no corresponding light client implementation for most (non-Cosmos) blockchains, and many do not anticipate light clients in their core designs. To implement IBC with a Cosmos chain and a non-Cosmos chain, developers must match complementary light clients to accommodate both blockchains. Development knowledge of both blockchains is required, and technical challenges arise in stabilizing the connection across multiple states. Because verifying cross-chain state transitions on-chain is resource-intensive, light clients typically rely on cryptographic proofs (e.g., Merkle roots or zk-proofs) or off-chain compute to validate state without parsing full blockchain histories.

Another challenge of the IBC protocol is token non-fungibility across different routes. In the Cosmos IBC framework, tokens transferred through different routes acquire distinct IBC denominations based on their localized paths. For example, token X transferred directly from Chain A to Chain B will differ from token X transferred via Chain C (A → C → B) due to variation in IBC channel metadata. This can lead to fragmentation in liquidity and usability if unmanaged. Cosmos chains can implement canonical token mappings, governance-based whitelisting, outposts, or relayer coordination to unify token representations and mitigate liquidity fragmentation issues. Still, these are features unique to IBC in its original stack.

The final limitation of Cosmos IBC lies in its reliance on relayers, which are off-chain agents that monitor and transmit IBC packets between chains. While not strictly required for protocol correctness, relayers play a crucial role in maintaining responsiveness. Without them, cross-chain transactions may appear stalled, even when successfully committed on-chain. Relayers submit proofs from the source to the destination chain, allowing user interfaces to reflect transaction status in near real-time. They also typically cover gas fees on the destination chain, further smoothing the user experience. While IBC ensures that relayers cannot tamper with or censor messages, the protocol still depends on their availability to relay packets in a timely manner. Because most relayers are uncompensated, this can create a recurring bottleneck for responsiveness and reliability, especially in user-facing applications.

Omnity’s Adaptive IBC: Enter ICP

Light clients are the core of IBC. They track the state of their counterparts to coordinate bridging, but the result of their awareness isn’t limited to asset transfers. Cosmos’ foundation and its architectural partners grew interoperability features around the Cosmos SDK, but struggled to extend them to non-Cosmos chains. While there are multiple non-Cosmos IBC designs, they are expensive to maintain, and their incentives align weakly across blockchain economies.

That’s where ICP comes in. ICP can witness multiple blockchains and generate immutable proofs in under 500ms, enabling it to trigger state changes across two chains in near real-time. While other blockchains can replicate parts of this functionality through augmentation, they often lack the dedicated infrastructure and tightly integrated architecture that ICP provides (see Technologies below). Comparable approaches built on monolithic blockchains typically require an external data availability (DA) layer to coordinate similar operations, which can increase system complexity and introduce additional cost and risk. In contrast, ICP manages data and state natively within its execution layer, reducing external dependencies and improving performance predictability.

Omnity first developed the Adaptive IBC concept to connect NEAR Protocol and Cosmos blockchains. Instead of relying on on-chain light clients, Adaptive IBC uses off-chain verification proxies hosted on a third-party public blockchain (proxy chain) to track the consensus state of the source chain (Cosmos). These off-chain proxies validate IBC messages and produce a single signature attesting to the message’s validity. A lightweight on-chain proxy client on the destination chain (any other blockchain) then verifies this signature, eliminating the need for full consensus verification on-chain.

This architecture simplifies cross-chain communication beyond Cosmos but does not resolve other IBC limitations, such as relayer dependence or lack of generalized message support. After testing several proxy chain candidates, Omnity selected the Internet Computer (ICP) for its strong performance, verifiability, and security, as well as its ability to address IBC limitations like relayer dependence and limited messaging.

Omnity’s Shift to ICP

By leveraging Dfinity’s commitment to a multi-chain thesis and Bitcoin, Omnity mitigates the current limitations of Cosmos IBC, including connecting multiple blockchains for a single asset, token non-fungibility, and reliance on third-party relayers.

Source: Hackernoon

The Internet Computer hosts all Omnity components within its decentralized, modular blockchain architecture, using smart contracts called “canisters” to support verifiable, cross-chain logic beyond Bitcoin’s native capabilities. Omnity builds on ICP’s full-node Bitcoin integration and support for widely adopted cryptographic standards, enabling streamlined Bitcoin asset handling through native and custom light clients. Omnity’s smart contract orchestration is compatible with any blockchain by abstracting asset properties into a standard token format recognized by ICP canisters.

One of ICP’s key advantages is its subnet architecture, which allows specialized subnets to host full nodes of external blockchains, such as Bitcoin, and a native smart contract layer (canisters) within the same execution layer. This co-location enables canisters (smart contracts) to directly observe and verify external blockchain states without relying on third-party infrastructure.

This design addresses a significant limitation in Cosmos IBC: verifying transactions across heterogeneous blockchains. IBC is typically deployed between common blockchain templates, so integrating state from structurally different chains, such as UTXO-based Bitcoin, often requires data normalization or a "flattening.” On ICP, full Bitcoin nodes can run alongside smart contracts, allowing rich Bitcoin transaction data to be directly queried, validated, and acted upon within the same execution environment. This makes it possible to coordinate cross-chain logic not only between ICP and Bitcoin, but also across other networks.

IBC implementations on ICP reduce reliance on third-party relayers by recording execution receipts directly on-chain with sub-second block times. Each attempted cross-chain action results in an immutable receipt that can be independently queried over HTTP through ICP’s canister-based web serving capabilities. This allows any user, relayer, or verifier to fetch cryptographic proof of execution or failure without trusting intermediaries or running a full node.

Omnity replaces traditional relayers with user-initiated message relaying directly from wallets or browsers by taking advantage of ICP’s Reverse Gas Model, where canisters pay for execution instead of the user. Once a cross-chain message is authorized on the ICP chain, pre-funded canisters autonomously execute all logic without further user interaction. Additionally, ICP’s Chain-key cryptography simplifies cross-chain message verification by allowing smart contracts to securely sign output data, reducing the computational and gas overhead typically associated with cross-chain communication.

Integrated ICP Technologies

Omnity harnesses the features and mission of ICP to build resilient and scalable cross-chain solutions. With ICP's distinct capabilities, including Chain Fusion, Chain-key cryptography, and the Reverse Gas Model, Omnity can balance UX, security, and long-term reliability.

Chain Fusion

Chain Fusion grants ICP interconnectivity with multiple blockchains, clients, virtual machines, smart contracts, and nodes. Chain Fusion has achieved deep integrations with major blockchains, such as Bitcoin and Ethereum, with Solana and others on the roadmap.

Source: ICP

ICP Canisters Interact Natively with the Bitcoin Network

Omnity’s Chain Fusion strategy focuses on Bitcoin. ICP canisters interact with Bitcoin directly. Canisters can directly receive, hold, and send BTC on the Bitcoin mainnet without using intermediaries or third-party bridges. This is made possible through specialized Bitcoin subnets, where ICP validators also run full Bitcoin nodes within the same execution environment. These subnets maintain the full UTXO set and allow canisters to locally query Bitcoin state, including script data and ledger history.

Canisters can also broadcast transactions directly to the Bitcoin network, signing them securely using Threshold Schnorr Signatures, an ICP upgrade supporting Taproot. This follows previous upgrades that introduced threshold ECDSA signing, enabling canisters to handle ECDSA keys, found in over 70 public blockchains and thousands of SaaS and mobile applications.

To maintain cryptographic security, ICP’s Chain-key cryptography, utilizing ed25519, ensures that private keys are never stored or exposed, even to the nodes themselves. Signing operations are distributed and threshold-based, preventing key leakage and eliminating the need to embed private keys in canisters.

Chain-Key Cryptography

Chain-key cryptography is one of the core technologies of ICP. Unlike traditional systems, where a single party holds a private key, Chain-key cryptography ensures that no subset of potentially misbehaving nodes can misuse a private key. Chain-key fragments the encrypted private key into private key shares and distributes these key shares to all nodes in a subnet. No node ever sees the whole private key, its own share, or any other node’s share.

To generate a valid digital signature, these nodes must collaboratively sign messages with a minimum (threshold) number of these shares. The threshold t is set such that t=⌈n/3⌉+1, where n is the total number of nodes in the subnet. Consequently, the network can tolerate up to one-third of the nodes failing or acting maliciously without disrupting its operations.

Source: Hackernoon

These BFT key shares are reshuffled every 1-2 hours among each subnet’s nodes to mitigate any compromise or abuse of shares. ICP’s distributed key generation (DKG) daemons utilize zero-knowledge proofs and elliptic curve cryptography to distribute key shares and randomize their reshuffling. Once reshared, the aged-out shares become obsolete, rendering them useless to any malicious actors or stale network participants.

When new subnets are created, the Internet Computer’s Network Nervous System (NNS) coordinates their initial key generation. The NNS is a DAO that governs the Internet Computer. It manages upgrades, node assignments, and the creation of subnets through governance actions. Because the NNS is designed to be trustless and decentralized at the protocol level, it cannot rely on a single trusted entity, so multiple NNS nodes must act as “dealers” for new subnets. Each dealer encrypts key shares for the new subnet's nodes and proves the correctness of these shares using zero-knowledge proofs. The contributions of all honest dealers are then combined to produce a single public key for the subnet and valid private key shares, ensuring the secure and decentralized bootstrapping of subnet keys.

Threshold-Schnorr Signing

ICP added threshold-Schnorr via ed25519 as a vehicle for ECDSA signing. Both threshold ECDSA and threshold Schnorr signatures are cryptographic techniques used to distribute the generation of signatures. Both schemes allow the encrypted private key to be divided into shares and distributed across different nodes in a network, where each node holds a partial key share. This enables several layered multi-chain designs, including correlating Bitcoin Taproot transactions with Ethereum transactions, or even supporting private blockchains. Omnity uses threshold-Schnorr signing (TSS) for Bitcoin inscriptions, runes, and other on-chain assets, such as SPL20 tokens (Solana token standard).

Reverse Gas Model

ICP introduces a Reverse Gas Model that shifts the responsibility for transaction fees from users to smart contracts. Instead of requiring users to pay gas fees, canisters fund execution using cycles, a non-redeemable resource token consumed during computation. This model allows users to interact with dApps without holding tokens or wallets, much like they use traditional web or mobile apps. It also enables developers to design onboarding flows where computation costs are pre-funded, a key requirement for freemium or pay-later SaaS-like models. Since cycles can’t be redeemed or traded, they serve purely as a metered compute resource.

Omnity Applications

The Omnity Hub

Omnity is built on ICP’s Chain Fusion infrastructure, which provides outbound HTTP, on-chain compute, and Chain-key cryptography to support verifiable cross-chain coordination. On top of this, the Omnity Hub introduces a modular hub-and-spoke architecture that connects Bitcoin and other public blockchains through dedicated smart contract components.

The Omnity Hub is a public coordination layer composed of canisters on ICP that manage cross-chain transactions. Each spoke is an additional canister responsible for interacting with a specific blockchain or ecosystem. Together, they form a permissionless interface for moving Bitcoin-native assets across multiple networks.

Source: Omnity

The Hub is natively integrated with Bitcoin, allowing users to sign and submit Bitcoin transactions through ICP. Spokes then route these transactions to other supported blockchains, enabling trust-minimized movement of tokenized Bitcoin assets beyond Bitcoin L1.

Today, Omnity supports routes to Bitcoin, Ethereum, Solana, Ton, ICP, and several Bitcoin L2s such as Bitlayer, Bitfinity, and Core. In Q1 2025, Omnity announced a temporary reduction in L2 support to streamline development and maintenance workloads, while keeping all related ICP contracts and blockchain addresses publicly accessible.

The Omnity Runes Indexer

Omnity’s Runes Indexer is the first fully on-chain Bitcoin asset indexer to deliver structured OP_RETURN data to applications across blockchains. While Bitcoin full nodes typically ignore OP_RETURN metadata, it has become central to BTCFi protocols like runes, Ordinals, and other emerging designs that operate entirely within Bitcoin’s existing consensus rules. These metaprotocols introduce new functionality, such as token issuance or digital artifacts, without relying on additional validators, external consensus layers, or wrapped assets. Websites like mempool.space have begun to visualize Bitcoin metaprotocol activity in real time, making it easier to confirm asset-related data through mainstream Bitcoin index services.

Omnity’s Runes Indexer currently powers applications like Odin.fun , Liquidium, and Blockminer by making Bitcoin asset data verifiable and available in near real time. Although OP_RETURN metadata is eventually confirmed on the Bitcoin ledger, it can be observed earlier through ICP’s Bitcoin subnet, which monitors the mempool directly. This allows canisters to expose rune metadata within approximately one second of broadcast, well before it is finalized on-chain.

The Runes Indexer serves as an on-chain backbone for emerging BTCFi protocols by providing developers with auditable, resilient Bitcoin asset data. This data supports a range of financial use cases, including lending, yield farming, derivatives, and fractionalized digital assets via recursive inscriptions. By indexing and exposing OP_RETURN inscriptions, the Runes Indexer can also support newer protocol designs such as Alkanes, a WASM-based smart contract system. Its flexible parsing framework is well-suited for early-stage standards like BRC2.0, which aims to extend fungible token functionality on Bitcoin. As of this writing, the Runes Indexer is fully compatible with Ord version 0.22.1.

The Omnity Hub Empowers BTCFi on Bitcoin L2s

Bitcoin isn't designed for complex programmability or high-speed execution. Transaction costs and 10-minute block settlement times limit the use of runes, Ordinals, and other assets. Bitcoin L2 networks address these limitations by processing transactions adjacent to Bitcoin itself. These networks typically execute transactions off-chain and settle selectively on Bitcoin, which allows them to increase throughput without being constrained by the 10-minute block interval. This architecture supports applications such as low-fee swaps, high-frequency trading, or gaming, which would be impractical on Bitcoin mainnet due to its latency, limited capacity, and reliance on miner-based finality.

The Omnity Hub makes Bitcoin metaprotocols like runes accessible across BTCFi applications on Bitcoin L2s, allowing them to be traded as fungible tokens. Users move runes to connected chains by locking their assets in hashed timelock contracts (HTLCs), where the Omnity Hub canister acts as the counterparty. These contracts are fully non-custodial, and assets can be withdrawn by the user at any time, provided the on-chain protocol rules are followed. In addition to transferring assets, users can etch, mint, and burn runes directly through the Omnity dApp. The “Add Runes” interface (see figure below) allows anyone to fund cross-chain metadata and extend interoperability to any Bitcoin rune, functioning as a permissionless bridge for onboarding new assets.

Source: Omnity

Omnity’s Native BTCFi Solution: Runes Exchange Environment (REE)

Layer 2 solutions extend Bitcoin’s functionality by moving execution off-chain, but each introduces its own trust assumptions, whether through external validators, rollups, or custodial bridges. In contrast, Omnity developed the Runes Exchange Environment (REE) as a new execution model built directly on Bitcoin. REE sidesteps the need for forks, bridges, or new opcodes by linking Rust-based smart contracts to Bitcoin core within the same runtime environment, achieving programmability without modifying Bitcoin’s consensus rules.

REE is not a validator network. It’s an application layer. REE adds a programmability environment to Bitcoin with smart contracts (canisters) instructing Bitcoin full nodes on the ICP blockchain. Unlike traditional Bitcoin L2 solutions, REE initiates Bitcoin locally without asset bridging or locking, preserving Bitcoin's security and introducing programmability through smart contracts.

Source: Omnity Docs

REE embraces Bitcoin UTXOs while providing advanced programmability and self-custody. REE adopts Bitcoin’s Partially Signed Bitcoin Transaction (PSBT) from BIP-370. This allows traders to interact with smart contracts directly without requiring asset lockups or deposits to an L2 solution. Instead, users simply sign a PSBT using their Bitcoin wallet. Once a user signs and broadcasts a PSBT, REE detects it in the Bitcoin mempool (typically within 2 seconds) and triggers a corresponding smart contract response, completing the transaction on-chain.

A Partially Signed Bitcoin Transaction (PSBT) is a flexible format that allows multiple parties to collaboratively construct and sign a Bitcoin transaction before finalization. PSBTs are designed to be incomplete until all required inputs and signatures are present, making them ideal for multi-party coordination without custodial risk.

In REE, applications registered with the REE Orchestrator can participate in this signing process directly. When a user signs and broadcasts a PSBT from their Bitcoin wallet, ICP Bitcoin subnet nodes monitoring the Bitcoin mempool detect the transaction in progress, either as a PSBT (pre-confirmation) or a completed UTXO (post-confirmation). This real-time observation forms the foundation of Omnity’s Decentralized PSBT Signer (DPS), a system where REE smart contracts complete user-submitted PSBTs by appending their own logic and signatures.

DPS eliminates the need for centralized servers or trusted relayers. It enables decentralized execution flows, where user-initiated PSBTs are picked up and completed by on-chain logic, resulting in finalized Bitcoin transactions without asset custody, protocol forks, or new opcodes.

Source: Omnity

REE’s Orchestrator smart contract is a verifiable on-chain coordinator. When users sign PSBTs with their Bitcoin wallets, REE applications emit transaction data and complementary PSBTs based on their logic and asset pools. The Orchestrator ensures consistency and atomicity by validating these PSBTs and coordinating execution. Although currently used for rune swaps, this PSBT-based coordination model can also support custom smart contract logic written in Rust, Motoko, or JavaScript. These contracts can interact with Bitcoin through UTXO validation and coordinated signing workflows.

REE BTCFi Exchange-Pool Model

REE’s Exchange-Pool model adapts Bitcoin’s UTXOs to an account-based identity on ICP. REE exchanges are independent ICP canisters (smart contracts) that can fully leverage the capabilities of the underlying blockchain, including the unique benefits to handle HTTP requests and containers on-chain. The Exchange-Pool model is composed of three basic concepts:

1. Coin: a unit of UTXO-based Bitcoin assets. BTC and runes are accepted as coins in REE.
2. Exchange: any BTCFi protocol operating on the REE platform.
3. Pool: a public key (Chain-key) that an exchange uses to hold coins and sign Bitcoin transactions. An exchange can manage multiple pools, each with its own coin holding and state.

REE exchanges have the composability to integrate across protocols and combine logic and liquidity in a trust-minimized framework. Because exchanges on REE are implemented as ICP canisters, BTCFi developers gain access to a broader design space, including features like native web serving, cross-canister calls, and persistent state.

REE Use Cases

Lending

REE supports lending protocols composed of configurable pools, where each pool can define parameters such as collateral types, interest rates, and liquidation thresholds. For example, BTC can be borrowed against blue-chip runes, with smart contracts enforcing overcollateralization and monitoring pool health.

A real breakthrough lies in REE’s ability to decentralize oracle logic through canisters running on ICP. Traditional Bitcoin-native systems like Discreet Log Contracts (DLCs) rely on external oracles that are difficult to decentralize and integrate at scale. On REE, however, price feeds and liquidation logic can be implemented as autonomous, auditable canisters, eliminating the need for trust in a single data source. These canisters can ingest off-chain price data, cryptographically verify feeds across multiple sources, and trigger liquidation logic by coordinating with the REE Orchestrator over PSBT workflows.

This architecture enables native Bitcoin implementations of DeFi use cases such as lending, stablecoin issuance, and collateralized options, while preserving user custody and maintaining verifiable state across chains. REE makes it possible to build lending protocols that are both trust-minimized and verifiably decentralized end-to-end.

Liquid Staking (LST)

While REE could support Bitcoin staking natively, a more intriguing option might be to support Bitcoin staking by integrating with a protocol such as Babylon, which enables Bitcoin L1 staking via a dedicated appchain. In this potential design, users deposit BTC and receive rune-based Liquid Staking Tokens (LSTs) issued on REE. These LSTs represent claims on delegated stake and can be composed into BTCFi protocols for use in lending, yield strategies, or derivatives.

Staking and reward distribution remain anchored to Bitcoin L1 and Babylon’s validator set. At the same time, REE manages LST issuance and composability directly on Bitcoin, without relying on bridges, wrapped assets, or independent execution layers. Trustless coordination between Babylon and REE is achieved through cryptographic cross-chain messaging, allowing canisters to verify stake state and interact with native Bitcoin assets programmatically.

By combining REE’s programmability with Babylon’s staking architecture, this design preserves Bitcoin self-custody, removes reliance on trusted intermediaries, and brings liquid staking in line with Bitcoin’s native trust model.

AMM DEX: RichSwap

As the first DEX deployed on REE, RichSwap provides a reference implementation for developers. It supports Bitcoin and Runes trading pairs and runs fully on-chain. While Omnity hosts the frontend (richswap.io), all transaction logic is executed directly on Bitcoin, coordinated by canisters exposed on ICP for verification and tracking, with no bridges, wrapped assets, or off-chain components involved.

RichSwap was built to solve the liquidity cold-start problem common to new DeFi protocols. On REE, 100% of liquidity is shared with any application in the environment. PSBT-based transaction coordination allows inputs and outputs to be composed across applications. This means that liquidity deposited into RichSwap can be reused by other BTCFi protocols without fragmenting capital or spinning up isolated pools.

The RichSwap contracts are open source and designed to be forkable, extendable, and auditable. Developers building on REE can use RichSwap as a baseline for integrating native swaps, liquidity coordination, and composable PSBT workflows into their own BTCFi applications.

RichSwap users retain custody of their Bitcoin at all times. Funds remain in user-controlled wallets; all transactions are signed locally before being submitted to the Bitcoin network. Liquidity pools are non-custodial and governed by smart contracts running on ICP subnets verifying Bitcoin state (see Chain-key).

When a swap is initiated, the transaction logic executes and finalizes on ICP within seconds. The resulting PSBT is broadcast to the Bitcoin mempool, where it waits to be finalized.

This yields an immediate path to optimistic transactions on Bitcoin, including support for limited reentrancy between REE contracts during the same logical session.

Source: RichSwap

RichSwap supports swaps between Bitcoin and runes, liquidity provision, and withdrawal. For example, when a user swaps BTC for a rune, the REE TypeScript SDK constructs a PSBT locally in the browser, locking in trade parameters using appropriate sighash flags. The user signs this PSBT to pre-authorize their side of the trade. Once broadcast to the Bitcoin mempool, it’s picked up by the REE DPS (Decentralized PSBT Signer), which validates the transaction inputs and outputs against expected values, and subsequently requests a PSBT from the RichSwap pool. After all parties sign their respective PSBTs, REE rebroadcasts the fully signed transaction to the Bitcoin network.. RichSwap’s next major roadmap feature reportedly includes a runes-to-runes swap within a single transaction.

RichSwap shows how REE supports Bitcoin-native DEX functionality by offloading contract logic to ICP while preserving on-chain settlement on Bitcoin. It provides a concrete example of REE’s UTXO-based exchange-pool model, bringing familiar DeFi mechanics, typically found on account-based blockchains like Ethereum, into the BTCFi ecosystem.

Conclusion

Drawing from Cosmos IBC and other battle-tested solutions, Omnity integrates the Internet Computer to eliminate auxiliary validators and mitigate the complexity of Tendermint for non-Tendermint light clients.

The Omnity Hub offers a trust-minimized framework for multi-chain Bitcoin-native asset handling with verifiable coordination through Internet Computer (ICP) smart contracts. Instead of asset custodians or third-party relayers, Omnity takes advantage of ICP’s Chain-key cryptography and smart contracts on ICP’s Bitcoin subnet. Omnity’s Runes Indexer fills a structural infrastructure gap for BTCFi development. It supports emerging Bitcoin asset standards by providing organized access to verifiable, low-latency Bitcoin asset metadata from the Bitcoin mempool to smart contracts.

The Runes Exchange Environment (REE) extends Bitcoin’s functionality without third-party risk by exposing programmable interfaces and offering real-time on-chain data for developers to create programmable and composable applications directly on Bitcoin using UTXO logic and standard transaction formats. REE’s standard usage of PSBTs coordinated by DPS means Bitcoin developers can deliver secure, non-custodial protocols without any changes to Bitcoin, thanks to the SaaS-grade tools on Dfinity’s ICP.

Omnity provides a composable, modular architecture with developer tooling and automatic signing from a resilient sub-network of Bitcoin full nodes unified by Bitcoin’s on-chain security and ICP’s on-chain logic. Omnity’s open-source tooling, pioneering contract framework, and native on-chain indexers offer Bitcoin applications a home void of proprietary software without compromising security and scalability.