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. Contents 1. Executive Summary 2. Liquid Architecture & Security Invariants 3. Vulnerability Analysis 4. Incident Timeline 5. Mitigations, Fixes & Recovery 6. Lessons & Corrective Actions 7. Acknowledgments Section 1: Executive Summary 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. Section 2: Liquid Architecture & Security Invariants 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. A) The offline key. This is a Bitcoin extended public key (xpub) derived from the member’s cold wallet. It allows the functionary node’s HSM to verify that a peg-out destination belongs to a registered PAK entry without needing the wallet’s private keys. Peg-out proceeds go to receiving addresses derived from this key. 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. That delay gives the Federation a window to catch the problem and act, before the BTC leaves reachable custody. Section 3: Vulnerability Analysis 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-prefixed. However, the length prefix built into the rangeproof was only checked as part of rangeproof verification, which the validation cache was designed to skip. Therefore, from the perspective of the validation cache, the rangeproof functioned as an undelimited byte sequence. An attacker could therefore truncate or extend the rangeproof, adjusting the scriptPubKey to compensate, and produce a transaction with an invalid rangeproof for which the validation cache would nonetheless assert validity. Similar-looking code in Bitcoin Core, in which signature validity is cached based on the concatenation of a (variable-length) public key followed by a (variable-length) signature, is not vulnerable, because the embedded length prefixes in those objects are checked before the validation cache is invoked. In practice, the attacker used the same asset commitment and the last byte of the same destination script as an already-verified, legitimately cached transaction. That reduced the problem to a collision between the rangeproof and the rest of the cache key. The resulting byte stream – attacker's (longer proof + modified value commitment + reused asset commitment + shorter script) – was identical, byte for byte, to the original cached entry's stream, even though the underlying proof and commitment values were different. Because a cache hit skips verification entirely, the fabricated rangeproof never needed to actually verify; it only needed to produce the matching bytes. This is Bug B: a deliberately constructed byte-alignment match, made possible by the absence of length-prefixing anywhere in the hash input. No reviewer, internal or external, identified this risk prior to exploitation. Three separate checks ran, each accompanied by manual review by internal engineers, examined the relevant code between the fix's development and its exploitation. As part of Blockstream’s internal QA cycle, an AI-assisted code review confirmed the correct fields (asset commitment and scriptPubKey) were included in the cache key. This review was appropriately scoped to validate the fix against the reported vulnerability. A functional test on testnet confirmed the fix blocked cross-context reuse of a cached proof. The byte-boundary collision mode had not been identified by any party and was therefore not within the scope of testing. A supplementary, independent AI-assisted scan using a newer open-weight model available at the time through PremAI (Kimi-K3) reviewed the Elements 29.x branch as part of a broader review beyond Blockstream’s normal AI-scan cycle. Engineers also manually reviewed the scan and its findings. That code already contained the same Bug A fix that was subsequently carried into the 23.x production branch, including the same unprefixed field concatenation. The scan and accompanying human review examined code in which Bug B was already present, but the defect was not identified - a result consistent with the experience of every other reviewer, including the external researcher who originally reported Bug A. Exploit Mechanics & Propagation The attacker's transaction (txid f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f) was confirmed in Liquid block 4,050,336 at 13:53 UTC on September 6, 2026. It created a confidential output whose value was not actually backed by its inputs. This is what the rangeproof check exists to prevent. Bug B allowed it to pass validation. The transaction's cache-key fields, concatenated without length framing, produced the same byte string as an earlier, legitimately verified rangeproof cache entry. Any functionary or node holding that earlier entry treated the new proof as already verified, without running the actual check. Not every node experienced this the same way. This split reflects each node's own cache contents at that moment (which proofs it happened to have already verified and stored, not differences in which software version it was running). All 15 functionaries were on the same fixed build by this point. A cache only returns a false "valid" result if the node already holds a matching entry from an earlier, genuine verification. Nodes whose caches held that entry accepted the block. Nodes with a cold cache, or with Bug A still present, ran the real check, which failed, and rejected the block. Once the approximately 4,000 unbacked LBTC entered accepted chain state, it was indistinguishable, to every other node, from genuine LBTC. Confidential Transactions blind amounts and asset types, not addresses or the transaction graph. So while the chain can be reasonably reviewed after the fact, the anomaly could not have been flagged at the time by inspection alone. The unbacked LBTC moved into a peg-out request processed by SideSwap and was confirmed on Bitcoin at 14:28 UTC, about 36 minutes after the original transaction, and well before Blockstream was able to coordinate the halting of the bridge nodes at 18:26 UTC. All downstream transactions built on the two original invalid outputs (four traced descendants in total) were later removed from the canonical chain state during the recovery process described in Section 5, since they were either directly invalid or derived entirely from an invalid output. SideSwap PAK & the Peg-Out Control SideSwap is a Liquid Federation member holding a PAK entry, which lets it move LBTC off the sidechain to a pre-registered Bitcoin address. The SideSwap PAK itself was not compromised, forged or stolen. The peg-out completed because SideSwap's node and the Federation's functionary nodes had already accepted the unbacked LBTC as valid before the peg-out request was ever evaluated. The PAK mechanism authenticated a real signature request against LBTC that consensus had, incorrectly, already accepted as real. Following the incident, SideSwap published a statement regarding two operational choices it made in how it operated its peg-out service that had an impact on the incident. First, SideSwap acknowledged that the peg-out signing key was kept online despite the Federation Charter requiring it to be kept offline, and payouts were forwarded to the requesting customer automatically, in the same Bitcoin block as the peg-out. SideSwap stated that a delayed, manually reviewed forwarding process would have kept the released BTC recoverable. Second, SideSwap applied no size limit, velocity control, or wallet-history check to peg-out orders. An order for approximately 4,000 LBTC, a large share of outstanding supply, went through with no human review. Section 4: Incident Timeline Section 5: Mitigation, Fixes & Recovery Immediate containment (September 6, 2026). Blockstream coordinated taking the Liquid bridge nodes offline at 18:26 UTC, thereby halting further transaction confirmation, including peg-outs. Blockstream simultaneously notified exchanges to pause LBTC deposits and withdrawals. These measures contained the incident and prevented further unauthorized movement of funds. Emergency patch (September 7, 2026, 01:09 UTC). Blockstream deployed and coordinated the fix to bridge nodes ahead of the full 23.3.4 release, closing the identified vulnerability path. Root-cause fix for Bug B (merged September 8, 2026; released as v23.3.4 on September 9, 2026): Adding a length prefix to all four fields (not just the two variable-length ones) ensured that the new code remains correct regardless of surrounding context, including if currently fixed-size fields later become variable-length or if validation of their internal length prefixes changes. With CHashWriter (SER_GETHASH), every field is serialized with an explicit length marker ahead of its bytes, so no sequence of bytes can be read two different ways. No two distinct (proof, commitment, asset_commitment, scriptPubKey) inputs can now produce the same serialized stream, regardless of which fields are fixed or variable in length. The fix also adds a -norangeproofcache startup option, letting operators disable the cache entirely if they choose. This fix went through multiple rounds of internal and external review, including by outside teams, before release, consistent with the review standard Blockstream is adopting for all consensus-critical and cryptography-related changes going forward (Section 6). Chain recovery. Because the incident relied on a cache vulnerability, Blockstream was able to identify the invalid inflation by replaying and validating the affected chain without using the rangeproof cache. With caching disabled, Elements correctly rejected the transactions that depended on Bug A or Bug B rather than reusing a previously cached result. The team then independently cross-checked the results using rust-elements. This gave Blockstream a deterministic way to identify the invalid transactions and their descendants. On-chain review identified the two original invalid outputs and four descendants, providing a common, verifiable basis for the recovery reorganization. As a result, Blockstream has verified that no inflation caused by Bug A or Bug B remains on the current Liquid chain. Blockstream then carried out a staged recovery (that is still ongoing), tested in parallel: 1) Resume block production with peg-out operations paused. 2) Replay transactions independently verified as valid. 3) Resume peg operations once the network state is fully restored. Reserve accounting. The Liquid reserve was affected by unauthorized transactions and by routine peg-outs that were already in progress at the time of the incident. Of the amount attributable to the unauthorized transactions, 3,400 BTC has been returned. Approximately 602 BTC remains subject to ongoing recovery efforts. As of the most recent public update (September 17, 2026, 21:05 UTC), the recovery plan remains under active testing and is subject to revision. No stage proceeds until independently judged safe. Section 6: Lessons & Corrective Actions Blockstream received, triaged and remediated Bug A within 24 hours of first report, and confirmed it independently through two further channels within a week. No report was missed, no warning was ignored and no key was compromised. Blockstream has nonetheless undertaken a comprehensive review of its engineering and security processes. The actions below reflect that review. 1) Remediation selection for consensus-critical issues. The external researcher who first reported Bug A later submitted a second, more comprehensive fix, using length-prefixed serialization. This approach gave stronger separation between the fields being combined. It also represented a larger, more involved change, and targeted a different, non-production branch. At the time, Blockstream's internal reviewers assessed this broader change as going beyond what the reported issue required. The narrower fix was selected for the production branch based on the information available at the time. Action: When more than one remediation exists for a consensus-critical issue, the approach providing the strongest structural safety guarantees will now be the default, even if it requires a broader change. Any deviation from this default will require justification and approval. In addition, Blockstream is implementing a requirement for review by an independent security auditor before release of critical fixes affecting production consensus software. 2) Recurring review of consensus-critical code. Bug A remained in the codebase for an extended period in part because the affected code path was stable. Blockstream’s security review program, like those across the industry, focused attention on new and changing code. This same logic applied to AI scanning. Blockstream's internal scanning program runs on a fixed rotation across products. That rotation had moved to other repositories in its normal cycle before the fix was merged. However, Blockstream engineering, separate from the QA rotation, had begun exploring ad-hoc AI-scans as a supplement to the standing cadence before the incident. The independent scan described in Section 3 was run as part of this initiative. This shows that the value of supplemental scanning had been identified internally and was being acted on. Action: Consensus-critical repositories will now be reviewed on two tracks. First, any change merged into a release branch will trigger a security scan. Second, critical consensus code will undergo recurring review even when it has not recently changed. Engineering teams will also have standing resources to commission supplemental AI-scans whenever a change or finding warrants one. 3) Adversarial testing capabilities. Bug A also demonstrates that dormant defects can remain hidden until someone actively looks for ways to break an assumption. Code review, whether performed by engineers, auditors or AI systems, is only one layer of defense. During this incident response, Blockstream developed tools to search both historical chain data and the mempool for rangeproof-cache collisions, as well as a zero-cache re-verification tool that checks validation without relying on previously cached results. These tools were originally built during the incident response. They will also help detect similar conditions earlier and will be made permanent. Action: Blockstream is continuing to strengthen its internal red-team capabilities to regularly test production software using manual and AI-assisted techniques. The incident response tools developed during this period will be made permanent as appropriate. Blockstream will expand its use of fuzz testing, mutation testing, symbolic execution, and (if applicable) formal verification for consensus-critical code, alongside broader on-chain monitoring of unusual transaction activity. 4) Caching a bare verification result for a context-dependent proof is a fragile pattern on its own, separate from how the cache key happens to be built. Correct key construction closes this specific incident, but the underlying pattern (trusting a cached boolean without re-deriving its context) remains a source of risk that Blockstream identified and elected to address proactively, independent of any external report. Action: Blockstream is implementing a defense-in-depth enhancement under which context-sensitive caches of this kind will carry a versioned schema tag and a mandatory context re-check at lookup time. This second layer of defense operates independently of key construction and reflects Blockstream’s commitment to eliminating entire classes of potential issues rather than addressing only the specific instance disclosed. 5) External researchers play a valuable role in open-source security, and Blockstream is strengthening the pathways available to them. Critical open-source infrastructure benefits from researchers having a clear way to report vulnerabilities responsibly before they are exploited. While Blockstream has long maintained a security reporting channel (security@blockstream.com) and has a track record of acting promptly on reports received through it, the disclosures that led to the discovery of Bug A underscore the value of formalizing and expanding those pathways. Action: Blockstream is establishing a dedicated bug bounty program for Elements and other critical open-source infrastructure it maintains. This program will provide structured incentives, defined scope, and clear safe-harbor protections for good faith security research. Federation Governance & Operational Review The Liquid Federation Board and Blockstream are reviewing a broader set of governance, security and operational changes. This work builds on governance modernization that was already underway before the incident and had been discussed at previous Liquid Summits. The Liquid Federation will provide updates as they are formally adopted. Section 7: Acknowledgments This incident, and the response to it, involved contributions from a number of people beyond Blockstream, and we want to recognize them directly. We are grateful to stutxo, the external researcher who first reported Bug A through our security mailbox and provided the information needed to investigate it. Responsible disclosure of this kind is essential to the security of open-source infrastructure, and stutxo’s decision to report through proper channels (rather than exploit the vulnerability) reflects the highest standards of the security research community. We also thank Bitcoin Red Team, the external security team whose independent review confirmed the issue and reinforced the need to address it, while identifying several additional findings that improved the codebase. Finally, we thank the independent reviewers, such as Alpen Labs, who supported multiple rounds of scrutiny of Elements v23.3.4 before its release. A note to the individual who originally exploited the vulnerability. We recognize that you identified a flaw in the system. If your actions were motivated by a desire to expose a weakness rather than to cause lasting harm, we urge you to return the outstanding BTC. The security of the Liquid Network is strengthened when vulnerabilities are surfaced responsibly, and Blockstream is committed to ensuring that researchers and discoverers who act in good faith are recognized. We thank SideSwap for its detailed, transparent public account of its own role in this incident, including operational issues it identified and disclosed on its own initiative. That transparency improved the accuracy of this report and is directly shaping future developments. We thank the Liquid Federation and its functionary node operators for their rapid coordination during containment, patch deployment and the ongoing recovery process, and the Liquid Federation Board for its continued partnership on the governance and security review described above. Finally, we thank the broader Liquid and Bitcoin developer community for its patience, scrutiny, and continued engagement with this network through a difficult period. Blockstream remains committed to the Liquid Network's security and to the transparency this report aims to reflect. We will continue to publish technical updates as recovery progresses and as the corrective actions in Section 6 are formally adopted. For technical questions, requests or to report a security concern, contact: security@blockstream.com If you have specific preferences, please, mark the topic(s) you would like to read: