Overview

The BitcoinOS team is the first to have developed and posted a ZK-compressed proof on the Bitcoin network. Other proof verification efforts have been limited to the Signet or testnet deployments. Their work has resulted in the development of BitSNARK, a software library for ZK-compressed fraud proofs on the Bitcoin network. The project aims to provide a horizontal scaling solution, offering a one-stop shop for teams interested in developing a rollup on Bitcoin. This approach shares similarities with the horizontal tech stack scaling in other ecosystems like Cosmos and Optimism, particularly in its focus on simplified verification, bridging standards, and lightweight interoperability.

Sovryn, Bitocracy, and The Demand for Bitcoin 

To understand the BitcoinOS team, it is important to understand their background in creating applications for Bitcoin. Prior to BitcoinOS, some of the team was imperative to the development of Sovryn, a smart-contract based system for lending, borrowing, and trading within the Rootstock ecosystem. Rootstock is a BTC-focused sidechain that leverages merge mining consensus to bootstrap validators for itself. The protocol has also launched on the new Build on Bitcoin (BOB) Layer 2 in the Optimism Superchain ecosystem. It uses the SOV token, which can be staked to Sovryn for governance and revenue sharing from their lending app and its fee revenues. Sovryn was essentially the incubator for BitcoinOS, and now serves as one of the leading teams developing infrastructure in the sector. Other members of the team have been largely involved elsewhere in the Bitcoin ecosystem, contributing to the development of tBTC, BitLayer, LN, BabelFish, and more.

Bitcoin has seen increased demand following the launch of its ETFs, which shows its dominance as a well-understood asset in contrast to others like Ethereum or Solana. This growing interest in Bitcoin applications, coupled with the increasing complexity of its blockspace, aligns with the vision of the BitcoinOS team, whose background in building infrastructure places them at the forefront of this trend toward more active use of Bitcoin within DeFi and beyond.

While the timeline for Ethereum has been significantly shorter, the Ethereum ETFs have seen considerably less demand, which shows us that Ethereum is an unfamiliar asset for institutions. Bitcoin is a household name, and many investors are both familiar with and have a deep understanding of it, infinitely more than Ethereum, Solana, or any other general application blockchain. At the same time, Bitcoin’s blockspace has become more complex, showing that there may actually be demand for applications on Bitcoin. Currently, Bitcoin is about half of the entire crypto ecosystem ($1.2T) market cap, and the majority of this BTC is sitting idle.

Last year, the release of BitVM 1.0 whitepaper sparked new potential for transforming Bitcoin into a network that supports general applications and Layer 2 solutions. Thus, team members of BitcoinOS developed their own Bitcoin-enabled tech stack for rollups, which bear a stark contrast to prior models seen by the BitVM 1.0. These solutions could create the very first working Bitcoin rollup, by achieving a working trustless bridge contract on the L1.

Bottlenecks in Bitcoin Rollups 

Bitcoin L2s are still very much a work in progress. But in the past year since the release of the BitVM whitepaper, significant developments have occurred to push new lightweight cryptographic proof standards for performing computation on Bitcoin. The Bitcoin L2 genesis began with the BitVM 1.0, a virtual machine for fraud proof verification. This meant that smart contracts could be a possibility on Bitcoin, but more importantly, a bridge contract between Bitcoin and an L2 could be established. The high data costs and limited throughput on the L1 make it less prospective to perform computation there, and thus the bridge contract is essentially the holy grail for Bitcoin L2s. However, BitVM was restricted to a two-party permissioned model, requiring the prover and verifier to be predetermined before execution. Multi-party smart contracts introduce a layer of complexity that has been fundamental for the development of ecosystems like Solana and Ethereum. Additionally, the first version of BitVM also had the caveat that it was outlined to have only used certain Bitcoin opcodes, which increased its onchain computation cost and narrowed its scope for use. Ultimately, BitVM 1 was never implemented in any way beyond conceptualization within its whitepaper.

Though it came after the release of the BitSNARK whitepaper, BitVM 2 emerged as the next conceptual iteration, introducing a new standard with additional features. It potentially allows for permissionless verification in a multiparty setting, but still requires significant optimizations to be functional for general usage. Though like BitVM 1, BitVM 2 has not moved beyond conceptualization.

BitVM 2.0 compresses a program into a SNARK verifier using Bitcoin script. Then, it breaks the verifier into smaller chunks under the maximum size of a block (4MB). Some operator then commits to the program, and if the operator attempts to withdraw funds, anyone can challenge them. Once challenged, the operator goes through the steps of a traditional fraud proof game where they must show all steps of their program.

The number of parts the SNARK verifier is broken into depends on the size of the specific verifier program used. Each part requires a signed intermediary step, and with a Lamport signature requiring 4KB per intermediate step, the total size of the subprogram would be substantial. In early BitVM 2 developments, a script would be broken into 1000 parts, and each part required an intermediate Lamport signature. Due to the signature size and the signatures required per midstate, the blockspace requirement for BitVM2 if implemented in its original form would have been 8MB minimum.

While neither BitVM1 or 2 have ever been implemented on mainnet, both require large transactions. The problem with this is that the Bitcoin blockspace is notoriously limited at 4MB. Thus, fitting large transactions into blocks may be hard, and could also make these transactions susceptible to some spam attacks. For example, someone could prevent proof verification with the BitVM 1.0 or 2.0 by simply spamming the blockchain, pushing back the window of verification. In fact, current BitVM2 implementations take 3 transactions, each taking large amounts of block’s space. The three transactions are: challenge, assertions, and disprove, each representing stances in the fraud proof game. BitVM 2.0 is still a work-in-progress, and drafters for the original BitVM 2.0 paper say that it still requires optimizations to formalize security proofs, improve the light client, and reduce onchain costs.

BitSNARK is the first realization of the research released with BitVM1 and 2. While other proof verification standards remain in testing or theoretical, BitSNARK stands out by accomplishing a mainnet implementation.

BitSNARK is a software library built by the BitcoinOS team for zkSNARK verification on the Bitcoin L1. Similar to BitVM 2.0, the BitSNARK uses a SNARK for proof compression in the dispute game. More importantly, BitSNARK minimizes complexity. The BitSNARK virtual machine has a simplified processor with three instructions for lightweight verification. While it uses SNARKs, it should not be confused for traditional ZK rollups as seen on Ethereum. Zero-knowledge technology here is strictly used for the compression of the fault proof interactive game within. During the Bitcoin Nashville conference, the BitcoinOS team showed the first successful dispute resolution onchain with the BitSNARK. This dispute was successfully executed after 52 transactions (though since then they have achieved optimizations that can cut this by more than 50%). In the open-source version of the BitSNARK, it takes 19 rounds of bisections to conclude the dispute in the best case scenario.

Like BitVM 1 and 2, the BitSNARK is a multi-party dispute system, which sets up prover and verifier entities. This dispute game is very similar to the traditional fraud proofs seen on ORUs in the Ethereum ecosystem. The prover initiates the game by providing the result of some computation, and the verifier can challenge the prover’s claim if fraud is suspected. This can be broken down:

1. Commitment Phase: The BitSNARK prover(s) reveal an input (proving the data was processed) and the result of computation (to prove there is a final result).
2. Challenge Phase: The verifier can select some part of the computation that they believe is incorrect and then challenge it.
3. Execution Reveal Phase: The prover will assert that it performed execution correctly.
4. Verification Phase: The process continues until the verifier can pinpoint exactly where error has occurred.
5. Resolution Phase: If the verifier proves that the prover has faulted, then the funds involved remain locked, and the verifier is rewarded. If the verifier fails to prove the claim, funds are unlocked, and the prover receives some reimbursement for its job.

There is an additional component here, where both parties are economically pushed to act honestly. Similar to all other schemes, the prover deposits a stake which is forfeited in case of fault, and the verifier needs to put up some assertion bond to start challenging. What gives the BitSNARK an advantage over the BitVM is that it has succinct complexity. The BitVM models have linear dependencies, and thus their onchain data costs scale linearly.

The natural conclusion to such a system is a Bitcoin L2. While one could theoretically use the BitSNARK for fraud proof verification of general applications on Bitcoin, this does not make sense in the majority of cases due to the onchain overhead costs for the applications. However, select use cases for privacy may be reasonable. It is more sensible to make a native bitcoin bridge to some other execution environment instead.

Thus, the BitcoinOS team aims to build the “Grail Bridge”. This bridge would use BitSNARK operators that monitor bridge activity and aid in withdrawals and deposits. These operators would ensure that user BTC is bridged from L1 to beyond. For this bridge system to work, operators would lock their funds in addresses to enter the dispute game, and these funds would stay within Taproot addresses until the SNARK proof of the game is provided. The L2 provides a SNARK proof to the bridge contract, allowing the bridge to mint the tokens back into the operator’s account. There are two proofs used in the Grail Bridge, a proof for transaction inclusion, and a proof for state transition on the L2. The inclusion proof is evidence that a transaction was included in a specific block, blocks were confirmed thereafter, and that the accepted block of that proof exists on the network.

