# Liquid Network $320M Range-Proof Cache Exploit > A range-proof verification cache bug in Elements let an attacker mint unbacked L-BTC and peg roughly 3,996 BTC (about $320M) out of Blockstream's Liquid Network, draining 95% of the reserve. The self-described white hat returned 3,400 BTC and kept 598.5 BTC. Source: https://defimon.xyz/blog/liquid-network-hack-september-2026 · Published: 2026-09-06 · Network: Bitcoin · Impact: $320.00M --- ## TLDR On September 6, 2026, an attacker exploited a caching bug in Elements, the software that runs Blockstream's Liquid Network, to mint about 3,998.5 unbacked L-BTC and peg roughly 3,996 BTC, about $320 million, out to the Bitcoin mainchain. It is the largest crypto theft of 2026. No keys were stolen. A range-proof verification cache let a Liquid node treat an unbacked confidential output as valid, and Liquid's peg-out mechanism then released real bitcoin exactly as designed. The peg-out settled on Bitcoin at 14:28:56 UTC in block 965,783, and the reserve fell from about 4,205 BTC to 197 BTC before the network was halted. The attacker left on-chain messages claiming to be a white hat, returned 3,400 BTC, about 85%, within a day, and kept 598.5 BTC, about $47 million, as a bug bounty that Blockstream has refused to pay. ## Technical Analysis Liquid is a federated Bitcoin sidechain. Real bitcoin is locked with a federation of functionaries, and an equal amount of L-BTC is issued on Liquid against it. A peg-out burns L-BTC and releases the matching BTC to a whitelisted address. The system's solvency depends on one invariant: L-BTC can only exist if bitcoin was locked to back it. This exploit broke that invariant by making a node believe an output was valid when it was not. Liquid uses confidential transactions, so amounts are hidden behind Pedersen commitments and proven to be in a valid range by a range proof. Verifying a range proof is expensive, so Elements caches the result: once a proof verifies, its result is stored under a cache key, and a later transaction that produces the same key is accepted without re-running the cryptographic check. The bug was in how that cache key was built. In the deployed version, Elements 23.3.3, the key committed only to the range proof and the value commitment: ```cpp void ComputeEntryRangeProof(uint256& entry, const std::vector& proof, const std::vector& commitment) { CSHA256 hasher = m_salted_hasher_range_proof; hasher.Write(proof.data(), proof.size()) .Write(commitment.data(), commitment.size()) .Finalize(entry.begin()); } ``` The asset commitment and the output script were left out of the key, and the fields that were included were concatenated as raw bytes with no length prefix. Two different outputs could therefore collide to the same cache key. An attacker could get one valid proof cached, then present a second output that hashed to the same key but carried a different asset commitment and script, and the node would return the cached "valid" result without checking anything. The range proof's minimum-value check was skipped along with it, so the output could claim value that was never backed. On-chain, the setup is visible in Liquid block 4,050,335, timestamped 13:52:10 UTC. Two transactions from the attacker's Liquid address `ex1q7kgx4ptje7px48tn0nsmc6se5pngdp3smpqa2w` each carried a 67-byte `OP_RETURN` payload alongside a real confidential output, seeding node caches with the proofs the attack would reuse. The forged output that minted the unbacked L-BTC landed in the next block, 4,050,336. From there the attacker sent the L-BTC to SideSwap, a federation member that holds a peg-out authorization key. Because the validation failure happened at the transaction level, before any peg-out logic ran, SideSwap's node and the federation functionaries all accepted the L-BTC as genuine and processed the peg-out as authorized. SideSwap's whitelisted address `bc1qgslsydz56d0ed6827hdemfmk5w2f6ldyc6wt7p` received 3,996.0183 BTC in Bitcoin block 965,783 and forwarded 3,995.99999857 BTC to the attacker in the same block. This is the message verification class of [bridge exploit](/blog/bridge-exploits-explained): no signature was forged and no key was stolen, but the system was convinced a deposit existed that never did. A fix for part of this already existed. A commit on the Elements master branch on August 3 had rewritten `ComputeEntryRangeProof` to bind the cache key to the asset commitment and the script. It had not been released to production, so the deployed functionaries still ran the two-field key. Even that fix kept the raw concatenation, which is why the emergency release went further. ## Impact Assessment The peg-out drained about 95% of Liquid's bitcoin. The reserve held roughly 4,205 BTC before the incident and 197 BTC after the attacker's withdrawals, against a circulating L-BTC supply that was still fully issued. Every L-BTC in existence became a claim on a reserve that was nearly empty. USDT and other assets issued on Liquid were not touched by the bug, but they were frozen along with everything else once the network paused, because Liquid cannot process any transaction while it is halted. Bitcoin itself was never at risk. The vulnerability lived entirely in Elements, the Liquid node software, not in Bitcoin Core, and the Bitcoin mainchain processed the peg-out transaction as an ordinary payment. The damage was contained to Liquid's reserve and to the holders and market makers exposed to L-BTC. At about $80,000 per BTC, the roughly 3,996 BTC that left was worth about $320 million, which makes this the single largest crypto theft of 2026, ahead of April's KelpDAO and Drift incidents. The divergence between a peg's reserve and its circulating supply is the loudest signal in this class of exploit, and it is visible on-chain in the same block the backing disappears. On the EVM chains Defimon monitors, that unbacked-mint-and-drain signature is exactly what its [real-time feed](/) flags in under a second; Liquid sits outside that coverage, but the lesson for anyone holding a wrapped or pegged asset is the same one the [Harmony mint](/blog/harmony-hack-august-2026) taught in August: the collateral can vanish a block before the price reflects it. ## Response and Recovery The attacker moved first. At 18:30 UTC on September 6, about four hours after the peg-out, they attached a message to a Bitcoin transaction reading "we are whitehats. contact us on chain." Over the next day they sent further messages, including "Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix." Blockstream deployed a patch to the Liquid bridge nodes, completing it at 01:09 UTC on September 7. At 16:09:25 UTC that day, in Bitcoin block 965,950, the attacker returned 3,400 BTC to the federation peg wallet `bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr`, keeping 598.5 BTC. Blockstream then published Elements v23.3.4 on September 9. The release switches the range-proof and surjection-proof cache hashers from raw byte concatenation to a length-prefixed serialization, so distinct argument tuples can no longer collide to the same key, adds a distinct domain separator for each proof type, and includes a `-norangeproofcache` option to disable the cache entirely. The network was rewound to the last pre-exploit block. On-chain, Liquid block 4,050,336, which had carried the forged mint, was re-mined at 21:05 UTC on September 9 on top of the original 4,050,335, discarding the exploited branch and the invalid peg-out with it. Block production resumed on September 10, with peg-ins and peg-outs kept paused while the reserve is restored to 1:1 backing. The remaining 598.5 BTC has not come back. In a later message the attacker demanded a 10% bounty, writing that Blockstream "allocated only $1.5M (maybe even 0) to secure $5B assets" and would "cause all your holders a 15% loss" otherwise. On September 11, Blockstream refused, saying it would not pay for the return of stolen property, and Adam Back said the L-BTC to BTC peg would be covered regardless, which puts the shortfall on Blockstream rather than on L-BTC holders. ## Frequently Asked Questions ### What happened to the Liquid Network? On September 6, 2026, an attacker exploited a range-proof verification caching bug in Elements, the software Blockstream's Liquid Network runs on, to mint about 3,998.5 unbacked L-BTC and peg roughly 3,996 BTC, about $320 million, out to the Bitcoin mainchain. The reserve fell from about 4,205 BTC to 197 BTC, and the network was halted. The attacker, claiming to be a white hat, returned 3,400 BTC within a day and kept 598.5 BTC, about $47 million. It is the largest crypto theft of 2026. ### How was the Liquid Network exploited if no keys were stolen? Elements caches the result of verifying a confidential transaction's range proof, which is expensive to check. In the deployed version the cache key committed only to the proof and the value commitment, leaving out the asset commitment and the output script and concatenating the remaining fields with no length prefix. That let two different outputs collide to the same key, so after one valid proof was cached the attacker could present an unbacked output that reused the cached valid result without any check running. The peg-out mechanism then released real bitcoin against L-BTC that was never backed, working exactly as designed on inputs it had been told were valid. ### How much did the Liquid Network attacker keep? The attacker pegged out about 3,996 BTC but returned 3,400 BTC to the federation peg wallet on September 7, keeping 598.5 BTC, worth about $47 million. Blockstream refused a demanded 10% bounty and said it would cover the L-BTC to BTC peg itself, so the shortfall falls on Blockstream rather than on L-BTC holders. ### Was Bitcoin itself affected by the Liquid hack? No. The vulnerability was in Elements, the Liquid sidechain's node software, not in Bitcoin Core, and the Bitcoin mainchain processed the peg-out as an ordinary transaction. Only Liquid's bitcoin reserve and the assets issued on Liquid, including L-BTC and Liquid USDT, were affected, and those assets were frozen while the network was paused rather than lost. ### Is the Liquid Network safe to use now? Blockstream patched the bridge nodes on September 7, released Elements v23.3.4 on September 9 with a redesigned cache key that length-prefixes every field, and resumed block production on September 10. Peg-ins and peg-outs stayed paused while the reserve is restored to full 1:1 backing. Node operators must upgrade to v23.3.4 for the fix to take effect.