A sidechain is a separate blockchain that allows Bitcoin to be "moved" between chains via a two-way peg. This chapter examines the theoretical foundations of sidechains, the trust models of different implementations (Liquid, RSK, Stacks), and the fundamental tradeoffs between security, functionality, and decentralization.
31.1 Two-Way Peg Fundamentals
Definition 31.1 (Sidechain)
A sidechain is a blockchain that:
- Has its own consensus mechanism
- Can receive and release Bitcoin via a two-way peg
- Operates independently of Bitcoin's main chain
Definition 31.2 (Two-Way Peg)
A two-way peg mechanism allows:
- Peg-in: Lock BTC on mainchain → mint equivalent on sidechain
- Peg-out: Burn on sidechain → unlock BTC on mainchain
The peg maintains a 1:1 relationship: total sidechain tokens ≤ locked BTC.
Proposition 31.1 (Peg Security Tradeoff)
Without changes to Bitcoin's consensus rules, a trustless two-way peg (where trustless means peg-out authorization verified entirely by the consensus rules of Definition 13.18) is impossible: Bitcoin Script has no opcode that can verify sidechain consensus, so some extrinsic trust (or a new opcode) must authorize peg-outs. The options are:
- Trusted custodians (federation)
- Bitcoin consensus changes (SPV proofs, validity proofs)
- Economic incentives (collateral, fraud proofs)
BitVM-style constructions (Exercise 31.4) do not contradict this: they reduce trust to the assumption that one of n designated verifiers is honest: trust minimization, not trustlessness in the above sense.
31.2 Federated Sidechains
The most practical current approach is to trust a federation to manage the peg.
Definition 31.3 (Federated Peg)
A federated peg uses a multisig controlled by known entities (the federation):
- Peg-in: Send BTC to federation multisig
- Sidechain validates, mints pegged tokens
- Peg-out: Federation signs BTC release after sidechain burn
Definition 31.4 (Federation Security Model)
For an m-of-n federation:
- Liveness: Requires m members to process peg-outs
- Safety: Requires n − m + 1 honest members to prevent theft
- Attack cost: Must corrupt m members to steal funds
31.2.1 Liquid Network
Example 31.1 (Liquid)
Liquid (by Blockstream) is a federated sidechain:
- Federation: 60+ members (exchanges, financial institutions), with 15 functionaries operating the peg and signing blocks
- Peg: 11-of-15 multisig
- Consensus: Federated (1-minute blocks)
- Features: Confidential Transactions, Issued Assets
Example 31.2 (Liquid Peg-in Process)
- User sends BTC to federation multisig address
- Wait for 102 Bitcoin confirmations
- Federation validates and signs L-BTC mint
- User receives L-BTC on Liquid network
Peg-out reverses this and is faster, but direct peg-outs are restricted to federation members; ordinary users typically swap L-BTC for BTC through an exchange.
Remark 31.1 (Liquid Tradeoffs)
| Advantage | Disadvantage |
|---|---|
| 1-minute blocks (2-block finality) | Federated trust model |
| Confidential Transactions | Regulatory exposure of federation |
| Asset issuance | Limited decentralization |
| Production-tested | Hundreds of millions of dollars of AUM risk concentration |
31.2.2 RSK (Rootstock)
Example 31.3 (RSK)
RSK is an EVM-compatible sidechain:
- Consensus: Merge-mined with Bitcoin
- Peg: Federated (PowPeg) with HSM enforcement
- Features: Smart contracts (Solidity)
- Token: RBTC (Smart Bitcoin)
Definition 31.5 (Merge Mining)
Merge mining allows miners to mine both Bitcoin and a sidechain simultaneously by including the sidechain block hash in Bitcoin's coinbase. The sidechain accepts Bitcoin PoW as valid.
31.3 SPV Sidechains (Theoretical)
The original sidechain proposal (Blockstream, 2014) envisioned SPV proofs.
Definition 31.6 (SPV Peg)
An SPV sidechain would verify peg-outs using SPV proofs:
- Sidechain transaction burns pegged tokens
- User creates SPV proof of burn (sidechain headers + Merkle path)
- Bitcoin script verifies SPV proof
- BTC released from peg address
Remark 31.2 (SPV Peg Limitations)
SPV pegs face fundamental challenges:
- Script limitations: Bitcoin Script cannot verify SPV proofs
- Soft fork required: New opcode needed (never activated)
- Security weakness: Sidechain 51% attack could steal peg funds
31.4 Validity Rollups and ZK Sidechains
Emerging designs use validity proofs for trust-minimized pegs.
Definition 31.7 (Validity Rollup)
A validity rollup posts compressed state updates to Bitcoin with a cryptographic proof (typically ZK-SNARK/STARK) that the state transition is valid.
Definition 31.8 (ZK Bridge)
A ZK bridge uses validity proofs for peg verification:
- Sidechain generates ZK proof of valid peg-out
- Bitcoin verifies proof (requires new opcodes)
- No federation needed: the proof is self-validating
Remark 31.3 (Bitcoin ZK Requirements)
For Bitcoin to verify ZK proofs natively:
- Need OP_CAT (for proof construction)
- Potentially need OP_VERIFYSTARKPROOF or similar
- Active research area (BitVM, etc.)
31.5 Stacks and Proof of Transfer
Example 31.4 (Stacks / PoX)
Stacks uses Proof of Transfer (PoX):
- Miners commit BTC to participate in Stacks consensus
- BTC goes to STX Stackers (recycled security)
- Stacks blocks anchor to Bitcoin blocks
- Not a traditional sidechain: no direct BTC peg until sBTC
Example 31.5 (sBTC)
sBTC (2024) adds a Bitcoin peg to Stacks:
- Threshold signature scheme for peg custody
- Signer set of STX Stackers (launched Dec 2024 with a curated ~15-signer set; decentralization is the end goal)
- Economic penalties for misbehavior
31.6 Comparison of Approaches
| Sidechain | Peg Type | Trust Model | Features |
|---|---|---|---|
| Liquid | Federated 11/15 | Trust federation | CT, Assets, Fast |
| RSK | Federated + MM | Trust federation + miners | EVM, Smart contracts |
| Stacks | PoX + sBTC | Economic + threshold sig | Smart contracts |
| ZK Rollup | Validity proof | Cryptographic (future) | Any (theoretical) |
Remark 31.4 (Sidechain Security Hierarchy)
Security guarantees from strongest to weakest:
- Bitcoin mainchain: Full consensus security
- Validity rollup: Cryptographic proofs (if implemented)
- Optimistic rollup: Fraud proofs + challenge period
- Large federation: m-of-n trust (e.g., 11-of-15)
- Small federation: Few trusted parties
- Single custodian: Full trust in one entity
31.7 Sidechain Economics
Remark 31.5 (Sidechain Fee Market)
Sidechains create parallel fee markets:
- Low-value transactions move to cheaper sidechain
- High-value transactions stay on mainchain
- Peg operations incur mainchain fees
- Net effect on mainchain fees: debated
Remark 31.6 (Sidechain Value Proposition)
Sidechains are useful when:
- Users need features Bitcoin does not have (privacy, smart contracts)
- Users accept the trust tradeoff for benefits
- Transaction volume justifies peg-in/out costs
31.8 Hashrate-Escrow Pegs: The Drivechain Episode
A third peg family completes the taxonomy: let Bitcoin's miners themselves custody the peg. Drivechains (BIP-300/301, proposed by Paul Sztorc) propose adding one opcode (OP_DRIVECHAIN) under which sidechain deposits sit in a hashrate escrow: a withdrawal bundle requires 13,150 miner ACKs within a 26,300-block (~6-month) window, with sidechain blocks produced via blind merged mining: miners sell block space to sidechain operators without validating sidechain state.
Remark 31.7 (Why It Did Not Activate)
Critics held that the design asks users to trust two parties the base layer does not ask them to trust: a miner majority can vote deposits to itself, slowly and in public, which proponents argued is the defense (the theft is visible and punishable, up to a user-activated soft fork) and which critics judged a description of the design rather than an attack on it. And since Bitcoin never validates sidechain state, whoever maintains each sidechain's software defines its rules, including peg behavior (the Section 33.9 argument). After a decade without approaching rough consensus, the proposal's advocates announced an exit in April 2026: a hard fork ("eCash," scheduled for ~block 964,000, August 2026, unrelated to eCash/XEC of Section 27.6.3) with drivechains enabled natively—and, controversially, with roughly 500,000 of the Satoshi-era coins' balances reassigned to project investors on the forked ledger. No BTC moves, but every prior fork in Chapter 27 preserved balances exactly; critics called it confiscation. The episode illustrates two results of this volume: activation requires the broad coordination of Chapter 33, not only technical coherence; and exit forks face the adoption game of Section 26.4.
Exercises
Exercise 31.1
Calculate the security threshold for an 11-of-15 federation. How many members must collude to steal funds? How many must be offline to halt peg-outs?
Exercise 31.2
Design a game-theoretic peg mechanism using collateral. How much collateral should custodians post? What happens if BTC price changes?
Exercise 31.3
Analyze the attack cost for a merge-mined sidechain. If the sidechain has 30% of Bitcoin's hashrate participating in merge mining, what is the cost of a 51% attack on the sidechain?
Exercise 31.4
Research BitVM. How does it enable validity proofs on Bitcoin without new opcodes? What are its limitations?