Research/Bitcoin

Drivechains (BIP-300): The Controversial Proposal to Give Bitcoin Unlimited Sidechains

How BIP-300 drivechains would enable permissionless Bitcoin sidechains, the miner-enforced peg, and why the proposal is controversial.

bcSatoruJun 10, 2026

What if Bitcoin could absorb every feature from every altcoin: privacy from Zcash, smart contracts from Ethereum, prediction markets, large-block payments? That is the promise of BIP-300, a proposal called "Hashrate Escrow" that would allow anyone to launch a sidechain on Bitcoin, secured by miners rather than a federation or a set of operators. Together with BIP-301 (Blind Merged Mining), the two proposals form the drivechain framework: permissionless sidechains pegged to Bitcoin through miner voting.

The concept, introduced by Paul Sztorc in 2015 and formalized as a BIP in 2017, has generated more debate than almost any other Bitcoin scaling proposal. Its proponents call it Bitcoin's best chance at absorbing altcoin innovation. Its opponents call it a fundamental threat to miner decentralization. Neither side has backed down, and the proposal remains unactivated years later.

What Problem Do Drivechains Solve?

Bitcoin's base layer is intentionally conservative. Soft forks take years to deploy and require broad community consensus. Features like advanced privacy, expressive smart contracts, or high-throughput payments cannot be added to Bitcoin L1 without compromising its core properties: simplicity, decentralization, and security.

Sidechains offer an alternative: separate blockchains pegged to Bitcoin so that BTC can move between the mainchain and the sidechain. Each sidechain can have its own rules, block sizes, and features. The fundamental challenge is the peg: how do you move BTC into and out of a sidechain without trusting a centralized entity?

Liquid solves this with a federation of functionaries controlling a multisig wallet. Drivechains propose a different answer: let miners enforce the peg using their hashrate as collateral.

How BIP-300 Works: Hashrate Escrow

BIP-300 redefines one unused opcode (OP_NOP5) as OP_DRIVECHAIN and introduces two new data structures tracked by every full node:

  • D1 (The Sidechain List): tracks up to 256 possible sidechain slots, each with metadata, activation status, and a pointer to the sidechain's locked UTXO on the mainchain
  • D2 (The Withdrawal List): tracks pending withdrawal bundles for each sidechain, including their vote count and remaining voting period

Communication between the mainchain and sidechains happens through six message types embedded in coinbase transactions and regular transactions:

MessagePurposeLocation
M1Propose a new sidechainCoinbase
M2ACK (vote for) a sidechain proposalCoinbase
M3Propose a withdrawal bundleCoinbase
M4ACK or NACK withdrawal bundlesCoinbase
M5Deposit BTC into a sidechainRegular transaction
M6Withdraw BTC from a sidechainRegular transaction

Each sidechain's locked BTC is held in a single Container UTXO (CTIP). Deposits increase the CTIP balance; withdrawals decrease it. This means months of sidechain activity compress into a single UTXO on the mainchain.

Deposits: Moving BTC In

Depositing is straightforward. A user creates a mainchain transaction (M5) that spends the sidechain's existing CTIP and creates a new CTIP with a higher balance. The difference is credited to the user on the sidechain. This requires no miner voting: it is a standard Bitcoin transaction with a special output script.

Withdrawals: The 6-Month Gauntlet

Withdrawals are where drivechains get controversial. Individual withdrawal requests on the sidechain are periodically combined into a single bundle (similar to a CoinJoin). A miner proposes this bundle's hash via an M3 message. Then the voting begins.

Over the next 26,300 blocks (approximately six months), miners vote on whether to approve the bundle. Each block, every sidechain's bundles are either ACKed (upvoted), NACKed (explicitly downvoted), or abstained. The critical rule: a bundle that receives no vote in a given block automatically loses one ACK. A bundle needs 13,150 ACKs to pass. If it cannot possibly reach that threshold given its remaining blocks, it is discarded immediately.

Why six months? The extended withdrawal period is a security mechanism. If miners attempted to steal funds by approving a fraudulent withdrawal bundle, the community would have roughly six months to notice, raise alarms, and coordinate a response: potentially including a user-activated soft fork to block the theft.

BIP-301: Blind Merged Mining

BIP-300 defines the peg mechanism, but sidechains also need block production. BIP-301 introduces Blind Merged Mining (BMM), a scheme that lets Bitcoin miners commit to sidechain blocks without running sidechain node software.

The system involves two participants. "Simon" (the sidechain node operator) assembles a sidechain block and creates a BMM Request transaction on the mainchain, paying a fee to whichever miner includes his block hash. "Mary" (the Bitcoin miner) includes a BMM Accept message in her coinbase, endorsing Simon's sidechain block and collecting the fee. Mary never needs to validate the sidechain block contents: she is "blind" to sidechain state.

This creates a fee market for sidechain block production. If a sidechain generates $2,000 in transaction fees, Simon might pay $1,999 to Mary and keep $1 as profit. Multiple Simons compete, and the miner picks the highest bidder.

The Criticism of BMM

