Blockstream details Liquid sidechain exploit that minted 4,000 unbacked LBTC and drained reserves

What happened

According to Blockstream's published incident assessment, an attacker exploited a flaw in the rangeproof verification cache of Elements — the open-source software that powers the Liquid sidechain — on September 6, 2026 at 13:53 UTC, at Liquid block 4,050,336. The exploit allowed a single transaction to pass validation even though its output value was not backed by its inputs, inflating the LBTC supply by roughly 4,000 LBTC with no bitcoin behind it.

The attacker then pushed the unbacked LBTC through Liquid's standard peg-out process via SideSwap, a federation member holding a Peg-out Authorization Key (PAK). That produced a withdrawal of approximately 4,000 BTC, confirmed in Bitcoin block 965,783. Blockstream says smaller peg-outs that confirmed before the network was halted brought the Liquid reserve down from about 4,205 BTC to 197 BTC.

Other assets issued on Liquid, including USDt and DePix, were unaffected, though they were unavailable while the network was paused. The attacker identified themselves on-chain within hours and, after several rounds of negotiation, returned 3,400 BTC on September 7 at 16:09 UTC (Bitcoin block 965,950). Approximately 602 BTC remains outstanding.

An eight-year-old cache bug

Blockstream attributes the theft to two enabling problems: consensus bugs in Elements that it labels Bug A and Bug B, and a gap in how one federation member's PAK signing process was configured.

Bug A, according to the report, traces back to an April 2018 commit merged through Elements PR #335 and shipped in Elements v0.14.1 on May 30, 2018. The change simplified the cache key for rangeproof verification so that it no longer included the asset commitment or the scriptPubKey; the key was computed as a SHA256 hash over only the nonce, the rangeproof and the value commitment. Since consensus rules make a rangeproof meaningful only for one exact output in one exact context — bound to the transaction's asset generator and scriptPubKey — a cached result could be reused in a context where the proof was not actually valid.

The report describes the resulting hazard: a node with a warm cache entry could accept a transaction that a node with a cold cache would reject, creating a consensus mismatch capable of splitting the chain or stalling block production. The cache-key design survived a 2019 refactor of the Confidential Assets validation code and stayed effectively unchanged until 2026.

How the peg-out safety net was meant to work

Liquid runs on Elements with its own chain parameters and a federation of 15 geographically distributed functionary nodes; blocks need signatures from at least 11 of the 15. Its peg is meant to be 1:1 — BTC locked on Bitcoin is matched by LBTC issued on Liquid, and BTC is released only against a corresponding LBTC burn. As the assessment points out, there is no separate off-chain reserve check at peg-out time; the mechanism depends entirely on the sidechain's own validated consensus state.

The PAK system was designed as a second layer of defense, with each entry holding two keys: an offline key, a Bitcoin xpub derived from the member's cold wallet that constrains where peg-out proceeds can go, and an online key that lives on a running Elements node and signs peg-out requests. The offline wallet is meant to act as a backstop — even if consensus wrongly accepts unbacked LBTC, the released BTC should land in cold storage that a person must manually move, buying the federation time to react. The report names a misconfiguration in one member's PAK signing setup as the second factor that let the attack succeed, alongside the consensus bugs.

Response and recovery

Blockstream says it coordinated a halt of the Liquid bridge nodes — the public nodes 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 assessment, which drew attention on the Hacker News front page, credits the Liquid Federation Board, functionary node operators and the broader Bitcoin development community, and notes that its findings are current as of publication and may be updated as the investigation continues.

The report also addresses why the bug lived so long, arguing that latent vulnerabilities in cryptographic and consensus code have persisted for comparable periods even in heavily audited projects, because security review naturally concentrates on new or changing code while long-stable code that has previously passed review is treated as lower risk.

Why it matters

The incident is a concrete demonstration of how a sidechain's 1:1 backed promise rests entirely on the correctness of its consensus code: one caching bug in an eight-year-old code path was enough to let real bitcoin leave the reserve, with no off-chain check to catch it. It also illustrates how performance optimizations like caching can quietly break the context-binding that cryptographic proofs depend on, and how such defects can survive audits and refactors for years. The partial recovery — 3,400 BTC returned through negotiation, with roughly 602 BTC still outstanding — shows that once funds are out, remediation depends as much on social pressure as on engineering. For operators of bridge and wrapped-token systems, the report is a detailed case study in layered defenses: the PAK cold-wallet backstop exists precisely for upstream consensus failures, and this incident shows what happens when one layer of that design is not actually enforced.