Services Products Clients Blog Contact
Back to blog
March 2026 Technical

Understanding BIP300 & BIP301: Bitcoin Sidechains Without New Tokens

A practical walkthrough of Drivechain — how Hashrate Escrows and Blind Merged Mining work, why they matter for Bitcoin's future, and what we've learned building in this space.

The problem Drivechain solves

Bitcoin is conservative by design. Changes to the protocol are slow, deliberate, and heavily scrutinized. This is a feature, not a bug — it's what gives Bitcoin its reliability as a monetary system.

But this conservatism creates a tension. People want to experiment. They want smart contracts, privacy features, faster transactions, different consensus mechanisms. And because Bitcoin's base layer moves slowly, these experiments tend to happen on entirely separate networks — altcoins — each with its own token, its own security model, and its own fragmented ecosystem.

Drivechain proposes a different path: let people build whatever they want on sidechains that are pegged to Bitcoin itself. No new tokens. No competing monetary systems. Just parallel chains where BTC moves freely in and out, and where the security is provided by Bitcoin's existing hashrate.

The proposal is split into two Bitcoin Improvement Proposals: BIP300 (Hashrate Escrows) and BIP301 (Blind Merged Mining). Together, they form the complete Drivechain specification.

BIP300: Hashrate Escrows

BIP300 is the peg mechanism. It's what allows BTC to move between the Bitcoin mainchain and a sidechain.

How deposits work

Depositing into a sidechain is straightforward. A user creates a transaction on the Bitcoin mainchain that locks their BTC in a special output — essentially sending coins to an address controlled by the sidechain's escrow. An equivalent amount of BTC becomes available on the sidechain. This is fast and requires no special permissions.

How withdrawals work

Withdrawals are where the design gets interesting — and where BIP300 diverges most from previous sidechain proposals.

In traditional federated sidechains (like Liquid), a group of known entities — typically 15 parties — jointly sign withdrawal transactions. You trust those 15 parties to be honest. If enough of them collude or are compromised, funds can be stolen.

BIP300 replaces this with a hashrate escrow. Instead of being signed by a fixed set of keys, withdrawal transactions are effectively "signed" by the collective hashpower of Bitcoin miners, over time.

Here's the process:

  1. A withdrawal bundle is proposed. Someone on the sidechain proposes a set of withdrawals — a bundle of transaction outputs that would pay BTC back to mainchain addresses. The hash of this bundle is included in a miner's coinbase transaction.
  2. Miners vote over a long period. Each block, miners can vote to approve or reject the proposed bundle. This isn't a quick process — the voting period lasts approximately 3 to 6 months (around 13,150 to 26,300 blocks).
  3. The bundle passes or fails. If enough miners vote in favor, the withdrawal executes on the mainchain. If not, it fails and no BTC moves.

The key insight is that this is slow and transparent. Everyone can see a withdrawal being proposed. Everyone can see how miners are voting. If a dishonest withdrawal is proposed — one that doesn't match what the sidechain's rules dictate — the community has months to notice and respond.

Why 3-6 months?

The long withdrawal period is a deliberate security trade-off. It makes theft extremely expensive. A miner (or coalition of miners) would need to sustain a majority hashrate commitment for months, publicly, while the entire community watches. The economic cost and reputational damage make this impractical in practice, even though it's theoretically possible.

What BIP300 specifies

At a protocol level, BIP300 defines five operations:

  • Proposing a new sidechain
  • Activating a new sidechain
  • Proposing a withdrawal bundle
  • Voting on a withdrawal bundle (approve, reject, or abstain)
  • Validating the actual withdrawal transaction

Mainchain nodes only need to enforce these simple rules. They don't need to understand or validate anything about the sidechain itself. The sidechain's internal rules — its consensus, its features, its smart contracts — are entirely separate concerns.

BIP301: Blind Merged Mining

If BIP300 handles the peg, BIP301 handles block production. It answers the question: who creates blocks on the sidechain, and how?

The basic idea

In traditional merged mining (like Namecoin with Bitcoin), miners run both the mainchain and sidechain software. They validate both chains. This works, but it creates a burden — miners need to run and maintain additional node software for every sidechain they want to support.

