Timechain Wiki

Liquid Network

10 min read

Liquid is a Bitcoin sidechain operated by the Blockstream-coordinated Liquid Federation — roughly 15–65 functionaries (exchanges, custodians, and other Bitcoin-industry participants) who run the signing infrastructure that secures it. Pegging in sends BTC to a federation-controlled base-layer address and mints an equivalent amount of L-BTC on Liquid; pegging out reverses the operation through a federated co-signed withdrawal. Blocks are produced on a fixed one-minute schedule by functionary rotation, and transactions use confidential transactions (CT) by default, hiding amounts (but not the transaction graph) via Pedersen commitments and bulletproof range proofs. Principal use cases are inter-exchange settlement, tokenized-asset issuance (USDT-Liquid, tokenized securities, NFT-style issuances), and Layer-2-on-Layer-2 patterns (Liquid Lightning, Liquid Multisig). The trust profile is structurally federated: an honest 1-of-N produces safety, an honest threshold produces liveness. The federation has operated without major incident since the 2018 mainnet launch, but represents a meaningfully different trust model from the base-layer protocol.

Why this note matters

Liquid is the dominant deployed sidechain in the Bitcoin ecosystem and the principal alternative to Lightning for off-base-layer Bitcoin-denominated value flow. Understanding what Liquid is — and specifically what trust assumptions Liquid asks users to accept — is the precondition for the broader sidechain debate (see BIP-300 and the Drivechains debate) and for understanding the layered-money architecture Bhatia and others describe.

The conceptual distinction between trust-minimized Layer-2 (Lightning, ARK) and federated Layer-2 (Liquid) is the load-bearing analytical structure, and Liquid — engaged here as deployed reality rather than proposal — is its principal deployed example.

Federated sidechain architecture

Liquid uses a federated-consensus model distinct from both Bitcoin’s proof-of-work consensus and Lightning’s peer-to-peer-channel construction:

  • Functionaries are the federation members who run signing infrastructure. The functionary set is approximately 15-65 entities (the exact number has varied; current public information lists ~65 participants).
  • Block production is round-robin across functionaries on a one-minute schedule. The current block-producing functionary signs blocks with their signing key; signing is verified against the federation’s published key set.
  • Threshold consensus for sensitive operations (peg-out, federation key rotation, software updates) requires a configurable threshold of functionary signatures — typically 11-of-15 or similar threshold dynamics that the federation maintains.

The functionary entities. The Liquid Federation membership includes major exchanges (Bitfinex, BTSE, OKEx historically, others), custodians (BitGo, Unchained Capital), and Bitcoin-infrastructure companies (Blockstream itself as a participant). Membership has rotated over time; the full current list is published by Blockstream.

The functionary HSM. Each functionary operates a hardware security module that holds the functionary’s signing keys. The HSM design includes operational restrictions (geographic location, network-isolation requirements, software-update procedures) that the federation specifies. The HSM-based design is the federation’s hardware-rooted security model.

Peg-in and peg-out mechanics

Peg-in (Bitcoin → Liquid):

  1. A holder sends Bitcoin to a federation-controlled multisig address on the base layer.
  2. After the base-layer transaction has 102 confirmations (a fixed delay; ~17 hours), the holder can claim an equivalent amount of L-BTC on Liquid.
  3. The federation verifies the base-layer deposit and credits the holder’s Liquid address.

The 102-confirmation requirement is a security buffer against base-layer reorgs. Pre-2024, the buffer was 144 blocks; it was reduced to 102 to improve UX while remaining safely deep.

Peg-out (Liquid → Bitcoin):

  1. A holder burns L-BTC on Liquid (sends to a special peg-out destination).
  2. The federation processes the peg-out request; functionaries co-sign a base-layer transaction releasing the corresponding Bitcoin to the holder’s chosen base-layer address.
  3. The holder receives Bitcoin on the base layer after confirmation.

Peg-out is the federation-trust-bearing operation: the holder’s Bitcoin is in federation custody until peg-out is processed and confirmed. The federation could in principle refuse a peg-out (the trust assumption being violated); historically this has not occurred for compliant peg-out requests.

Peg-out access is restricted. Not every Liquid participant can directly peg-out; the federation maintains an allowlist of entities (typically the functionary members themselves and authorized partners) who can initiate peg-out transactions. Smaller participants typically peg-out by selling L-BTC on an exchange that processes peg-out internally — adding a counterparty-trust layer beyond the federation trust.

Confidential transactions and the privacy model

Liquid transactions use Confidential Transactions (CT) by default — a Greg Maxwell-co-designed cryptographic construction that hides transaction amounts while preserving auditability:

  • Pedersen commitments to amounts replace plain numeric amounts. The commitment binds to a specific value but reveals nothing about that value to observers.
  • Bulletproofs (Bünz et al.) prove that committed amounts are non-negative and that input and output amounts balance, all without revealing the values themselves.
  • Asset commitments (for Liquid’s multi-asset support) similarly hide which asset is being transferred (USDT vs L-BTC vs tokenized security) while preserving the per-asset balance verification.

What CT hides: amounts and asset types. What CT does not hide: transaction graph (which addresses sent to which) and metadata (transaction timestamps, sizes, signing structure).

The privacy improvement over base-layer Bitcoin is real but partial. Transaction-graph analysis (chain analysis) still works on Liquid; only the per-transaction amount and asset are private.

The auditability tradeoff. Hidden amounts mean external observers cannot verify Liquid’s total supply or detect inflation if a federation-level bug or compromise occurred. The federation publishes periodic Proof of Reserves attestations to compensate, but the cryptographic-trust profile is different from base-layer Bitcoin (where total supply is directly auditable).

