Hemi Developer AMA Recap: What’s Next for Bitcoin Programmability and L3 Security
In this episode of MwM, the engineering team sat down to answer questions with the Hemi community.
This week, the Hemi protocol engineering team hosted a wide-ranging AMA covering everything from Bitcoin state access inside the HVM to future plans for L3 rollups and decentralized security. Co-founder Max Sanchez and developers Marco, JCV, Antonio, and Joshua joined the session to walk through the architectural decisions behind Hemi and what’s coming next.
Here’s a breakdown of the highlights.
Real-Time Bitcoin Data, with a Two-Block Delay
One of the core features of Hemi’s hVM (Hemi Virtual Machine) is its ability to query native Bitcoin state from within EVM-compatible smart contracts. To keep this deterministic and secure, hVM intentionally lags two Bitcoin blocks behind the tip. This avoids issues where someone could mine a block and selectively withhold it to confuse the state.
Hemi doesn’t support mempool queries for smart contracts, since Bitcoin mempool views are non-deterministic. However, the team built a custom embedded Bitcoin node—called TBC (Tiny Bitcoin Client)—to support efficient, deterministic state queries from smart contracts.
Why Ethereum Is Used for DA (Data Availability)
Hemi uses Ethereum for publishing data availability proofs instead of Bitcoin. This is largely about cost and throughput. Ethereum’s blob-based data system (EIP-4844) is designed for L2 scalability. Bitcoin, with its 4MB per 10-minute block limit and fee spikes, isn’t well suited to serve as a DA layer for high-throughput chains.
This choice also makes Hemi a better network citizen: publishing large amounts of L2 data to Bitcoin would crowd out other Bitcoin users. Instead, Hemi leverages Ethereum’s DA layer while anchoring security via Proof-of-Proof (PoP) to Bitcoin.
TBC: A Purpose-Built Bitcoin Node for the EVM
TBC is a streamlined Bitcoin full node embedded inside Hemi’s version of op-geth. It runs in two modes: one for tracking Bitcoin consensus headers, and another for full state indexing. This makes it possible for smart contracts to query Bitcoin UTXOs, validate transactions, and more—all from within the EVM.
The engineering team built TBC to be compact (about 14,000 lines of code) and efficient. It also inherits years of experience from prior work on BTCD, a well-known alternative Bitcoin client.
Smart Contract Interface: Precompiles, Not Opcodes
Accessing Bitcoin data from a smart contract is handled through EVM precompiles—lightweight native functions that live outside the EVM opcode space. These precompiles talk directly to TBC and return data like UTXOs, transaction proofs, and block metadata.
While developers can interact with these precompiles directly, most will use higher-level abstractions via BitcoinKit, Hemi’s SDK for building Bitcoin-aware contracts.
Handling Bitcoin Reorgs
hVM’s two-block delay protects against short Bitcoin reorgs. For longer reorgs, DApp developers are responsible for setting proper confirmation windows—typically 4–6 blocks—for any operation that relies on finality, like issuing loans or minting assets.
Using Bitcoin for Randomness
While Hemi is in talks with oracle providers to support verifiable randomness functions (VRF), developers can also use delayed Bitcoin block hashes as a secure entropy source for lottery or game applications. This works well if you design around the two-block delay and avoid letting users “peek ahead” at future entropy.
Simplifying Node Operation
A major refactor is underway—known as PR #396—that splits up the monolithic architecture of Hemi’s early daemons. The new layout will make nodes easier to run, monitor, and extend. Prometheus support is being added across services, and helper scripts are being bundled for local deployments.
Testnet is also moving to Bitcoin Testnet4, which solves issues caused by Testnet3’s erratic block times and massive reorgs.
UTXO Growth Isn’t a Concern
Compared to Ethereum’s state tree, Bitcoin’s UTXO set is small and grows slowly. TBC uses efficient indexing, and the team is rolling out improvements to UTXO unwinds and storage. In short, Hemi’s architecture isn’t bottlenecked by Bitcoin’s state size.
Light Clients and ZK Proofs Are Coming
Eventually, Hemi will support ZK-proven light clients, where full Bitcoin and Ethereum state can be verified by smart contracts using zero-knowledge proofs. This will allow external parties to trustlessly verify the output of the Hemi chain without needing to run a full node.
Chain Builder and L3 Rollups
The team previewed Chain Builder, a modular framework for launching custom L3s that inherit security from Hemi and, by extension, Bitcoin. Builders will be able to choose between enabling HVM, using HemiBTC via the tunnel, and configuring DA and sequencing preferences.
In the future, shared sequencing and shared DA for L3s will enable smoother interoperability and cheaper operation, while still allowing for flexibility in design.
Security and Audits
Hemi’s smart contracts are audited before any major upgrade, and the core codebase has undergone reviews by HackerOne. A more formalized release schedule and public changelogs are coming. For reporting issues, Hemi uses a private HackerOne program and a responsible disclosure process.
POP and SegWit
Currently, POP mining uses legacy Bitcoin address formats for simplicity and compatibility with Ethereum keys. The team plans to support SegWit and Tapscript in the future, but this requires additional cryptographic tooling and a new registration system for linking Bitcoin keys to EVM addresses.
What’s Next
- The release of the BitVM+ white paper
- Full migration to Testnet4
- Launch of ZK proving infrastructure
- A formal rollout of Chain Builder for L3 deployments
The AMA showed just how much depth and intentionality has gone into Hemi’s architecture. It’s not just a bridge—it’s a rethinking of how to make Bitcoin programmable, accessible, and secure for the next wave of developers.
Stay tuned for the next Engineering AMA. There’s a lot more to cover.
Hemi Dev Team