Current bridges in Bitcoin have too many uncertainties. WBTC has fallen into scrutiny from its centralization and potential collaboration with Justin Sun & TRON which led to its delisting from large protocols like MakerDAO. Other forms of BTC like iBTC (Interchain BTC) are limited by low volume and considerable fragmentation despite better decentralization methods. tBTC has lower liquidity risk but relies on two additional assets, KEEP and ETH, while also operating with a closed set of validators, which introduces a trust assumption. BitVM-enabled bridges are not out of the spotlight either — bridges must rely on operator reimbursement. The operator is responsible for reimbursing users on both sides of the bridge, so if a user deposits $10 then the operator must be able to provide $10 on the other side. This is somewhat unstable because the operator’s liquidity requirement will increase linearly with the TVL of the bridge. Of course, this can be fixed with optimizations in design and operational costs.

BitSNARK’s Distinct Advantage 

There are competitors in the race for proof verification on Bitcoin. Notably, the BitVM 2.0 has received numerous optimizations and is developed by the Build on Bitcoin team with other contributions from teams like TMUL from Alpen Labs. Alpen’s recent TMUL optimization provides a script size reduction by 47%. This is a major improvement as one of the biggest obstacles was the BitVM 2.0 being unable to consistently fit its transactions into blocks. Other teams, like Rootstock Labs are developing solutions like the BitVMX, which is more generalized and flexible as it aims to be able to accomplish universal computation on Bitcoin mainnet, rollups, applications, anything. Though BitVMX is not intended to be used for the development of rollups, rather optimizations to the HSM-federated peg system that Rootstock currently uses for its merge-mining consensus. **What sets the BitSNARK apart is that it is real and has been executed onchain and has optimizations with this in mind. **

Overall, the BitSNARK aims to be as lightweight as possible for easy operations. BitSNARK moves beyond the theoretical implementations seen with BitVM 1.0 and 2.0 with achieving proof verification on Bitcoin mainnet. Moreover, BitSNARK optimizes cost for its proof verification by managing transaction placement in blockspace. In BitVM2, transactions between the prover and verifier would require one full block each. With BitSNARK, transactions are reorganized and optimized so that blockspace is optimally structured. This allows transactions to be distributed across multiple blocks, without needing to buy entire blocks. As a result, the cost per byte is lower for BitSNARK than theoretical implementations. Other systems like BitVM2 have increased DDOS vulnerabilities because of their dependency on blockspace. For example:

• 5% Attacks: Dishonest actors can buy up block space and prevent honest challengers from accessing a whole block. The prover would need to wait for the challenge process to timeout and could steal funds.
• Parallel Challenge Vulnerability: This vulnerability is derived from BitVM 2’s need to post proofs sequentially, whereas BitSNARK can handle multiple parallel challenges. Because of this vulnerability, there exists a problem where BitVM can be flooded with fake challenges to timeout an existing challenge within, breaking the dispute system.

The BOS Stack?

The Grail Bridge is the first of many products to be developed under the BitcoinOS Stack. The BOS Stack consists of a proof verification system (BitSNARK), the Grail Bridge, and Merkle Mesh. BitSNARK enables rollup-specific computation to be achieved on Bitcoin. The Grail Bridge is designed to create a functioning bridge system for rollup ecosystems. Merkle Mesh is the last piece, to bring interoperability to the Bitcoin rollup ecosystem. While it is still currently in development, the Merkle Mesh system can be thought of as something similar to Polygon’s AggLayer, a shared bridge contract system that leverages ZK proofs for all chains. This would position all ZK-enabled BitcoinOS rollups to achieve interoperability with each other; of course, this is contingent on a transition to the more traditional idea of a ZK proof, rather than BitSNARK’s ZK compression. BitSNARK uses ZK compressed fraud proofs; if the network does seek to transition to aggregated ZK proofs, it will need rollups to aggregate actual ZK proofs from all chains within its ecosystem.

Regardless, if BitcoinOS is to position itself as a horizontal scaling solution for Bitcoin rollups then it may try similar strategies as other ecosystems.

BTC L2 Alignment vs. Business Management 

