Two-Way Peg

What Is a Two-Way Peg?

A two-way peg is a mechanism that enables assets to move bidirectionally between a main blockchain (the parent chain) and a secondary chain such as a sidechain or Layer 2. When a user transfers assets from the parent chain to the sidechain, the parent-chain assets are locked in a special output, and an equivalent amount of tokens are created on the sidechain. The reverse process: burning the sidechain tokens and unlocking the parent-chain assets: completes the round trip.

The concept was formally introduced in the 2014 Blockstream sidechains whitepaper, which proposed extending Bitcoin's functionality by allowing BTC to move to purpose-built sidechains without altering the base protocol. The two-way peg preserves Bitcoin's fixed supply: no new BTC is created, only transferred between chains. This stands in contrast to wrapped Bitcoin schemes where a separate token represents BTC on another chain.

How It Works

A two-way peg operates through two complementary processes: peg-in (parent chain to sidechain) and peg-out (sidechain to parent chain).

Peg-In (Deposit)

1. The user sends BTC to a special locking script on Bitcoin. This script is controlled by whatever trust model the sidechain uses (a federation multisig, a drivechain script, or a covenant-based contract).
2. The user waits for a confirmation period on Bitcoin. Most implementations require a high number of confirmations to guard against chain reorganizations. Liquid requires 102 Bitcoin confirmations for peg-ins.
3. The user submits proof of the deposit to the sidechain. In SPV-based designs, this is a Merkle proof linking the deposit transaction to a Bitcoin block header. In federated designs, the federation nodes observe the deposit directly.
4. The sidechain mints equivalent tokens (such as L-BTC on Liquid or RBTC on Rootstock) and credits them to the user.

Peg-Out (Withdrawal)

1. The user initiates a withdrawal on the sidechain, burning (or locking) the sidechain tokens.
2. A withdrawal proof is generated. In federated models, the federation verifies the burn and signs a Bitcoin transaction unlocking the user's BTC. In SPV-based designs, the proof goes through a contest period where anyone can submit a reorg proof to challenge a fraudulent withdrawal.
3. After the contest or signing period, the locked BTC on the parent chain is released to the user's Bitcoin address.

Confirmation and Contest Periods

The original sidechains whitepaper proposed a symmetric SPV peg with two waiting periods. The confirmation period ensures the deposit or withdrawal has sufficient proof of work behind it, making reversals expensive. The contest period is a window during which anyone can submit evidence that the parent chain has reorganized and the deposit is invalid. A longer contest period increases security but slows transfers: the whitepaper discussed examples as long as thousands of blocks, which was acknowledged as impractical for everyday use.

Trust Models

Not all two-way pegs offer the same security guarantees. The trust assumptions differ substantially depending on who controls the locked BTC and how withdrawals are authorized. The spectrum ranges from fully federated to aspirationally trustless.

Federated Pegs

In a federated peg, a fixed group of known entities (functionaries) hold the keys to the locked BTC via a multisig arrangement. Withdrawals require a threshold of functionaries to sign: for example, Liquid uses an 11-of-15 multisig where each key is stored in a dedicated hardware security module. Security rests on the assumption that fewer than the signing threshold of functionaries are compromised or colluding.

Federated pegs are the most widely deployed model on Bitcoin today. The Liquid Network uses a Strong Federation, and Fedimint mints use a similar federated custody approach for ecash tokens backed by Bitcoin.

SPV Pegs

The original Blockstream design proposed an SPV-based peg where the sidechain validates deposits using simplified payment verification proofs: a Merkle path from the deposit transaction to a block header, plus evidence of sufficient proof of work. No federation is needed because the sidechain can cryptographically verify the parent-chain state.

In practice, pure SPV pegs have not been deployed on Bitcoin mainnet. The challenge is that Bitcoin Script cannot natively verify SPV proofs from another chain. Implementing this would require new opcodes or a soft fork enabling on-chain proof verification, which has not been activated.

Drivechain (BIP-300)

Drivechains propose a miner-enforced peg where Bitcoin miners vote on withdrawal transactions over an extended period (typically months). A withdrawal succeeds only if it receives sufficient miner acknowledgment over many blocks, making theft require sustained majority hashrate collusion. The Rootstock PowPeg incorporates elements of this concept: its functionaries run PowHSM devices that verify cumulative proof of work via merge mining before producing signatures.

BIP-300 requires a Bitcoin soft fork that has not been activated as of 2026, and it remains a subject of debate due to concerns about miner extractable value and centralization pressure on mining.

