Liquid Network Security Incident Assessment

Note to readers: The information contained in this report is current as of the date of publication and may be updated as the investigation continues. Technical claims are drawn from internal and external documentation, supporting source materials and on-chain analysis. We thank the Liquid Federation Board and functionary node operators for their close coordination throughout and the broader Bitcoin development community for its scrutiny and support.

1. Executive Summary
2. Liquid Architecture & Security Invariants
3. Vulnerability Analysis
4. Incident Timeline
5. Mitigations, Fixes & Recovery
6. Lessons & Corrective Actions
7. Acknowledgments

On September 6, 2026 at 13:53 UTC (Liquid block 4,050,336), an attacker exploited a vulnerability in Elements' rangeproof verification cache, allowing a single transaction to pass validation even though its output value was not backed by its inputs. Liquid nodes, including federation functionary nodes, accepted the transaction. It inflated the LBTC supply by approximately 4,000 LBTC with no bitcoin behind it.

The attacker then moved the unbacked LBTC through Liquid's standard peg-out process, via SideSwap, a Federation member holding a Peg-out Authorization Key (PAK). This produced a withdrawal of approximately 4,000 BTC, confirmed in Bitcoin block 965,783. 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.

Liquid 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. Per the Liquid Federation Member Charter and the PAK Entry Creation Instructions, every PAK entry has two keys. Each key does a different job.

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. That delay gives the Federation a window to catch the problem and act, before the BTC leaves reachable custody.

Two distinct issues enabled the attacker to steal BTC from Liquid: (1) the consensus vulnerabilities in Elements (described below as Bug A and B); and (2) a gap in how one member’s PAK signing process was configured. Both are described in more detail below.

Bug A & B

Bug A originated in an April 2018 commit included in Elements PR #335, which was merged on May 30, 2018 in Elements v0.14.1. The change simplified the rangeproof cache key so that it no longer included the asset commitment or scriptPubKey, meaning a cached result was not bound to all of the context used to verify the rangeproof.

This was a critical consensus bug. Under the right conditions, one node could reuse a previously cached result and accept a rangeproof in a context where it was not actually valid, while another node without that cached result would reject the same transaction. Because consensus requires nodes to reach the same result when validating a block, this difference could cause the network to split, potentially disrupting or halting normal block production.

The rangeproof cache key was computed as SHA256(nonce ‖ rangeproof ‖ value_commitment), leaving out the asset commitment and scriptPubKey, even though both were part of the underlying rangeproof verification. 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. These tools can search large codebases, compare historical changes and test potential exploit paths more efficiently than traditional manual review alone. In light of this incident, Blockstream and the Liquid Network are continuing to incorporate these capabilities into their ongoing review program (see Section 6).

Bug A: Disclosure, Validation & Remediation

Three separate reviews (the external researcher’s report, Blockstream’s internal review, and a separate external engagement with the Bitcoin Red Team) reached the same root cause within five days. This gave Blockstream strong confirmation that Bug A was real and serious. Work on a fix began within a day of the first report.

The external researcher (stutxo) proposed two ways to fix the problem. The first was a direct-concatenation approach that added the missing fields to the cache key. The second was a broader approach using length-prefixed serialization, which provided stronger separation between each field.

Blockstream opened an internal fix on August 3, 2026, using the direct-concatenation approach. The immediate goal was to correct Bug A by adding the missing asset commitment and scriptPubkey to the cache key. The fix was deployed to Liquid’s bridge nodes the same day, providing immediate protection for functionaries; nearly all transactions pass through a bridge node before reaching block-producing nodes.

The fix underwent manual engineering review and a separate AI-assisted review as part of Blockstream’s standard QA process. Those reviews confirmed that the correct fields had been added, which was accurate. The byte-level combination issue that later became Bug B was a distinct and independent vulnerability class - a second-order interaction that was not flagged by any of the three independent review streams, including the external researcher’s own analysis.

The external researcher’s broader serialization fix targeted a different, non-production branch. Blockstream’s engineering team evaluated both approaches and selected the direct-concatenation method as the appropriate remediation for the reported vulnerability. The length-prefixed approach addressed a broader serialization pattern beyond the scope of the specific defect being remediated. Both approaches were reasonable engineering choices for the reported issue. The byte-boundary vulnerability that later surfaced as Bug B was a separate defect that was not identified by any reviewer at the time.

Testing and review continued in parallel. Starting August 4, Blockstream deployed additional third-party AI-assisted review capacity to scan Elements branches beyond its normal QA cycle, with the results also reviewed manually by engineers. That work reached a non-production branch first, but that branch already contained the same direct-concatenation approach used in the fix that later shipped to production. The byte-boundary defect (Bug B) was already latent in the code being reviewed, and neither the AI scan nor the accompanying human review identified it - consistent with the fact that no reviewer, internal or external, identified this vulnerability class at that time.

On August 5, Blockstream separately tested the fix on Liquid testnet using a cache-poisoning transaction designed to reproduce Bug A. The fix correctly rejected the attack and resolved the warm/cold cache consensus split caused by Bug A. The test was designed to validate the fix against the known vulnerability. The byte-boundary collision mode that constituted Bug B had not been identified by any party and was therefore not within the scope of testing.

Deployment continued as these checks were completed. By August 11, 13 of 15 functionary nodes were running the update, with the remaining nodes following shortly afterward.

Blockstream made the fix public in the Elements repository on September 1, 2026. On September 3, all internal items tracking the external reports and their remediation, including this fix, were marked resolved.

Bug B: Root Cause & Pre-Deployment Review

The fix that closed Bug A extended the cache key to include the asset commitment and scriptPubKey. The defect lay not in which fields were added, but how they were combined:

This writes each field's raw bytes into the hash sequentially, without length prefixing or separators. This is Bug B.

Two of these fields, the value commitment and the asset commitment, are fixed at 33 bytes each. The other two, the rangeproof and the scriptPubKey, vary in length. The rangeproof has an embedded header which encodes its length, while the scriptPubKey was encoded as the final field and therefore did not require a length prefix as long as all other fields were length-