Introduction
So far, interoperability between Bitcoin and Ethereum has been limited, preventing the seamless integration of Bitcoin’s security and liquidity with Ethereum’s flexibility and diverse ecosystem of protocols and assets. The Hemi Network addresses this gap by connecting the two ecosystems, enabling the development of cross-chain applications that approach Bitcoin and Ethereum as components of a single supernetwork. By merging Bitcoin’s security with Ethereum’s programmability, Hemi opens the door to a new era of decentralised applications (dApps) that operate across both chains without the need for intermediaries or centralised exchanges.
Currently, Hemi has announced a $15 million seed round led by Binance Labs, Breyer Capital, and Big Brain Holdings. Interest in the project has been high – since the launch of incentivised testnet in July, over 200,000 Proof-of-Proof (“PoP”) miners testing Hemi’s unique Bitcoin security inheritance mechanism have sent over 95 million PoP transactions on Bitcoin’s testnet3 network. Additionally, community testing of Hemi’s cross-chain asset transfer system (“Tunnels”) at peak accounted for 88% of all traffic on Ethereum’s Sepolia testnet and caused the base gas rate to spike above 10,000 Gwei - a value never before seen on the network.
The Team
Seasoned experts in blockchain development are spearheading the Hemi Network. Jeff Garzik, the CEO and Principal Engineer at Hemi, is a co-founder and CEO of Bloq with a rich history in Bitcoin development. As an early Bitcoin core developer, he worked alongside Satoshi Nakamoto in the early days of Bitcoin. His tenure at Red Hat involved significant contributions to the Linux kernel (work that underpins every Android device and Linux-based data centre today). Jeff’s deep involvement in open-source software development uniquely positions him to lead Hemi’s technical vision.
Max Sanchez, Hemi’s Lead Architect, brings extensive experience in blockchain protocol design. Before joining Hemi, he co-invented the Proof-of-Proof (PoP) protocol for decentralised and permissionless Bitcoin security inheritance. A blockchain enthusiast since 2011, Max has been instrumental in launching innovative technologies like the first testnet utilising post-quantum cryptography. He has also contributed to the identification and disclosure of consensus vulnerabilities in multiple blockchain projects.
Key Features
Hemi is a modular multi-network L2 blockchain focused on securely connecting Bitcoin and Ethereum in a scalable manner. A key feature of Hemi is its robust interoperability layer, enabling seamless asset transfers and data sharing between Bitcoin and Ethereum. This feature creates an EVM- compatible environment for decentralised applications (dApps) that operate across both chains.
The Hemi Virtual Machine (hVM) introduces a novel way to build Bitcoin-aware smart contracts by embedding a full Bitcoin node inside the EVM. The flexibility provides applications with a complete view of Bitcoin’s state without relying on third-party relayers or centralised oracles.
Hemi inherits Bitcoin’s Proof-of-Work security in a fully decentralised and permissionless manner. The novel Proof-of-Proof protocol protects cross-chain transactions from reorg attacks and leverages both Bitcoin and Ethereum to protect users from censorship.
Finally, the network’s architecture is built to extend access to Bitcoin and Ethereum assets, EVM- level Bitcoin awareness, Bitcoin security inheritance, and multi-network censorship protection to an ecosystem of interoperable L3 networks with the flexibility for developers to optimise for different use-cases like AI, gaming, and DeFi.
hVM
The hVM (Hemi Virtual Machine) enables Bitcoin interoperability and programmability by integrating a full Bitcoin node within a fully backwards-compatible Ethereum Virtual Machine (EVM) environment. This integration provides Ethereum-style smart contracts with direct access to Bitcoin’s complete state, including states like the UTXO table, which previous Bitcoin interoperability technologies could not securely provide due to some limitations of Bitcoin’s architecture.
Core Components of the hVM
The hVM consists of three major components – an EVM execution environment, a Bitcoin full node implementation designed to be driven deterministically as part of an L2’s state transition function, and a set of precompile contract endpoints that facilitate communication between smart contracts executing inside the EVM and the Bitcoin full node.
The execution environment used for the hVM is a standard EVM which maintains full backwards compatibility with the Ethereum network, meaning any smart contract that runs on Ethereum can be deployed on Hemi without modification.
The Bitcoin node used for the hVM is a custom-built full node implementation that connects to the Bitcoin P2P network to synchronise Bitcoin blockchain data, but only indexes the chain to a tip specified by the Hemi protocol to ensure deterministic views of Bitcoin state from within the hVM. To drive this indexing, the Hemi protocol maintains its own lightweight consensus view of Bitcoin (using a dual-chain L2 block derivation process). This deterministic driving of the Bitcoin full node ensures that the Bitcoin state data available to smart contracts is universally consistent across all Hemi nodes when processing a particular Hemi block.
The hVM’s precompile contracts connect the EVM execution environment with the Bitcoin node. Endpoints accessible from within the EVM perform queries on the Bitcoin node and return the results to the smart contract inside the EVM.
A fully indexed Bitcoin node within the EVM enables seamless smart contract interactions with the Bitcoin blockchain. By exposing comprehensive Bitcoin data — such as the UTXO set — directly into the EVM, the hVM provides smart contracts with a trustless and deterministic view of Bitcoin’s state. This eliminates the need for external oracles or third-party relayers, enhancing security and decentralisation while enabling cross-chain functionality directly through Ethereum smart contracts.
In other words, Hemi allows smart contracts to access Bitcoin’s state in much the same way they access the state of other contracts within the same EVM. For example, in Ethereum, a contract can interact with Uniswap to retrieve the current price of an asset without relying on external data sources; all necessary information is inherently available within the EVM.
This seamless access is possible because the EVM ensures the correctness of the data by default. Similarly, Hemi enables contracts to directly query Bitcoin’s state — including specific transaction details — without the need for oracles or relayers. While the analogy isn’t exact (since Hemi provides more extensive access to Bitcoin data than the EVM typically offers for its own chain) it illustrates how Hemi enhances cross-chain capabilities by making Bitcoin’s state readily accessible within smart contracts.
Smart Contract Bitcoin Event Subscriptions
A slated feature of the hVM will further expand functionality by enabling real-time subscriptions to Bitcoin events. With the hVM event subscriptions, developers can program smart contracts to automatically execute specific actions based on Bitcoin events such as transaction confirmations, the mining of new blocks, or the spending of a particular transaction output. Event subscriptions also allow developers to build applications that respond dynamically to Bitcoin activity. This architecture supports highly customisable logic, enabling conditional workflows that don’t require onchain initiation from an Externally Owned Account (EOA) on Hemi.
For example, escrowed funds in a non-custodial DEX could be released when a particular Bitcoin address receives the expected quantity of Bitcoin to complete a trade, or an operator could be deactivated from the active operator pool of a Bitcoin restaking protocol if they publish a transaction on Bitcoin that initiates a claim procedure to withdraw staked BTC collateral.
Enabling Cross-Chain Workflows
In addition to Bitcoin awareness, the hVM maintains awareness of Ethereum by processing Ethereum transactions that perform cross-network calls to Hemi during the L2 block derivation process. The hVM can also initiate outgoing calls to contracts on Ethereum.
As a result, smart contracts on Hemi can perform complex multi-chain workflows. For example, a smart contract could observe the confirmation of a specific transaction on Bitcoin and send a cross- chain call to a contract running on Ethereum. Or a smart contract on Ethereum could send a cross- chain message to trigger a smart contract on Hemi to perform a particular action based on Bitcoin state.
When designing cross-chain applications, the state challenge time for settlement of Hemi-to Ethereum cross-chain calls, along with the hVM’s natural delay in processing Bitcoin blocks must be considered. However, Hemi’s ability to observe and interact with both chains provides a powerful foundation for decentralised applications that demand secure and flexible cross-chain workflows.
Metaprotocol Support (Ordinals, BRC-20s, Runes, etc.)
As early as 2012, various developers have launched metaprotocols that live on top of the Bitcoin blockchain. These metaprotocols are unknown to the Bitcoin protocol itself, making them experimental for the protocol, but users can run additional metaprotocol-specific indexers that extract and process relevant information from Bitcoin transactions to track the metaprotocol’s state machine.
The architecture of the hVM makes it possible to introduce future protocol upgrades that add additional indexers (along with their own precompile endpoints) to the embedded Bitcoin full node. These upgrades provide smart contracts with additional information about protocols running on top of Bitcoin. By adding metaprotocol-specific indexers to the hVM, the Hemi network can provide smart contracts with a complete Bitcoin metaprotocol state as well. Support for Ordinals, BRC-20s, and Runes are also possible additions to Hemi’s roadmap for hVM functionality. When support for a specific metaprotocol is added to the hVM, a number of additional precompiles can be added that allow smart contracts to query the metaprotocol’s state.
Metaprotocol support will make it possible to develop smart contracts that interact with Bitcoin metaprotocols, including expanding the Hemi Bitcoin Tunnel system to support the tunnelling of metaprotocol assets.
Advantages of hVM for Bitcoin Interoperability and Programmability
Over the past decade, developers have introduced a variety of different mechanisms to introspect Bitcoin in a smart contract environment. The architecture of Bitcoin makes this particularly complex because Bitcoin maintains (the UTXO table) an actual state machine that isn’t cryptographically committed to in the Bitcoin blockchain. Therefore, proving/validating statements like “X output has not been spent” or “the balance of X address is Y” is impossible or extremely impractical with traditional approaches.
These approaches fall into three broad categories:
Bitcoin Header Relay: A smart contract tracks lightweight Bitcoin consensus using Bitcoin headers, which relayers communicate to the consensus-tracking smart contract. Other smart contracts that want to introspect Bitcoin have their users submit relevant Bitcoin transactions with Merkle proofs. These prove transactions are contained within a particular Bitcoin block by authenticating them, which is validated against the Merkle root contained in a Bitcoin block.
Bitcoin State Oracles: A trusted oracle system is used which tracks Bitcoin state and responds to queries by signing or otherwise endorsing the response as valid.
Succinct Arguments of Knowledge (SNARG): Users or specialised parties with access to extensive computing power construct SNARG (in practice, generally zk-SNARK) proofs of processing large amounts of data from Bitcoin to validate onchain a certain statement about Bitcoin is correct.
Download the full report here
Download the "Hemi: A Modular L2 Connecting the Bitcoin and Ethereum Ecosystems" report here (PDF)