Peg-in and Peg-out

Liquid's 1:1 peg with Bitcoin is the mechanism that connects the two networks. This page explains how peg-in (BTC → LBTC) and peg-out (LBTC → BTC) transactions work, and how to implement them as part of your exchange workflow.

What is the peg?

Every LBTC on Liquid is backed by an equivalent amount of BTC held by the Liquid Federation on the Bitcoin main chain. The Liquid federation functionaries hold the locked BTC in a federated multisig wallet. When users peg in, they send BTC to the federation and receive LBTC on Liquid. When they peg out, the reverse happens: LBTC is destroyed, and BTC is released.

The ratio is always 1:1. There is no more LBTC in circulation than there is BTC locked by the federation.

flowchart LR
  subgraph btc["Bitcoin Mainnet"]
    user1["User BTC wallet"]
    fedAddr["Federation multisig address"]
  end

  subgraph liq["Liquid Network"]
    user2["User LBTC wallet"]
    claim["Peg-in claim tx"]
  end

  user1 -->|"1. send BTC"| fedAddr
  fedAddr -.->|"2. 102 confirmations"| claim
  claim -->|"3. mint LBTC"| user2

  user2 -->|"a. burn LBTC + peg out request"| liq
  fedAddr -->|"b. release BTC (~17 min)"| user1

Peg in (Bitcoin → Liquid)

Peg in is the process of moving BTC from Bitcoin to Liquid. Here's how it works step by step.

Step 1: Generate a peg in address

Using your Liquid node wallet, generate a peg-in address:

elements-cli getpeginaddress

This returns two values:

  • mainchain_address: the Bitcoin address where you send your BTC
  • claim_script: a script you'll need later to claim the corresponding LBTC on Liquid

The mainchain_address is a unique federation controlled address, tweaked by the keys in your wallet. It's constructed so that only the functionaries can spend from it. Importantly, it's derived in a way that proves the funds are destined for your Liquid wallet.

Step 2: Send BTC to the peg-in address

From any Bitcoin wallet, send your BTC to the mainchain_address. This is a normal Bitcoin transaction. Nothing special needed.

Step 3: Wait for 102 Bitcoin confirmations

Peg-ins requires 102 confirmations on the Bitcoin main chain. This is about 17 hours of waiting. The large confirmation requirement exists to protect against deep Bitcoin reorganizations, just like Bitcoin coinbase transactions. If a reorg were to unwind your deposit, fake LBTC could be created.

Step 4: Claim your LBTC on Liquid

After 102 Bitcoin block confirmations, claim your LBTC on Liquid:

elements-cli claimpegin <bitcoin_tx_hex> <bitcoin_tx_merkle_proof>

Many wallets (including GDK based wallets and Blockstream Green) automate this step. You don't need to manually construct the claim in normal operation. Your Liquid wallet does it for you once the confirmations are reached.

The claim creates a new LBTC UTXO in your Liquid wallet, equal in value to the BTC you sent (minus any fees).

Peg-in summary

StepActionDuration
1Generate peg-in address on LiquidInstant, with synced Liquid node
2Send BTC to the address~1 block (10 min)
3Wait for 102 confirmations~17 hours
4Claim LBTC on LiquidInstant once ready

See What is a Liquid peg-in? and Peg in BTC to the Liquid Network for Blockstream's official walkthrough.

Peg out (Liquid → Bitcoin)

Peg out moves LBTC back to Bitcoin. It's faster than peg in but has some restrictions.

How peg out works

  1. You create a Liquid transaction that burns LBTC and specifies a Bitcoin destination address.
  2. The federation picks up the peg-out request and, in the next peg-out round, releases the equivalent BTC to your specified Bitcoin address.
  3. The BTC arrives on the main chain.

Typical processing time is 11 to 35 minutes, averaging ~17 minutes per peg-out round.

Peg-out Authorization Key (PAK)

To prevent abuse, peg-outs require a Peg-out Authorization Key (PAK). Only users with registered PAK entries can peg out. This is to ensure that even if a set of functionaries were compromised, they couldn't redirect user funds to attacker controlled addresses.

Each PAK entry binds a user's identity (or wallet) to a specific Bitcoin output. When you peg out:

  • The transaction proves that the Bitcoin destination address is derived from one of the registered PAK entries.
  • It doesn't reveal which specific PAK entry, just that a valid one exists.

Who can peg out?

Not all Liquid participants can peg out directly:

RoleCan peg out?
Functionaries (Liquid federation members)Yes, directly
Participants (institutional members with PAK)Yes, directly
General public (individuals, many exchanges)Indirect, use a federation member or exchange

If you're a general participant, you typically peg out indirectly by sending LBTC to an exchange (like Bitfinex or SideSwap) that supports peg out on your behalf. The exchange handles the PAK and executes the actual peg out.

If you want to peg out directly from your exchange, you'll need to become a Liquid participant or use a peg out partner.

For everyday users, it is often more convenient to perform an atomic swap between Bitcoin/Lightning and Liquid instead of pegging in or out, using a swap provider like Boltz.

Implementing peg out as an exchange

For most exchanges, the flow is:

  1. User requests a BTC withdrawal from their LBTC balance.
  2. You check whether your exchange can peg out directly (participant) or needs to route through a peg out partner.
  3. If direct: construct a peg out transaction with the user's Bitcoin destination, submit to the network.
  4. If via partner: send LBTC to the partner, they handle the peg-out to your user's Bitcoin address.

See What is a Liquid peg-out? for the full flow.

Peg out summary

StepActionDuration
1Create peg-out transaction on LiquidInstant
2Include destination Bitcoin address (PAK verified)Instant
3Federation processes peg-out round~11 to 35 minutes
4BTC arrives on Bitcoin main chain1 confirmation

Peg workflow for exchanges

Most exchanges implement the peg as a separate flow from normal deposits/withdrawals:

OperationUser experience
Deposit LBTCUser sends LBTC to a deposit address → credited after 2 Liquid confirmations
Deposit BTC via peg-inUser sends BTC to a peg-in address → credited as LBTC after 102 BTC confirmations
Withdraw LBTCUser gets LBTC to any Liquid address → sent after approval
Withdraw BTC via peg outUser gets BTC to any Bitcoin address → sent after peg-out round (~17 min)

Clearly communicate the different timings to your users. The 102 confirmation peg0in delay surprises new users, so make it visible in your UI.

Security considerations

  • Always validate peg-ins with a Bitcoin node if you operate at scale. See Enable peg-in validation.
  • Don't accept peg-ins before 102 confirmations. A malicious actor could cause a deep reorg on Bitcoin and roll back the peg-in deposit.
  • PAK management: if you operate a PAK entry, protect those keys like you'd protect custody keys. Compromised PAKs could allow unauthorized peg-outs.
  • Monitor the federation status. If too many functionaries go offline, peg-ins and peg-outs can stall. In this case the federation can start the process of rotating functionary operators.

Resources

Next steps

  • Running Your Elements Node: set up the infrastructure needed for self hosted peg-in validation
  • Go Live Checklist: prepare for production

The Liquid Network is a Bitcoin layer-2 enabling the issuance of security tokens and other digital assets.

© 2023 Liquid Network
All rights reserved.

Feedback and Content Requests

We'd be happy to hear your suggestions on how we can improve this site.

BuildOnL2 Community

The official BuildOnL2 community lives
at community.liquid.net. Join us and build the future of Bitcoin on Liquid.

Telegram

Community-driven telegram group where
most of the Liquid developers hang out.
Go to t.me/liquid_devel to join.