Liquid Network

Imagine Anna wants to send money to Pavel. Both have wallets that support Liquid Network and want faster confirmations and private amounts. Anna is not sending an ordinary Bitcoin payment down a faster shortcut. She is using a separate network, a Sidechain, with its own history and rules. Bitcoin is represented there by Liquid Bitcoin, written L-BTC or LBTC. It is designed to represent BTC held in reserve at a ratio of 1:1, not newly mined bitcoin. Transactions are recorded in blocks that form Liquid’s own history. The network also tracks UTXO, transaction outputs that have not yet been spent: each specifies an asset, an amount and the conditions for spending it. A Bitcoin wallet therefore does not necessarily support Liquid, and the recipient must select the right network. [2] [3]

Anna can obtain L-BTC from another holder or through a service. Entering directly from Bitcoin is called a peg-in. In our example, she sends 0.1 BTC to a specially generated Bitcoin address managed by the federation, the group of Liquid operators. After 102 Bitcoin confirmations, she can claim a corresponding 0.1 L-BTC on Liquid; we leave fees aside for clarity. At an average of ten minutes per block, the wait works out to about 17 hours, but the actual time varies. The evidence consists of the original transaction and a Merkle proof, showing its inclusion in a block. Her money has not doubled: Anna can no longer spend those original BTC herself and controls L-BTC instead. Buying existing L-BTC is a different route and does not require a fresh peg-in for each buyer. [4] [9]

If Pavel needs BTC on the main Bitcoin network, the key to his L-BTC alone cannot release the reserve. A private key is secret data the wallet uses to create a digital signature authorizing the spending of the corresponding funds on Liquid. It does not give Pavel signing authority over the Bitcoin reserve. A direct return, or peg-out, is available to authorized participants with a Peg-out Authorization Key, or PAK. The corresponding L-BTC is made unspendable, commonly described as burned, and operators release BTC to an approved address. An ordinary user generally goes through such a participant, an exchange or a swap, meaning an exchange of assets. A swap need not be a direct peg-out: a counterparty can provide BTC it already holds. Service availability, fees, liquidity—the funds available for the exchange—and conditions therefore matter. The reserve ratio of 1:1 is not a promise of cost-free, immediate conversion. [5] [9]

Anna may not want everyone browsing an explorer, a website for viewing transactions, to see how much she paid Pavel. Confidential Transactions can hide both the amount and the asset being sent. Nodes, computers that verify the network’s rules, still use cryptographic proofs to check that a transaction spends no more than it has available. An authorized recipient reads the concealed details using a blinding key; this key does not, by itself, authorize spending. Some information can be shared voluntarily, for example with an accountant. Connections between transactions, timing and some other information remain public, however; peg-ins and peg-outs also leave a visible Bitcoin trail. Confidential Transactions therefore do not automatically provide anonymity or make every operation invisible. [6] [10]

Normal operation rests on the Strong Federation. Its operators have two distinct jobs: blocksigners sign blocks, while watchmen manage the reserve BTC keys and their release. This is not an open competition between miners using Proof of Work, the computational work needed to find a Bitcoin block. Decisions require a specified threshold of signatures; one operator is not normally meant to decide for everyone. Keys are also protected by an HSM, specialized security hardware that restricts what it can sign. A functioning ledger and a safe reserve are different things: a correctly confirmed payment does not prove that BTC withdrawals will always be available. Anyone can run a validating node, but doing so does not make them a reserve custodian. [2]

Under normal conditions, Liquid targets a block roughly every minute. After two confirmations, a transaction is considered final within the federation's security assumptions: signing-device rules prevent deeper rewrites of history. This is not an unconditional guarantee against every attack or failure. The 2020 whitepaper describes a configuration requiring 11 signatures out of 15, more than two thirds; that example is not a current membership list. If too few signers are available, new blocks can stop. Faster payments inside Liquid also do not eliminate the peg-in wait or processing of the return to Bitcoin. Anna should therefore not expect the entire transfer between the networks to take one minute. [1] [2]

A validating node checks Liquid's rules and transaction proofs. With peg-in validation enabled, it also checks the Bitcoin evidence through a Bitcoin node. L-BTC backing therefore need not rely solely on a number displayed on an operator's website. That does not mean Anna holds the reserve BTC keys or that the network will always be available. Block signing might stop, reserve releases might fail or security devices might be compromised. The federation's emergency recovery is not a button allowing any L-BTC holder to withdraw BTC independently. The distinction has practical consequences: keeping your own wallet can protect against the failure of an account custodian, but it does not remove reliance on the bridge between the networks. [1] [2] [9]

Besides L-BTC, people can issue other assets, such as a digital voucher or a token whose issuer promises to exchange it for other property. Each asset has an asset ID, a unique identifier; a similar name or icon does not prove it is the same asset. An issuer may also create a reissuance token, authorizing further issuance. A name registry helps identify an asset but does not establish the issuer's solvency or the enforceability of its promise. L-BTC backing rules do not automatically apply to other tokens. If Pavel accepts a digital voucher, the network can record the transfer correctly even if the issuer later fails to honor its obligation. [7] [11]

Liquid is built on Elements, open-source software derived from Bitcoin Core with support for multiple assets and confidential transactions. An advanced user can run the elementsd node software and verify the rules independently. PSET, Partially Signed Elements Transaction, carries a prepared transaction between tools: it packages the information needed for checking, concealing amounts and signing. It is not proof that a payment has already been sent. Network fees are paid in L-BTC even when transferring another asset. An ordinary wallet hides most of these details, but support for the network, asset and any signing device still needs checking. [8] [13]

Before moving a larger amount, Anna chooses a compatible wallet, checks the receiving network and establishes a specific route back to BTC, including costs. She prepares backups according to her wallet's requirements. Alongside spending keys, she needs to be able to recover the information that reveals confidential amounts. The seed is the secret source data from which the wallet derives keys. Some wallets derive blinding keys from the seed, for example under SLIP-0077; another setup may require an additional backup. There is therefore no universal requirement to export every key manually. A small round trip reveals practical problems better than simply watching a balance. Liquid can be useful for certain payments and assets when people understand the speed and confidentiality it offers, along with the conditions they accept. [9] [12]