The development of Bitcoin rollups is accelerating. While the conversation is moving toward having an “aligned” Bitcoin rollup stack (execution offchain on an L2, and everything else on the L1) it is highly unlikely that this approach remains the case. Bitcoin blockspace is notoriously expensive, so Bitcoin as a DA layer is unlikely to take hold. Bitcoin’s block sizes are limited to 4MB currently, making it much more scarce compared to Ethereum’s dynamically sized blocks that scale with demand. ZK proofs in particular have data availability concerns in the Ethereum ecosystem due to the current average proof size. This means that the aligned idea of Bitcoin L2s is significantly more difficult to execute, as onchain costs and storage capabilities would push most functions offchain.

Because of how limited BTC blockspace is, it is essential for Bitcoin rollups to use a DA layer. Without a DA provider, proof costs for a rollup would be extremely high, if the initial challenge transaction is $120-$200 per proof, and posted every 6 blocks in an 144 block day, then the cost to post these proofs would annualize to $1,051,200 (without accounting for market variability). To that end, BitcoinOS has partnered with NuBit, a Bitcoin-specific DA layer. This partnership should decrease the data availability burden substantially, allowing for Bitcoin rollups to be achieved with a much smaller operational expense. In its testnet implementation, Nubit currently achieves about 1.8 mb/s, very similar to Celestia’s 1.88 mb/s.

The Bitcoin rollup ecosystem may find an easier time bootstrapping the required security for these layers as Bitcoin mining nodes will look for other opportunities as mining rewards dry up. Merged mining, a consensus mechanism where miners validate both Bitcoin and an off-chain layer, offers a potential incentive structure to sustain the L1 network despite a shrinking security budget. Bitcoin will likely be used as a settlement layer only, with offchain DA and execution provided by other parties like BitcoinOS and NuBit.

There is no EIP-1559 to introduce variable block sizes to scale with demand, the blockspace is hard capped at 4MB (mostly). Bitcoin rollups may find some need to explore partnerships with mining pools for optimized management and guaranteed block inclusion. Marathon Digital’s slipstream product (transaction inclusion beyond the block limit) is just one possible foray into the future for Bitcoin rollups, if they see sizable traction. Ultimately though, this means that Bitcoin rollups are in a much more constrained environment than Ethereum rollups, in that there are existing constraints on the L1 that drive activity elsewhere.

The majority of credible Bitcoin L2s remain in development, with very few finding methods to launch to mainnet early. Almost all early approaches have launched as a standalone EVM with no bridge to Bitcoin (BOB, Corn, etc). Projects that will launch on Bitcoin the fastest are those that compromise on alignment. In other words, how much interaction is required between Bitcoin L1 and the rollup. BOB and Hemi’s approaches are reasonable because they leverage the Ethereum community and existing tooling with the aim to eventually launch on Bitcoin. OP_NET is another scalable execution solution that exists as a metaprotocol, where native mechanisms work directly within Bitcoin rather than a proof of execution being posted to the network with rollups. OP_NET is currently in testnet, with several applications in the pipeline already. These protocols are best positioned to achieve market share as their go-to-market strategy is focused on bringing a product to users as soon as possible and maintaining that experience.

The competitive landscape is expansive and most projects have already launched some product to begin to bootstrap a community (Sovryn, Rootstock, and BOB) or are deep in development (Citrea, Alpen Labs, and Starknet).

There is still a question of whether a separate execution layer is needed for Bitcoin. The most profitable lightweight business from the Bitcoin L2 mania could simply be a new bridge to Solana, Ethereum, or some other expressive execution layer that already exists and has the marketing, community, and tooling, though this would tie the expressivity of Bitcoin to the health of Solana and Ethereum.

Conclusion

Ultimately, Bitcoin L2s have potential to see outsized demand given the recent ETF activity, which suggests that Bitcoin’s reputation and standing is more well-regarded than Ethereum and others.

BitcoinOS becomes a versatile tech stack for cost-effective development of Bitcoin L2s, as most other structures for general computation on Bitcoin rely on trust assumptions or have extremely high onchain costs. BitcoinOS has already forged partnerships with two major players, Nubit (DA layer for Bitcoin L2s), and Merlin, a stage 0 L2 that gained the majority of the Bitcoin L2 mindshare early this year. BitcoinOS genuinely could position itself to be the default layer for all Bitcoin L2s and make general computation for any VM accessible to Bitcoin. There is an obvious customer base for BitcoinOS; however, the question remains on whether BitcoinOS can optimally monetize its stack, capture, and sustain its customer base, all the while answering the illusive question of whether there is consistent demand for general computation on Bitcoin.