The Omnity Hub is a robust and comprehensive blockchain interoperability stack built for Bitcoin. Today, it supports Bitcoin’s top three fungible asset classes—Bitcoin, BRC-20, and Runes. Omnity also seamlessly connects four distinct blockchain types: EVM, Cosmos, Solana, and ICP, while maintaining a 100% on-chain standard. Integrating a new EVM-compatible chain, such as Base, BSC, or Arbitrum, adding a Cosmos chain, enabling BRC-20 on Solana, or connecting ckBTC with Ethereum or BSC—all these expansions can now be achieved with lightweight noncustom code.
Crossing a bridge is notorious for its history of hacking because getting heterogeneous chains to talk to each other creates additional attack vectors and off-chain vulnerabilities. We never want any losses to happen on Omnity. Thus, the solution for Omnity is the Internet Computer’s Chain Fusion integrated with Omnity’s IBC light-client technology. We detail our IBC journey in the Omnity Lightpaper and have written about its potential to scale Bitcoin. But in this article, we want to shine the light on what led our seasoned interoperability stack developers to want to build on Dfinity’s technology in the first place. In ICP’s powerful smart contract platform and advanced cryptography, we finally saw the ability to build a cross-chain solution that meets our standard of trustlessness.
Omnity’s Trustless Solution for BTCFi Innovation
Bitcoin is a decentralized ledger for peer-to-peer transactions and isn’t designed for complex programmability or high-speed execution. Its scripting language is intentionally limited and non-Turing complete, upholding security while disincentivizing complex interactive applications on Bitcoin. Smart contract platforms have seized the marketing opportunity to complement Bitcoin, trialing all sorts of DeFi before BTCFi would be worth the sats.
Omnity was engineered to address Bitcoin’s constraints. Built on the most powerful smart contract platform to date, the Omnity Hub has native integration with Bitcoin and shares it trustlessly with other blockchain networks. Through Omnity, Bitcoin metaprotocols can be accessed across BTCFi dApps and traded as fungible tokens. Omnity is particularly interested in the untapped potential of Runes across broad sectors.
The Untapped Potential of Runes
Runes are a technically sound and widely accepted fungible token standard for the Bitcoin ecosystem. They can be structured to represent different assets or value classes — such as stablecoins, BTC derivatives, or utility tokens — and used in diverse applications like lending, staking, yield generation, and swaps.
Runes are etched directly onto Bitcoin using the OP_RETURN opcode. This allows arbitrary data to be written on-chain without impacting Bitcoin’s UTXO set, creating an immutable, secure, tamper-resistant record for each Rune, defining and authenticating the Rune’s properties, and setting a maximum limit. Minting converts the etched record into tokens that can be transferred, traded, or used in various DeFi applications on Layer 2. The etched Rune ensures the asset’s authenticity, while minting puts it into circulation as a tradable token.
Burned Runes are subtracted from the circulating supply but don’t change the original etched limit. This means users can influence the active supply within BTCFi without altering the transparency or security of the fixed maximum etched on Bitcoin. Omnity’s cross-chain solutions for Bitcoin assets give Runes the potential to disrupt liquidity markets.
The Omnity Ord Canister: The 1st Fully On-chain Bitcoin Metaprotocol Indexer
Omnity’s Ord Canister is the first on-chain, fully trustless Bitcoin asset indexer. It’s indispensable for building a secure, transparent, interconnected BTCFi ecosystem. The indexer acts as the “backbone” for BTCFi, allowing users and developers to view and manage their Bitcoin assets across different platforms.
Omnity doesn’t need to rely on any external entity to tell us what’s happening with Bitcoin.— Louis Liu, Founder of Omnity.
Ord Indexer makes it easier for users to engage with diverse dApps without manually tracking assets or risking loss during cross-chain transactions. BTCFi developers can leverage real-time, accurate data on Bitcoin assets to build novel financial applications, such as yield farming, lending, and derivatives.
The Ord Canister occupies a few GB of on-chain storage and actively extracts blocks from the RPC service. This is only possible because of the remarkably robust smart contracts built by Dfinity engineers. ICP’s smart contracts’ capabilities are just not available on any other blockchain.
ICP’s Powerful Smart Contract Platform
ICP smart contracts (canisters) can interact directly with the Bitcoin network — reading and writing to it without external bridging mechanisms. Canisters are full-stack, highly advanced, scalable smart contracts with robust storage and web-serving capabilities, making them vastly more powerful and versatile than basic Ethereum smart contracts.
For context, Ethereum contracts offer theoretically limitless storage through an unlimited number of 32-byte (256-bit) slots but face practical limitations due to high gas costs associated with on-chain storage operations. Writing data that remains on-chain can become incredibly expensive, so Ethereum-based applications often offload large data to external solutions like IPFS or Arweave, referencing this data within smart contracts rather than storing it directly.
In contrast, ICP canisters are designed to handle extensive state data directly, offering a stable memory capacity of up to 400GB per canister. Canisters can store large data sets or any data that requires long-term persistence without relying on off-chain solutions. Canisters can even support fine-tuning AI models.
ICP’s reverse gas model, where developers pay for execution costs rather than users, allows users to interact with ICP smart contracts without needing gas or a wallet. For example, Omnity’s Red Envelope Runes mini app bot lets you share and receive Runes across multiple Web2 platforms.
Canisters also natively support HTTP requests, which means they can serve web content directly to users. Therefore, a canister can act as both a backend for a dApp and a web server. Entire websites and applications can run directly on Internet Computer smart contracts without traditional cloud infrastructure. The storage is decentralized on-chain.
Finally, unlike Ethereum smart contracts, which are constrained by synchronous and gas-limited transactions, canisters operate with asynchronous messaging. Canisters can call one another, handle requests, and manage state independently of the execution timeline of a single transaction.
Canisters allowed Omnity the power and flexibility to move tasks (which typical require off-chain or 3rd party bridging mechanisms) entirely on-chain within a trustless, decentralized network secured by advanced cryptography.
How Omnity Integrates with Bitcoin
Omnity’s integration with ICP’s Chain Fusion secures our seamless cross-chaining of Runes. This is demonstrated on the Omnity Hub with the Runes that Omnity zips around between Bitcoin and any chain for which we’ve built an on-chain light client.
Omnity only incorporates an ICP settlement chain into its hub when full-node security can be achieved. Once ICP integrates a subnet to support a chain, Omnity can securely connect it to any other chain with no off-chain components. Technically, ICP is not running a Bitcoin bridge as Dfinity’s technology effectively separates the bridging logic from asset custody.
How Omnity Talks to Bitcoin
Omnity is integrated with the ICP Bitcoin Subnet. When a canister (such as Omnitys’) on the ICP network wants to perform a Bitcoin transaction, it sends a request to the Bitcoin Subnet, where the Bitcoin Canister resides.
The Bitcoin Canister initiates the signing process using ECDSA threshold signatures among the Subnet Nodes. (Chain Key cryptography is complemented by ICP’s Byzantine Fault Tolerance (BFT) framework. We discuss this below.) The Bitcoin Canister submits the transaction to the Bitcoin Network via the Bitcoin Adapters.
Each Subnet Node in the Bitcoin Subnet has a Bitcoin Adapter daemon independently connected to the Bitcoin Network. These adapters listen to the Bitcoin blockchain, receive updates on new blocks and transactions, and relay this information to the Bitcoin Canister.
Once a transaction is sent, confirmation from the Bitcoin Network is asynchronous. The Bitcoin Adapters wait for the transaction to be confirmed on Bitcoin, then update the Bitcoin Canister to reflect the new state of the UTXO set so that all the ICP canisters, including Omnity, have an accurate view of Bitcoin’s unspent outputs and know what happened on Bitcoin.
How Omnity Enables Cross-chain Access to Bitcoin
Omnity adds a hub-and-spoke structure to ICP’s Chain Fusion stack. Spokes are the components that take care of the on-chain light client verification and RPC adoption, connecting Omnity Hub with blockchains like Solana, Cosmos, or Ethereum. The Omnity Hub orchestrates where Bitcoin assets should go, and the Spokes provide the route. Meanwhile, the Ord Canister actively reaches out (using RPC) to the Bitcoin Network to pull in the latest blocks and keep track of Bitcoin’s state for cross-chain operations.
Omnity consistently adds Spokes for various Bitcoin Layer 2s. Users can connect to Omnity and move Runes to any connected chain without leaving a simple Dapp environment. Users can even mint and burn Runes directly from within the Omnity Dapp, with the result reflected on Bitcoin. The Omnity Hub’s cross-chain infrastructure can offer this simplified development environment and user experience with unparalleled security because ICP smart contracts can orchestrate advanced threshold signing cryptography.
The Magic Keys: Chain Key Cryptography
The first problem in securing a cross-chain bridge is determining who holds the private key. — Louis Liu, Founder of Omnity.
Tldr; ICP magically generates and shifts broken pieces of a single private key periodically amongst nodes. ICP calls this Chain Key cryptography. To visualize this, we should consider the robustness of ICP’s smart contracts, which can securely sign transactions using threshold signatures. Chain Key threshold signing is a Multi-Party Computation (MPC). In this cryptographic protocol, multiple parties collaborate to compute a function without revealing their inputs, preventing private key exposure across nodes.
ICP’s Bitcoin subnet has 34 node operators (at the time of this reporting) spread across different continents in diverse geographic locations. Each node on a subnet has control over a unique ECDSA public key, but the secret signing key is split into shares and distributed among the nodes in the subnet.
More than one-third of the nodes must participate in the signing process to generate a valid signature. 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. Simply put, one more than one-third must sign, and no more than one-third must fail.
Nodes can’t access their private key shares and can only request signatures for their public key because the private key is never stored in a single place. It never exists anywhere in a reconstructed form; it only exists in secret-shared form— no node sees the whole key, its own share, or any other node’s share.
ICP’s Distributed Key Generation (DKG)
ICP’s Distributed Key Generation (DKG) manages secret keys across multiple parties by distributing the secret key shares to different nodes. DKG involves zero-knowledge proofs and elliptic curve cryptography to distribute key shares and periodically reshuffle them without requiring direct communication between nodes. The resharing process renders previous key shares useless and allows the network to adapt securely to changes, such as node additions or removals.
Byzantine Fault Tolerance (BFT)
Chain Key signing is complemented by ICP’s Byzantine Fault Tolerance (BFT) framework, engineered to keep the network operational even if some nodes fail or act maliciously. If any nodes should fail, join, or rejoin, those nodes synchronize using a Catch-Up Package (CUP) — a snapshot of the subnet’s state — and reintegrate without compromising security or slowing down the subnet. The CUP, which includes a Merkle hash of the entire subnet state, is generated at the end of each epoch to provide a consistent state from which any disrupted nodes can restart. (An epoch is a fixed operational period that includes multiple consensus rounds and ends with a summary block of the finalized state for that period.)
Omnity Eliminates the Chasm Between Bitcoin and Other Networks
Omnity’s vision is a BTCFi landscape that eliminates the chasm between Bitcoin and diverse networks without compromising robust security, transparent asset management, and minimized trust. The Omnity Hub was designed to eliminate single points of failure. ICP’s Chain Key cryptography for cross-chain has secured its multi-billion dollar network for roughly three years, and its powerful smart contracts allowed us to bring our design to life.
Omnity’s mission is to simplify BTCFi development and allow users to play with Bitcoin assets across multiple chains from a single Dapp. Thanks to the fusion of ICP and Omnity technology, users can easily move Bitcoin assets across the heterogeneous chains and developers have a secure and trustless execution environment for BTCFi innovation.
“Even if aliens abducted the Omnity Team, users would still be able to redeem their Bitcoin assets back to the Bitcoin settlement chain.” — **Louis Liu, Founder of Omnity.
Suzanne Leigh is the Editor of Omnity Network.
