Peg-In

Peg-in is the act of moving bitcoin from the main chain onto a federated Bitcoin sidechain such as Liquid, where it becomes a pegged representation — Liquid Bitcoin (L-BTC) in Liquid's case. The user sends BTC to a deposit address derived from the federation's multisignature script; once the deposit is sufficiently confirmed, an equal amount of L-BTC is issued to the user on the sidechain, backed one-to-one by the locked mainchain coins. No new bitcoin is created and none is destroyed: the mainchain supply is simply immobilized in the federation's custody while its sidechain twin circulates. The reverse trip — redeeming L-BTC for the underlying BTC — is a peg-out, and the two operations together define the "two-way peg" that gives sidechains their name.

How a peg-in works mechanically

The deposit address is not an ordinary receiving address: it is constructed so the funds land under control of the federation's multisignature quorum while cryptographically binding the deposit to the user's sidechain address — so the federation's software knows exactly who to credit and cannot be tricked into crediting anyone else. The entities operating this machinery are the network's functionaries: a fixed set of known institutions, each running hardened hardware that watches the Bitcoin chain, participates in the multisig, and signs off on issuance and redemptions. When the required confirmation depth is reached, the functionaries' consensus issues the L-BTC. From the user's perspective the flow is one Bitcoin transaction plus a wait; the trust machinery is entirely behind the curtain — which is precisely why it deserves examination.

Why 102 confirmations

Liquid's functionaries wait for 102 confirmations on the Bitcoin network before crediting L-BTC — roughly 17 hours. The depth defends against a deep chain reorganization: if L-BTC were issued after a shallow confirmation and the funding transaction was then reorged out of the Bitcoin chain, the sidechain would be circulating claims on coins that no longer exist — the depositor could double-spend the very BTC backing the fresh issuance. One hundred blocks is Bitcoin's own coinbase-maturity horizon for reorg safety, and the peg adopts the same order of magnitude plus margin. The practical consequence: peg-ins are for repositioning treasury, not for point-of-sale. Traders and exchanges keep a standing balance of L-BTC precisely so they never wait on a peg-in, and casual users typically acquire L-BTC by swap rather than pegging in themselves.

The trust trade, stated plainly

A peg-in hands custody of the underlying bitcoin to the federation for as long as its representation stays on the sidechain. This is a categorically different arrangement from the Lightning Network, where a channel is enforced by Bitcoin script and you can always exit unilaterally: a sidechain peg is only as honest as the federation quorum, and if enough functionaries colluded or were simultaneously compromised or coerced, pegged funds could be frozen or lost with no on-chain recourse. What you buy with that trust: one-minute blocks, confidential amounts and asset types, and asset issuance — genuinely useful properties for trading and transfers. What you spend: base-layer trustlessness. A sovereign Bitcoiner should treat sidechain balances the way they treat exchange balances — sized to the trust actually warranted, with long-term savings staying on the main chain under your own keys as a UTXO you alone control.

The bigger picture

Peg-ins illustrate Bitcoin's layered scaling honestly: the base chain optimizes for verification and sovereignty, and each layer above it trades some trust for some capability — Lightning trades liveness requirements, federated sidechains trade custody, and proposed covenant-based designs aim to shrink these trade-offs further. Knowing exactly which trade each layer makes — and pricing it consciously — is the difference between using the stack and being used by it.