- Liquid Network Architecture and Consensus Model
- Confidential Transactions and Asset Management
- The Two-Way Peg and Security Infrastructure
Liquid Network Architecture and Consensus Model
The Liquid Network is a federated sidechain built on the Elements codebase, designed to extend Bitcoin’s capabilities while relying on its fundamental security. Unlike Bitcoin’s Proof-of-Work, Liquid operates on a Federated Consensus model. The network is maintained by a globally distributed group of members, including exchanges, trading desks, and infrastructure providers. From this membership, fifteen "functionaries" are selected to act as block signers.
These functionaries produce blocks in a deterministic round-robin fashion, with a new block generated every minute. This precise timing stands in contrast to Bitcoin’s probabilistic ten-minute intervals. For a block to be valid, it requires signatures from at least 11 of the 15 functionaries (a two-thirds plus one threshold). This mechanism provides Liquid with "two-block finality," meaning that once a transaction has two confirmations (approximately two minutes), it is mathematically impossible to reorganize the chain. This speed and certainty are critical for arbitrage, automated trading, and rapid inter-exchange settlement.
The federation is dynamic. Through the Dynamic Federation (Dynafed) protocol, the network can rotate functionaries or update parameters without requiring a hard fork. This allows the system to evolve and replace hardware or members seamlessly while maintaining continuous operation.
Confidential Transactions and Asset Management
A defining feature of Liquid is its native support for Confidential Transactions (CT) and multiple assets. On the main Bitcoin chain, all transaction details—sender, receiver, and amount—are public. In Liquid, CT uses cryptographic commitments to hide the asset type and amount from the public ledger while still allowing the network to verify that the transaction is valid (i.e., no inflation occurred). Only the participants holding the blinding keys can view the specific values, offering a level of commercial privacy essential for institutions moving large positions.
Liquid treats all assets as "native" citizens of the blockchain. This includes Liquid Bitcoin (LBTC), stablecoins like USDT, and security tokens. Issuing an asset does not require complex smart contracts; it is a basic function of the protocol.
Regulated Assets and AMP
For assets requiring compliance, such as security tokens, Liquid employs the Blockstream Asset Management Platform (AMP). This introduces a permissioned layer where transactions require a second signature from an authorization server. This allows issuers to enforce rules—such as Whitelisting or KYC requirements—on a granular level, combining the efficiency of a blockchain with the regulatory controls of traditional finance.
The Two-Way Peg and Security Infrastructure
The connection between Liquid and Bitcoin is maintained through a two-way peg. To "peg-in," a user sends Bitcoin to a generated address on the mainchain. These funds are locked for 102 confirmations (roughly 17 hours) to eliminate reorganization risks. Once confirmed, an equivalent amount of LBTC is minted on the Liquid sidechain.
The "peg-out" process enables users to redeem LBTC for Bitcoin. This requires the burning of LBTC and a cryptographic authorization from the federation. To prevent theft, peg-outs are strictly controlled by Peg-out Authorization Keys (PAKs) held by federation members. Additionally, funds can be swapped instantly via third-party providers like SideSwap, bypassing the settlement delay for faster liquidity.
Hardware Security Modules (HSMs)
Security is enforced strictly through hardware. Functionaries do not keep private keys on standard servers; instead, they operate Hardware Security Modules (HSMs). These devices are air-gapped from the logic of the host server and are programmed with strict rules. For example, an HSM will refuse to sign a block if its height is not greater than the previous one, preventing history rewrites. This "adversarial" security model assumes the host server could be compromised, ensuring the keys remain secure even if the physical location is breached.
Quiz
Quiz1/5
sid3022.1
What is the main consensus mechanism used by the Liquid Network?