Liquid Network Security Incident Assessment

Smaller peg-outs confirmed before the network was halted brought the Liquid reserve down from about 4,205 BTC to 197 BTC.All other Liquid-issued assets (USDt, DePix, and other tokenized assets) were unaffected by the incident, though they were unavailable while the network was paused.The attacker identified themselves on-chain within hours of the incident and returned 3,400 BTC (September 7, 16:09 UTC, Bitcoin block 965,950) after several rounds of negotiations.

Approximately 602 BTC remain outstanding.Blockstream coordinated a halt of the Liquid bridge nodes (public nodes that users connect to) shortly after the attack, deployed an emergency interim patch within hours, and shipped a fully reviewed hardening release, Elements v23.3.4, within days.The purpose of this report is to outline what happened, and how Blockstream and the Liquid Network responded to this unprecedented attack.

Section 2: Liquid Architecture & Security InvariantsLiquid is a production Bitcoin sidechain built on Elements, an open-source blockchain platform developed by Blockstream. Liquid runs Elements Core with its own chain parameters, consensus configuration, and active federation, and is operated by 15 geographically distributed functionary nodes. Blocks require signatures from at least 11 of the 15 functionary nodes to be accepted by the network.Three architectural properties are especially important to understanding the September 6 security incident and its impact:1) 1:1 BTC backing. BTC locked on the Bitcoin chain via peg-in is matched 1:1 by LBTC issued on Liquid. BTC is only released on peg-out against a corresponding LBTC burn. This depends entirely on consensus validating correctly that no LBTC can be created without a matching and provably valid transaction. There is no separate, off-chain reserve check at peg-out time; the peg-out mechanism relies on the sidechain's own validated state.2) Confidential Transactions and rangeproof verification.

Liquid blinds transaction amounts and asset types using Pedersen commitments. A zero-knowledge rangeproof attached to each confidential output proves the committed value is in a valid range, without revealing it, and a surjection proof ties the output's asset generator back to a valid input asset. On its own, a rangeproof only proves a value is in range. Consensus rules combine it with the transaction's asset generator and scriptPubKey, so the proof is only meaningful for that exact output, in that exact place. Elements caches the results of these expensive checks to avoid re-verifying identical proofs across mempool and block validation.3) PAK-based peg-out authorization.

The Charter instructs members to "keep the bitcoin receiving wallet offline and secure." This keeps the bitcoin backing LBTC safe, even if an attacker gets past other defenses.B) The online key. This is a secp256k1 key. Its private half lives on a running Elements node, in the node's peg-out wallet. It stays online, because it signs peg-out requests.In other words, the PAK authorization does two things: it controls where BTC can go (offline key), and it controls who can ask for BTC to be sent (online key).The offline key exists as a safety net for upstream failures.

If, for example, consensus validation accepts bad LBTC by mistake, a genuinely offline receiving wallet still holds the released BTC afterward. Someone must manually retrieve the funds from cold storage and move them. This takes time.

As a result, once a (rangeproof, value commitment) pair had been successfully cached, the node could treat the same pair as already valid when presented with a different asset commitment or script, without running the rangeproof verification again. A node with that cache entry could therefore accept a transaction that a node with a cold cache would reject, creating a consensus mismatch that could split the chain or stall block production.

The defect was introduced in 2018, and the underlying cache-key design was carried into the later Confidential Assets validation implementation during a 2019 refactor. After that, the relevant behavior remained essentially unchanged until 2026.The subtlety and deeply embedded nature of this class of defect is well recognized in the industry. Across the broader blockchain ecosystem, latent vulnerabilities in cryptographic and consensus code have persisted undetected for comparable periods even in heavily audited projects. Security review, by its nature, focuses most closely on new or changing code.

Stable, long-running code that has passed prior review and operated without incident occupies a lower-risk tier in standard audit frameworks - a prioritization approach consistent with widely accepted software security practices.The emergence of AI-assisted analysis tools has begun to shift the landscape for reviewing legacy codebases.