Progress pill
Fundamentals

Liquid Network Overview

Liquid Bootcamp Essentials

Liquid Network Overview

  • Liquid Network Architecture and Consensus
  • Confidential Transactions and Native Assets
  • The Two-Way Peg and Dynamic Federation

Liquid Network Architecture and Consensus

The Liquid Network operates as a federated sidechain built upon the Elements codebase. While Elements—a fork of Bitcoin Core—provides the software foundation, Liquid is the production network implementation. Unlike Bitcoin's Proof-of-Work, which relies on competitive mining, Liquid utilizes a Federated Consensus model.
The network is maintained by fifteen globally distributed "functionaries." These entities operate specialized servers that perform two critical roles:
  1. Block Production: Functionaries take turns creating blocks in a deterministic round-robin schedule, generating a new block exactly every minute.
  2. Block Signing: For a block to be valid, it must be signed by at least 11 of the 15 functionaries.
This 11-of-15 threshold ensures the network can tolerate the failure of up to four nodes without halting. The primary advantage of this trade-off is deterministic finality. While Bitcoin deals in probabilities, Liquid achieves settlement certainty after two blocks (approximately two minutes). Once a block has a single confirmation on top of it, the chain cannot be reorganized, making it highly effective for arbitrage and rapid settlement.

Confidential Transactions and Native Assets

Liquid’s defining feature is the default use of Confidential Transactions (CT). On the Bitcoin mainchain, the sender, receiver, and amount are public. Liquid improves this by cryptographically blinding the amount and the asset type, while leaving the sender and receiver addresses visible for verification.
To ensure that a user cannot print money (e.g., by sending negative amounts), Liquid employs Pedersen Commitments and Range Proofs. These cryptographic primitives allow the network to verify that Inputs = Outputs + Fees and that all values are positive integers, without ever revealing the specific numbers to the public ledger. Only the participants holding the blinding keys can view the decrypted data.

Asset Issuance

Liquid treats all assets as "native." Whether it is Liquid Bitcoin (L-BTC), a stablecoin like USDT, or a security token, they all share the same architecture. Issuing an asset requires no smart contracts—only a simple RPC call.
  • Unregulated Assets: Can be issued permissionlessly by anyone.
  • Regulated Assets: Utilizing the Blockstream Asset Management Platform (AMP), issuers can enforce compliance rules (like KYC/AML) by requiring a second signature from an authorization server before an asset can be moved.

The Two-Way Peg and Dynamic Federation

The bridge between Bitcoin and Liquid is the Two-Way Peg. It allows users to move BTC onto the sidechain (Peg-in) and back to the mainchain (Peg-out).
The Peg-in Process: This is permissionless. A user sends BTC to a federation-controlled address. To protect against Bitcoin blockchain reorganizations, these funds must wait for 102 confirmations (approx. 17 hours) before the equivalent L-BTC is minted on the sidechain.
The Peg-out Process: To return to Bitcoin, L-BTC is burned. However, to prevent theft of the underlying Bitcoin reserves, peg-outs are not fully automated. They require authorization from a member holding a Peg-Out Authorization Key (PAK). The Bitcoin funds themselves are secured in an 11-of-15 multisignature wallet, with keys held in Hardware Security Modules (HSMs) that are air-gapped from the functionaries' main servers.
Dynamic Federation (Dynafed): To ensure longevity, Liquid employs Dynafed, a protocol that allows the network to rotate functionaries or update parameters without a hard fork. If a functionary needs to be replaced, the network broadcasts a transition transaction. After a two-week overlap period, the new configuration takes over, allowing the federation to evolve seamlessly while maintaining continuous uptime.
Quiz
Quiz1/5
What happens to the network configuration during Liquid's Dynamic Federation (Dynafed) transition process when a functionary needs to be replaced?