On September 6, 2026, the Liquid network’s federation released approximately 3,996 BTC after accepting unbacked L-BTC tokens. As a Bitcoin sidechain, Liquid uses L-BTC to represent actual bitcoin stored within a federation reserve. However, an authorized withdrawal converted this flawed sidechain state into a genuine Bitcoin transaction worth roughly $320 million at the time. Implementing a payout threshold prior to the federation’s signature could have blocked this massive withdrawal.
Simanta Gautam, CEO of Alpen Labs, stated that his team’s AI agents identified the underlying vulnerability and simulated it locally in roughly one hour. This investigation commenced after he learned of the September 6 exploit. In a detailed technical report and account published on September 22, Gautam explained the failure of the proof verification. Since this simulation occurred after the funds had already been drained, its rapid execution does not guarantee that a real-time AI monitoring system would have detected and flagged the issue prior to the exploit.
Elements, the open-source software powering Liquid, stores successful verifications of cryptographic proofs for confidential transactions in a cache. A software update on September 1 aimed to link each cached validation to its full verification context, such as the output script and asset generator. According to Alpen, this modification merged these fields as raw bytes without defining their boundaries. Consequently, a legitimate “seed” proof and an entirely different, illegitimate target proof could generate identical input data for the cache.
During Alpen’s local simulation, a clean verification correctly dismissed the invalid target proof. However, once the legitimate seed proof populated the cache, the compromised cache wrapper mistakenly accepted the invalid target. This successful cache lookup allowed the system to skip the vital proof check that should have blocked the transaction. Even though the two requests represented completely different verification tasks, they produced identical cache input bytes. This simulation successfully recreated the suspected consensus breakdown. Alpen noted that because they lacked access to the exact validator binaries and historical cache states used in production, they had to strongly infer the active code and the live priming sequence from source code and blockchain data.
According to SideSwap, a private security build deployed on its node in August accepted the malicious transaction. While this detail clarifies what happened with one specific operator, it remains unclear which software builds were running on other federation nodes. On September 8, a patch for Elements was released to resolve the issue by encoding field lengths in cache keys, introducing collision-testing procedures, and adding an option to disable the range-proof cache entirely. Version 23.3.4 was subsequently rolled out on September 9. These fixes targeted the initial validation gate to prevent invalid L-BTC from being accepted by the network state.
Authorized withdrawals lacked independent safeguards
SideSwap reported that the attacker transferred 4,000 L-BTC to its peg-out service at 14:05 UTC on September 6, and SideSwap subsequently burned the tokens with valid authorization at 14:06. Because the size of the request exceeded the service’s available wallet funds, two initial payout attempts failed. Ultimately, federation signers approved the release of 3,996 BTC at 14:28. SideSwap then routed 3,995.99999857 BTC to the user’s address within the same Bitcoin block.
This processed transaction demonstrates why relying solely on a valid authorization key was an inadequate security measure. SideSwap disclosed that its signing key was kept online, withdrawals were fully automated, and the platform operated without any transaction size limits, velocity thresholds, supply-ratio metrics, wallet history tracking, or manual oversight. Furthermore, the federation signed off on an unusual request following two failed transactions. Had there been a payout limit or an independent holding mechanism implemented by either the service or the federation before signing occurred, the funds might have been secured, even after Liquid accepted the corrupted state.
Utilizing an offline authorization key would have introduced a crucial delay before SideSwap signed off on the peg-out. Similarly, a manual forwarding process with a built-in delay could have intervened at a later stage. While this might have allowed SideSwap to retain custody of the federation-released Bitcoin and return it, the actual transfer from the federation’s reserves would have already taken place. This highlights how the specific placement of a security control dictates exactly which type of loss it can prevent.
Gautam’s rapid simulation was an after-the-fact analysis. While the local recreation illustrates how the cache could return an incorrect result under the flawed code, it does not prove that an active, continuous monitoring tool would have caught the bug before deployment, nor does it reconstruct the exact state of the production cache at the time. A patched validator is designed to reject invalid sidechain transactions entirely, whereas a payout limit acts as a safety net to limit financial damage if a different vulnerability ever compromises the bridge. These two security measures target entirely different points of failure.
On September 17, Liquid announced that standard transactions had been restored, though peg-out withdrawals remained suspended. The network stated that withdrawals would only resume once 1:1 BTC backing was verified and all necessary software patches, testing, and third-party audits were finalized. However, the outstanding operational concern is whether the reactivated peg-out system will feature autonomous mechanisms capable of halting a massive, authorized withdrawal before the assets are permanently transferred out of the federation’s custody.