Asset issuance and multi-asset architecture

Liquid supports issuance of additional assets beyond L-BTC. Major deployed asset families:

  • Tether USDT-Liquid. USDT issued on Liquid; substantial inter-exchange settlement volume. The Liquid version offers faster settlement than base-layer USDT-Omni (which was discontinued) and lower fees than Tron-USDT or Ethereum-USDT — though the trust profile is the Liquid Federation plus Tether.
  • Tokenized securities. Several issuers have used Liquid for tokenized stock and bond instruments — Bitfinex Securities products being the most prominent. The regulatory and operational layer is jurisdiction-specific; Liquid provides the transaction infrastructure.
  • NFT-style issuance (rare in practice; Liquid is not optimized for high-volume NFT activity).

The multi-asset architecture is one of Liquid’s distinguishing features versus other Bitcoin sidechains. The L-BTC and the issued assets share the same transaction infrastructure and the same federated trust model.

Liquid Lightning and Layer-2-on-Layer-2

Lightning channels can be operated on Liquid as well as on the base layer. Liquid Lightning channels:

  • Use L-BTC (or other Liquid assets) as the channel funding currency.
  • Inherit Liquid’s faster confirmation and confidential-amount properties.
  • Trade base-layer’s trust-minimized settlement for federated-Liquid’s settlement.

The deployment is small but real. The use case is high-frequency low-trust-cost Lightning operation for users already in the Liquid ecosystem.

Liquid Multisig and emerging patterns. Various multisig-and-vault constructions on Liquid use the federated trust model as one layer of a layered-trust design. The pattern is operationally niche but architecturally interesting.

Operational history and incidents

Liquid mainnet launched in September 2018. Major operational milestones:

  • 2018 launch — initial federation of ~15 functionaries.
  • 2019-2021 expansion — federation growth to ~50+ functionaries; asset-issuance growth (USDT, tokenized securities).
  • 2021 “Liquid emergency” — a federation-coordinated emergency response to a discovered key-handling issue with the HSM software; functionary re-keying executed without user-facing impact. This was the highest-profile operational stress event; the federation’s response was generally praised as transparent.
  • 2024-2025 — continued operation; periodic peg-out batch processing; Liquid Lightning experimentation.

No significant fund-loss incident has occurred. The federation has not censored peg-out requests in any publicly known case. The operational track record is positive within the federated-trust framing.

Tradeoffs and design choices

Federated trust vs trust-minimized trust. Liquid’s federated trust model is meaningfully different from the base-layer protocol’s trust model. Users implicitly trust the federation collectively for safety (the federation will not move funds without proper authorization) and for liveness (the federation will continue operating). The trust profile is real and is the principal point of analytical-critique engagement. See BIP-300 and the Drivechains debate for the substantive engagement with alternative sidechain trust models.

Privacy vs auditability. Confidential Transactions hide amounts but make total-supply auditing impossible without federation cooperation. The tradeoff is structurally different from base-layer Bitcoin (where supply is directly auditable but amounts are public). Proof-of-Reserves attestations substitute for direct auditability but require trusting the attestation methodology.

Federation-allowlisted peg-out vs unrestricted peg-out. Peg-out access is restricted to the functionary set and authorized partners. Smaller users peg-out via exchange-mediated processes that add a counterparty-trust layer. The design choice prioritized operational simplicity (the federation can batch and validate peg-out requests) at the cost of UX-frictionless peg-out for smaller users.

Multi-asset architecture vs Bitcoin-only. Liquid supports issuance of arbitrary assets including stablecoins and tokenized securities. The maximalist position has internal disagreement about whether multi-asset capability on a Bitcoin sidechain is appropriate; the Bitcoin-not-crypto framing distinguishes Bitcoin-denominated value flow (legitimate sidechain use) from arbitrary altcoin-issuance (Bitcoin-not-crypto position skeptical). Liquid sits in tension with this distinction.

Federated consensus vs proof-of-work consensus. The functionary signing model trades PoW’s permissionless security for federated permissioned security. The choice was deliberate — PoW on a sidechain has its own well-known issues (merge-mining centralization concerns; security-budget questions) — but the result is a structurally different security model.

Substantive analytical critique of federated-sidechain trust models lives in BIP-300 and the Drivechains debate (which proposes a different trust profile for sidechains) and in the broader Custody concentration risks framing.

Open questions for further development

  • How does the federation scale as new functionaries join? The current functionary count balances decentralization against operational coordination cost; the optimal size is unsettled.
  • What is Liquid’s trajectory as competing Layer-2 architectures mature? ARK, statechains, and emerging covenant-light designs may address some of Liquid’s use cases without federated trust.
  • How does Liquid interact with Bitcoin’s monetization framework? The institutional-stack thesis (see Wall Street securitization of Bitcoin) and Liquid’s exchange-and-custodian-heavy functionary set suggest Liquid’s role may shift as institutional Bitcoin adoption matures.
  • What is the appropriate Proof of Reserves cadence and standard for Liquid? The federation publishes PoR attestations but the methodology and frequency are not standardized across the ecosystem.

Canonical sources for this note

Specifications and documentation

  • Liquid Network technical documentation: liquid.net and docs.liquid.net
  • Liquid GitHub: github.com/ElementsProject/elements — the Elements codebase Liquid is built on
  • “Strong Federations” white paper (Blockstream, 2016) — the foundational federated-sidechain design

Cryptographic primitives

  • Greg Maxwell, “Confidential Transactions” (2015) — the CT construction Liquid uses
  • Benedikt Bünz et al., “Bulletproofs: Short Proofs for Confidential Transactions and More” (2017) — the range-proof construction

discussion references

Graph View

Backlinks