Peter Todd, a Bitcoin Core contributor who was hired by LayerTwo Labs (Sztorc's company) to review the proposals, published a detailed critique. He identified an equivocation attack where miners could include conflicting OP_RETURN transactions at the same block height. He also noted that the prevMainBlock field in BMM Requests means mainchain reorgs would invalidate sidechain transactions, and that BIP-301 lacks any mechanism to compensate miners for the work of approving BIP-300 withdrawals.

The Sidechain Vision

LayerTwo Labs, the company Sztorc co-founded with developer CryptAxe, has been building seven reference sidechains to demonstrate what the drivechain framework could enable:

SidechainPurposeComparable To
zSideShielded transactions (privacy)Zcash
EthSideEVM smart contractsEthereum
Truthcoin / HiveMindPrediction markets with oracle resolutionPolymarket / Augur
ThunderLarge-block payments (50-250 MB blocks)Bitcoin Cash
CoinShiftTrustless L2-to-L1 swapsDecentralized exchange
BitAssetsTokens, NFTs, corporate sharesEthereum ERC-20 / ERC-721
PhotonQuantum-resistant transactionsPost-quantum cryptography

The thesis is that every feature driving value to altcoins could exist as a Bitcoin sidechain instead, secured by Bitcoin's hashrate and denominated in BTC. Sztorc's Truthcoin (a decentralized prediction market oracle system) actually predates the drivechain concept itself and was one of the motivating use cases.

The Case for Drivechains

Proponents make several arguments for why BIP-300 should be activated:

  • Permissionless innovation: anyone can launch a sidechain without permission from Bitcoin Core developers or a federation
  • Miner revenue: sidechain fees flow to Bitcoin miners via merged mining, supplementing declining block subsidies
  • Altcoin absorption: if Bitcoin can host every use case, the incentive to create or hold altcoins diminishes
  • Minimal base-layer changes: BIP-300 repurposes a single unused opcode and adds coinbase message parsing; proponents argue it is a modest consensus change
  • Reversibility: since the change uses a soft fork, it could theoretically be reversed by a subsequent soft fork if problems emerge

Sztorc has argued that Bitcoin L2s that do not pay fees to miners (including Lightning) threaten the long-term security budget, and that drivechains are the only scaling approach that aligns incentives by routing sidechain revenue back to miners.

The Case Against: Why Critics Say No

The opposition to drivechains is equally vocal, drawing criticism from developers, investors, and Bitcoin maximalists alike.

Miner Centralization

Peter Todd's core objection: miners effectively become custodians of sidechain funds. Unlike regular Bitcoin transactions, where no amount of hashrate can forge a digital signature, drivechains explicitly grant miners the power to approve or deny withdrawals. A coalition controlling 51% of hashrate could approve a fraudulent withdrawal and steal every sidechain's BTC.

Todd further argued that with dozens or hundreds of potential sidechains, miners would face pressure to run each sidechain's full node to validate withdrawal bundles. This creates an economy of scale favoring large, well-resourced mining pools and undermines decentralization efforts like Stratum V2 and p2pool. In his words: "Drivechains replaces the careful incentive design we see in other Bitcoin protocols with blind trust in miners."

MEV and Fee Market Distortion

If sidechains host DeFi applications, EVM smart contracts, or token exchanges, the same Miner Extractable Value problems that plague Ethereum could arrive on Bitcoin. Miners would have financial incentives to reorder, frontrun, or censor sidechain transactions, introducing complexity that Bitcoin's current fee market avoids.

The Capital Lock-Up Problem

The six-month withdrawal period means BTC locked in sidechains is effectively illiquid for half a year. This creates capital requirements that favor large, well-funded entities and could give rise to "withdrawal intermediaries" who front liquidity for a fee: reintroducing the trusted third parties Bitcoin was designed to eliminate.

Todd raised the question: does the ability to approve or deny withdrawals make miners custodians under financial regulation? If so, mining pools could face lawsuits, court orders, and compliance requirements. As he noted: "Does this make miners custodians? Maybe! It certainly invites lawsuits."

The social layer argument: Drivechain proponents counter that the six-month withdrawal window gives the community time to respond to theft via a UASF (User-Activated Soft Fork). Critics respond that relying on social coordination for security is a step backward from Bitcoin's cryptographic guarantees: the whole point of Bitcoin is that you do not need to trust human coordination.

Comparing Sidechain Approaches

Drivechains are one of several approaches to Bitcoin sidechains and Layer 2 scaling. Each makes different tradeoffs between trust, speed, and capability.

PropertyDrivechain (BIP-300)LiquidBitVM RollupsSpark
Trust model51% hashrate honesty11-of-15 federation1-of-n honest verifier1-of-n honest operator
Requires soft forkYes (BIP-300/301)NoNoNo
Withdrawal time~6 months~2 hoursChallenge period (days)Instant (unilateral exit)
Permissionless launchYesNo (federation required)YesNo (operator set required)
Miner revenueYes (merged mining)NoMinimalNo
Smart contract supportPer-sidechain rulesLimited scriptingArbitrary computationToken issuance, DeFi
StatusDraft BIP, not activatedLive since 2018Early mainnet deploymentsLive since 2025

The trust model differences are significant. Lightning Network achieves fully trustless payments through HTLCs and payment channels. BitVM rollups require only one honest verifier to catch fraud. Spark requires one honest operator during each transfer, with perfect forward security after key deletion. Drivechains require that a majority of hashrate remains honest for the entire six-month withdrawal period: a fundamentally different security assumption.

Current Status: Draft, Stalled, and Forked

BIP-300 remains in Draft status. It has not been activated on Bitcoin mainnet and lacks the broad community consensus required for a soft fork.

The Bitcoin Core PR

In August 2023, Luke Dashjr (a longtime Bitcoin Core developer) wrote a clean reimplementation of BIP-300 consensus code and submitted PR #28311 to the Bitcoin Core repository. Dashjr described himself as "neutral" on the concept, but simultaneously warned: "With the current state of mining centralisation, it would be pretty dumb to send any bitcoins to a drivechain." The PR was closed by a maintainer in March 2024 after discussion "turned non-technical."

CUSF: Bypassing Bitcoin Core

Frustrated by the inability to merge BIP-300 into Bitcoin Core, LayerTwo Labs developed the Core Untouched Soft Fork (CUSF): a separate "enforcer" binary that miners can run alongside Bitcoin Core. The bip300301_enforcer validates BIP-300 and BIP-301 rules independently. The idea: if more than 51% of hashrate runs the enforcer, drivechains activate without any change to Bitcoin Core itself.

This approach is itself controversial. It circumvents Bitcoin's traditional peer review and activation process, and it means a hashrate majority could impose new consensus rules over the objections of node operators, users, and developers.

The eCash Hard Fork

In early 2026, Sztorc announced a hard fork of Bitcoin called "eCash", scheduled for block height 964,000 (approximately August 2026). The forked chain would include BIP-300/301 natively and offer a 1:1 airdrop to existing BTC holders. The announcement was met with further controversy when it emerged that certain dormant coins would be reassigned to early investors and developers: a move widely criticized as contrary to Bitcoin's property-rights ethos. LayerTwo Labs completed a $4 million angel funding round in December 2025.

The Activation Challenge

Drivechains face a fundamental governance problem. Bitcoin's consensus changes require rough community agreement across developers, node operators, miners, and users. No formal threshold exists, but the precedent set by SegWit and Taproot suggests that contentious changes are extremely difficult to push through.

The drivechain debate has fractured along unusual lines. Some Bitcoin maximalists support it as the path to absorbing altcoin features. Others (including prominent maximalists like hodlonaut and Saifedean Ammous) oppose it, arguing it introduces "grift, complexity, risk, and shitcoin-like functionality." Pierre Rochard, VP of Research at Riot Platforms, called the economic arguments "speculative" rather than grounded in solid engineering. Cashu developer Calle argued that BIP-300 grants miners excessive authority and has been "broadly dismissed."

The CUSF approach and the eCash hard fork represent Sztorc's attempts to route around this impasse. Whether either succeeds depends on whether miners and users see enough value in drivechain functionality to adopt alternative activation paths.

Where Drivechains Fit in the Scaling Landscape

Drivechains represent the maximalist vision for Bitcoin sidechains: unlimited permissionless chains, all merged-mined by Bitcoin's hashrate, all denominated in BTC. It is the "Bitcoin absorbs everything" thesis taken to its logical conclusion.

But the Bitcoin ecosystem has not stood still while waiting for BIP-300. Other approaches have shipped working products with different tradeoff profiles. Liquid provides federated sidechains with fast withdrawals and confidential transactions. Lightning handles payments without trusted intermediaries. BitVM-based rollups offer trust-minimized computation. Spark uses statechains and FROST threshold signatures to deliver instant, self-custodial Bitcoin and stablecoin transfers without channels, without merged mining, and without a soft fork.

The philosophical difference is instructive. Drivechains tie sidechain security to miner incentives, betting that economic self-interest will keep miners honest. Spark ties security to operator honesty with a 1-of-n threshold: only one operator needs to behave correctly, and users retain unilateral exit at all times. Neither approach is trustless in the way that Bitcoin L1 is, but they make very different bets about where to place trust.

For a broader comparison of these approaches, see the Bitcoin Layer 2 scaling landscape overview. And for a deeper look at covenants, which overlap with drivechain proposals in their ambition to extend Bitcoin's programmability, see our covenant explainer.

What Developers Should Know

If you are building on Bitcoin today, drivechains are a design space to understand rather than a tool to deploy. BIP-300 is not activated, and the path to activation is unclear. The CUSF approach remains experimental, and the eCash fork is a separate chain entirely.

For developers looking to build Bitcoin applications that work today, Spark's developer documentation covers integration with a live Layer 2 that supports Bitcoin, stablecoins, and token transfers. The wallet SDK comparison can help you evaluate your options, and the scaling landscape overview provides additional context on where each approach fits.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.