Liquid Network bug may explain $320M Bitcoin drain

Researchers digging into the roughly $320 million Liquid Network incident say they have narrowed in on a likely culprit: a failure in the software's transaction-validation cache that could let unbacked LBTC be redeemed for real BTC. The account, discussed by developers and independent analysts, suggests an attacker exploited a weakness in how Liquid caches verification of range proofs—cryptographic checks used in confidential transactions to ensure hidden amounts stay within permitted bounds. While range proofs are costly to verify, nodes store successful results for reuse. Calle said an attacker may have crafted an invalid output and proof that produced the same cache key as a previously valid check, causing a node to reuse the cached "pass" and skip the verification that should have rejected an inflationary transaction. Blockstream engineer Charles Guillemet described the same idea as a deliberate cache-key collision that allowed a confidential transaction to bypass a range check. Calle warned his description simplifies the mechanism and could include errors. A separate reconstruction by Stu points to a sequence of setup transactions culminating in an allegedly invalid transaction in Liquid block 4,050,336, which he said created about 3,996.0183 LBTC before a subsequent withdrawal via SideSwap. Liquid is a Bitcoin sidechain where LBTC is intended to be backed one-for-one by BTC held by the network's federation. As CryptoSlate previously reported, SideSwap said a customer submitted 4,000 LBTC through its peg-out service on Sept. 6, triggering the release of roughly 3,996 BTC. Liquid has said neither SideSwap's peg-out authorization key nor other federation keys were compromised, pushing attention to how the LBTC entered the withdrawal flow in the first place. Mononaut added a deployment angle that, if confirmed, would place software rollout decisions at the center of the incident. He said the exploited bug had entered Elements' master development branch the prior week but was never included in a tagged release. He also claimed Liquid federation functionaries were running that code, accepting the exploit transactions, approving withdrawals, and continuing to build blocks, while other nodes rejected the invalid transactions. That deployment claim has not been confirmed by Blockstream in available statements. The reported split would explain why some infrastructure, including mempool's Liquid explorer, could omit transactions visible elsewhere if it was following nodes that rejected the affected block. It also makes the specific software versions and validation behavior critical to any postmortem aimed at establishing what code ran, why it was deployed, and why federation nodes accepted transactions that other nodes refused. Separately, the party controlling the withdrawn Bitcoin has described itself as a whitehat and said it will return most funds once developers prove the flaw is fixed across affected nodes. Public reporting so far has not confirmed either a completed patch rollout or a full return of the funds. Recovering the BTC would address the reserve gap; demonstrating that updated software reliably rejects the exploit would address the failure that allowed reserves to leave the sidechain.