Blind Merged Mining removes this requirement. Bitcoin miners can mine sidechain blocks without running the sidechain software at all. They're "blind" to the contents of the sidechain blocks they're helping to produce.

How it works

BIP301 uses a two-message protocol:

  1. The request (from sidechain block creators). Someone who is running the sidechain node software constructs a sidechain block and creates a special Bitcoin transaction. This transaction includes the hash of the proposed sidechain block, the sidechain's ID, and a reference to the previous mainchain block. Crucially, this person doesn't need to be a miner — they're just proposing a block.
  2. The accept (from miners). A Bitcoin miner includes a reference to this request in their coinbase transaction. By doing so, they're committing to the proposed sidechain block without needing to know what's in it. In exchange, they collect a fee from the block creator.

The result is a marketplace. Sidechain operators pay Bitcoin miners to include their block commitments. Miners earn extra fees without running additional software. The sidechain gets the security of Bitcoin's hashrate.

Why "blind"?

The miner never sees the contents of the sidechain block. They only see a hash and a fee. This is the core innovation: it decouples block production (which requires hashpower) from block validation (which requires running the sidechain). Miners provide security; sidechain operators provide the content.

Why this matters

Drivechain, if activated, would change Bitcoin's relationship with innovation in several important ways:

No new tokens

Every Drivechain sidechain uses BTC. There's no new coin, no ICO, no token sale. When you deposit BTC into a sidechain, you get BTC on that sidechain. When you withdraw, you get BTC back. This preserves Bitcoin's monetary properties and avoids the fragmentation that alt-L1s create.

Experimentation without risk to the base layer

Want a sidechain with Turing-complete smart contracts? Build one. Want a privacy-focused chain? Build one. Want one that processes thousands of transactions per second with a different consensus mechanism? Build one. None of these experiments require changing a single line of Bitcoin's base layer code beyond the initial BIP300/301 activation.

Miner revenue

Every sidechain transaction generates fees. Those fees ultimately flow to Bitcoin miners through the blind merged mining market. More sidechains means more fee revenue, which strengthens Bitcoin's security budget — an increasingly important consideration as the block subsidy continues to halve.

Mainchain simplicity

Bitcoin nodes only need to validate BIP300 and BIP301 rules. The sidechain logic is entirely separate. You can safely ignore any sidechain you don't use. This is a clean separation of concerns that keeps Bitcoin's base layer simple while allowing arbitrary complexity on sidechains.

The trade-offs

No design is without trade-offs, and it's worth being honest about Drivechain's:

  • Withdrawal speed. 3-6 months is a long time to wait for a withdrawal. This is the cost of the security model. For large-value transfers, it may be acceptable. For everyday use, users would likely stay on the sidechain or use secondary markets.
  • Miner trust. BIP300 gives miners unilateral control over sidechain funds, in the sense that a sustained majority could theoretically approve a dishonest withdrawal. The argument is that the economic incentives make this irrational, but it is a different trust model than cryptographic signatures.
  • Activation. Like any Bitcoin soft fork, BIP300/301 needs miner adoption. The proposal specifies that deployment occurs when more than 51% of hashrate runs the enforcing client. This is a social and political challenge as much as a technical one.

What we've learned building here

At Santacroce, we've been working in the Drivechain ecosystem through our collaboration with Layer Two Labs. This has given us a front-row seat to both the technical challenges and the potential.

A few things we've observed:

  • The protocol is simpler than it sounds. When you read the BIP specifications, the actual mainchain changes are quite minimal. Most of the complexity lives on the sidechain side, which is by design.
  • The tooling is still early. This is infrastructure-level work. The developer experience is improving but still requires significant expertise. That's part of why we're writing about it — to make these concepts more accessible.
  • The community debate is healthy. There are genuine disagreements about Drivechain's security model. We think that's a good thing. Bitcoin should be cautious about protocol changes, and robust debate is part of that process.

Whether Drivechain activates or not, the ideas it introduces — hashrate escrows, blind merged mining, sidechain experimentation without monetary fragmentation — have already influenced how people think about Bitcoin's future. We're glad to be part of that conversation.


Further reading

BIP300 specification: bips.dev/300

BIP301 specification: bips.dev/301

Layer Two Labs: layertwolabs.com

Drivechain info: bip300.xyz