BitVM-Based Bridges

The BitVM paradigm enables more trust-minimized bridges by allowing arbitrary computation to be verified on Bitcoin through a challenge-response protocol. BitVM2-based bridge designs operate under an honest-minority assumption: withdrawals succeed as long as at least one verifier in the bridge set is honest and online to challenge fraudulent claims.

This represents a significant improvement over federated pegs (which require an honest majority) but still falls short of fully trustless operation. Research into BitVM bridges is active, with multiple teams building production implementations.

Comparison with Rollup Bridges

Rollups on Ethereum use a different approach to bridging. Optimistic rollups post transaction data to L1 and rely on fraud proofs during a challenge period, while ZK-rollups use validity proofs that the L1 smart contract verifies directly. In both cases, the L1 has a smart contract capable of verifying the L2's state transitions, which provides strong security anchoring.

Bitcoin lacks this capability natively. Its Script language cannot verify complex proofs or execute the logic needed to validate sidechain state. This is why most Bitcoin two-way pegs rely on external trust assumptions (federations, miners, or optimistic challenge games) rather than direct on-chain proof verification. Proposals like OP_CAT and other covenant opcodes could narrow this gap by enabling more expressive on-chain verification. For a deeper analysis, see the research on Bitcoin L2 bridge security and L2 trust model comparison.

Use Cases

Sidechain Scaling

The primary use case for two-way pegs is moving BTC to sidechains that offer faster transactions, lower fees, or additional features. Liquid enables confidential transactions and rapid settlement for traders. RSK brings EVM compatibility to Bitcoin-backed assets. In both cases, the two-way peg is what allows users to carry their BTC into these environments and return to the main chain when they choose.

Cross-Chain Liquidity

Two-way pegs enable BTC to participate in ecosystems beyond the base layer. Through pegged assets, Bitcoin holders can access DeFi protocols, issue stablecoins, or interact with smart contract platforms without permanently leaving the Bitcoin network. The cross-chain bridge landscape includes many variations on this theme, from simple federated pegs to complex proof-based systems.

Confidential Transactions and Privacy

Liquid's two-way peg enables access to confidential transactions, which hide transaction amounts using cryptographic commitments. Users peg-in BTC, transact privately on Liquid, and peg-out when they want to return to the base layer.

Why It Matters

Two-way pegs are foundational infrastructure for Bitcoin scaling. Without a mechanism to move BTC between chains, every sidechain or L2 would need its own separate token or rely on custodial wrappers. The two-way peg preserves Bitcoin's monetary properties (fixed supply, holder sovereignty) while extending its reach into new execution environments.

The design space continues to evolve. Newer Layer 2 protocols like Spark take a different approach to extending Bitcoin, using statechains and FROST threshold signatures rather than traditional sidechain pegs. Understanding two-way pegs provides the context for evaluating how different Bitcoin scaling solutions manage the tradeoff between trust minimization, speed, and capital efficiency. For a broader comparison, see the research on Bitcoin Layer 2 solutions.

Risks and Considerations

Federation Trust

Federated pegs concentrate custodial risk in a small group. If a sufficient number of functionaries are compromised, collude, or are coerced by a government entity, they can steal the locked BTC. While hardware security modules reduce this risk, they do not eliminate it. The security of bridges remains one of the most scrutinized topics in blockchain design, and federated pegs have been described as the weakest link in many sidechain architectures.

Withdrawal Delays

Two-way pegs inherently involve waiting periods. Peg-ins on Liquid require 102 Bitcoin confirmations (roughly 17 hours). Peg-outs require federation processing. SPV-based designs with contest periods could take even longer. These delays create friction and lock up capital, reducing the capital efficiency of pegged assets.

Sidechain Failure

If a sidechain suffers a catastrophic failure (a consensus bug, a governance collapse, or a mass exit), the two-way peg can become congested or non-functional. Users may be unable to withdraw their BTC if the sidechain cannot produce valid withdrawal proofs. The isolation property of sidechains means a failure should not affect Bitcoin itself, but it can trap user funds on the sidechain.

Script Limitations

Bitcoin's deliberately constrained scripting language makes fully trustless two-way pegs extremely difficult without protocol changes. The inability to verify external chain state on-chain means every current Bitcoin two-way peg design involves some trust assumption beyond Bitcoin's own security model. Whether through federations, miners, or optimistic verifiers, there is always an entity that can theoretically censor or steal pegged funds.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.