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 a FEDERATION multisig (a large k-of-n threshold)
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.

By the numbers — what a federation actually buys you

Liquid, the best-known federated sidechain, turns the speed/trust tradeoff into concrete numbers:

block time:   ~1 minute              (vs Bitcoin's ~10)
finality:     ~2 blocks ≈ 2 minutes  (vs the ~6-block / ~1-hour convention on Bitcoin)
custody:      a fixed federation of functionaries holds the locked BTC
              behind a large multisig threshold

You get blocks roughly 10× faster plus confidential amounts — in exchange for trusting that a threshold of those functionaries won’t collude or go dark. Faster and more featureful, but notice what moved: the security floor is now the federation, not proof-of-work. That single substitution is the whole tradeoff, made measurable.

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.

The architect’s lens

Pegs are a deliberate trust substitution — the design only makes sense if you name what you give up:

• Why does it exist? Because the one ledger is intentionally conservative, and some uses want properties it won’t add — faster blocks, confidential amounts, whole-coin transfers. A peg lets value visit a system with other tradeoffs and return, while the real coins stay anchored to Bitcoin.
• What problem does it solve? Features the base chain refuses to bake in. A two-way peg locks real BTC and issues a claim elsewhere: federated pegs (Liquid: ~1-min blocks, ~10× faster, confidential amounts), drivechains (miner-ratified, proposed), and statechains (instant off-chain transfer of a whole UTXO, no liquidity to balance).
• What are the trade-offs? Every step right on the spectrum imports a new trust assumption — a federation that could collude (Liquid’s k-of-n), miners adjudicating peg-outs (drivechains), or a statechain entity that must honestly delete its old keys. Nothing on top of Bitcoin is more trustless than Bitcoin.
• When should I avoid it? Wrong for cold savings or anything that needs the full proof-of-work security floor — keep those on a base-layer UTXO. The honest question is never “is this secure?” but “whom must I now trust, and for what?”
• What breaks if I remove it? You lose base-anchored value with non-Bitcoin properties (sub-minute blocks, confidential amounts, fee-free whole-coin transfers) — but you also shed the federation/miner/ entity trust those properties cost. The peg is that trade, made concrete.

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.

Show answers

1. Only a claim on the coins moves to the other system; the real BTC stays locked on the Bitcoin base chain and never leaves. The whole analysis is: who or what guarantees you can always redeem that claim — and a peg almost always guarantees it with something weaker than Bitcoin’s proof-of-work-plus-your-keys.
2. You trust the federation’s honesty and availability — a fixed set of known functionaries (exchanges, businesses) who jointly custody the locked BTC behind a k-of-n multisig. If a threshold colludes or is compromised, the locked BTC is at risk. It’s a trusted-third-party model — smaller and more accountable than a bank, but emphatically not Bitcoin’s “trust no one.”
3. They’re controversial because they shift meaningful power onto miners, who would effectively adjudicate peg-outs (proposed and ratified by miner voting over months) — which many consider an unacceptable change to Bitcoin’s security assumptions. Their status: a proposal (BIPs 300/301), not part of consensus and not activated — it would require a contentious soft fork.
4. A statechain transfers ownership of a whole specific UTXO off-chain (handing over the right to sign, with a statechain entity co-signing) — unlike Lightning, there’s no liquidity to balance, but you move whole coins, not arbitrary amounts. The key trust assumption: that the statechain entity honestly deletes its old keys, so a previous owner can’t collude with it to claw the coin back.
5. Ordering, most trustless/slowest → fastest/most trust: base-layer UTXO (trust no one) → Lightning (your keys, base chain as court of last resort) → statechain (trust the entity to delete keys) → federated peg (trust the federation). Each step right buys convenience by importing a new trust assumption — nothing on top of Bitcoin is more trustless than Bitcoin itself.