Sidechains, Statechains & Two-Way Pegs

Lightning scales payments by moving them off-chain while leaning on Bitcoin’s base layer for settlement. A different family of systems asks a more radical question: what if you move the coins themselves onto a separate chain with different rules and different tradeoffs, then move them back when you’re done? That is the world of sidechains, statechains, and pegs — and the single most important thing to understand about all of them is what you give up in exchange.

The core idea: a two-way peg

A peg is a mechanism for representing bitcoin on another system at a fixed 1:1 value, with a way to get the real coins back.

  BITCOIN (main chain)                    OTHER SYSTEM (sidechain / etc.)
  ┌────────────────────┐   peg IN         ┌───────────────────────────┐
  │ coins LOCKED here   │ ───────────────► │ equal value ISSUED here    │
  │ (can't be spent     │                  │ (faster / private / new    │
  │  while pegged out)  │ ◄─────────────── │  features)                 │
  └────────────────────┘   peg OUT         └───────────────────────────┘
        the real BTC never leaves Bitcoin; a *claim* on it moves

The real coins stay on Bitcoin, locked. What moves is a claim. The whole question is: who or what guarantees that you can always redeem that claim for the real coins? Bitcoin’s base layer guarantees this with proof-of-work and your own keys. A peg almost always guarantees it with something weaker — and naming that “something weaker” is the entire analysis.

The base layer is the security floor, not the ceiling

Nothing built on top of Bitcoin is more trustless than Bitcoin itself. Every design on this page trades away some of Bitcoin’s trust-minimization for speed, privacy, or features. The honest framing is not “is this secure?” but “whom must I now trust, and for what?”

Federated pegs (Liquid-style)

The most common live design uses a federation: a fixed set of known functionaries (exchanges, businesses) jointly custody the locked BTC behind a multisig. Peg-in locks coins to the federation; peg-out requires the federation to sign the release. Liquid is the best-known example.

Peg-in:  user → locks BTC to FEDERATION multisig (e.g. 11-of-15)
On Liquid: user holds L-BTC, gets fast blocks + confidential amounts
Peg-out: federation signs to release the real BTC back to the user

• What you gain: faster, more predictable blocks; confidential transaction amounts; issuance of other assets.
• What you trust: the federation’s honesty and availability. If a threshold of functionaries collude or are compromised, the locked BTC is at risk. This is a trusted-third-party model — a smaller, more accountable one than a bank, but emphatically not Bitcoin’s “trust no one” model.

This is a deliberate, eyes-open tradeoff: you accept a federation in exchange for speed and features that the base chain doesn’t offer.

Drivechains (proposed, not activated)

Drivechains are a proposal to peg with no federation — using miners instead. Peg-outs would be proposed and then ratified by miner voting over a long window (months), giving the network time to spot and reject a fraudulent withdrawal.

Status: proposal

Drivechains (associated with BIPs 300/301) are not part of Bitcoin consensus and have not been activated. They would require a soft fork and remain contentious. The central critique is that they shift meaningful power and responsibility onto miners — who would effectively adjudicate peg-outs — which many consider an unacceptable change to Bitcoin’s security assumptions. Treat drivechains as an idea under debate, not a deployed system.

Statechains

Statechains are a cleverer, lower-trust point on the spectrum. The idea: transfer ownership of a specific UTXO off-chain by handing over the right to sign for it, with help from a statechain entity that co-signs — but is constructed so it cannot spend the coin unilaterally and so the current owner can always close to the base chain.

A single UTXO (2-of-2: owner key + statechain entity)
   owner A  ──transfer──►  owner B  ──transfer──►  owner C    (all off-chain)
   at every step: the holder can broadcast a backup tx to claim on-chain

• What you gain: instant, fee-free transfer of whole coins between parties without an on-chain transaction each time — and unlike Lightning, no liquidity to balance.
• What you trust: that the statechain entity deletes its old keys honestly (so a previous owner can’t collude with it to claw the coin back). Designs use timelocked backup transactions and “blind” signing to shrink this trust, but it is still weaker than holding a plain UTXO. You also transfer whole coins, not arbitrary amounts.

Where each design sits

MORE trustless / slower ◄──────────────────────────────► faster / MORE trust
  base-layer UTXO   Lightning   statechain   drivechain*   federated peg
  (trust no one)    (your keys, (trust entity (trust        (trust the
                     court of    to delete    miners*)       federation)
                     last resort)keys)
                                              *proposed, not activated

There is no free lunch. Each step right buys convenience by importing a new trust assumption. The skill is matching the tool to the job: base layer for cold savings, Lightning for spending, sidechains/statechains for use-cases where their specific tradeoff is acceptable.

The thread

How does this help untrusting strangers agree on one ledger? These systems are an admission that the one ledger is deliberately conservative — and that some uses want different properties. Pegs let value visit a system with other tradeoffs and then return, while the real coins stay anchored to Bitcoin’s consensus. The danger is forgetting that the anchor is the only part with Bitcoin’s full security: the moment your coins are pegged out, “untrusting strangers agree” is replaced by “you trust a federation, or miners, or an entity.” Knowing exactly which is the whole point.

Check your understanding

1. What actually “moves” in a two-way peg, and what stays on the Bitcoin base chain?
2. In a federated peg like Liquid, precisely whom are you trusting, and what could that party do if a threshold colluded?
3. Why are drivechains controversial, and what is their current consensus status?
4. How does a statechain differ from Lightning, and what is the key trust assumption it rests on?
5. Place base-layer UTXOs, Lightning, statechains, and federated pegs on a trust-vs-speed spectrum and justify the ordering.