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 getpeginaddressThis returns two values:
mainchain_address: the Bitcoin address where you send your BTCclaim_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
| Step | Action | Duration |
|---|---|---|
| 1 | Generate peg-in address on Liquid | Instant, with synced Liquid node |
| 2 | Send BTC to the address | ~1 block (10 min) |
| 3 | Wait for 102 confirmations | ~17 hours |
| 4 | Claim LBTC on Liquid | Instant 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
- You create a Liquid transaction that burns LBTC and specifies a Bitcoin destination address.
- The federation picks up the peg-out request and, in the next peg-out round, releases the equivalent BTC to your specified Bitcoin address.
- 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:
| Role | Can 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:
- User requests a BTC withdrawal from their LBTC balance.
- You check whether your exchange can peg out directly (participant) or needs to route through a peg out partner.
- If direct: construct a peg out transaction with the user's Bitcoin destination, submit to the network.
- 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
| Step | Action | Duration |
|---|---|---|
| 1 | Create peg-out transaction on Liquid | Instant |
| 2 | Include destination Bitcoin address (PAK verified) | Instant |
| 3 | Federation processes peg-out round | ~11 to 35 minutes |
| 4 | BTC arrives on Bitcoin main chain | 1 confirmation |
Peg workflow for exchanges
Most exchanges implement the peg as a separate flow from normal deposits/withdrawals:
| Operation | User experience |
|---|---|
| Deposit LBTC | User sends LBTC to a deposit address → credited after 2 Liquid confirmations |
| Deposit BTC via peg-in | User sends BTC to a peg-in address → credited as LBTC after 102 BTC confirmations |
| Withdraw LBTC | User gets LBTC to any Liquid address → sent after approval |
| Withdraw BTC via peg out | User 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
- What is a Liquid peg-in?
- Peg in BTC to the Liquid Network
- Enable peg-in validation on my Liquid node
- What is a Liquid peg-out?
Next steps
- Running Your Elements Node: set up the infrastructure needed for self hosted peg-in validation
- Go Live Checklist: prepare for production