On September 6, 2026, the Liquid federation released approximately 3,996 BTC after its network processed L-BTC lacking backing from actual Bitcoin. Liquid operates as a Bitcoin sidechain where L-BTC corresponds to bitcoin held securely in a federation reserve. Because a validly authorized withdrawal converted this unbacked sidechain state into an authentic Bitcoin payout valued at roughly $320 million at the time, implementing a payout limit prior to federation signing might have successfully halted that exit.
Simanta Gautam, CEO of Alpen Labs, reported that his AI agents traced the vulnerability and successfully replicated it locally within roughly an hour. This investigation commenced after he learned of the September 6 attack. His technical report and account, published on September 22, offer a thorough breakdown of the compromised proof verification. Because this demonstration occurred after the funds had already been stolen, its rapid execution does not prove that an active AI monitoring tool would have triggered an actionable alert prior to the exploit.
Elements, the software powering Liquid, caches successful evaluations of cryptographic proofs linked to confidential transactions. A code modification introduced on September 1 attempted to make every cached outcome rely on all contextual factors influencing verification, such as the output script and asset generator. According to Alpen, this update concatenated those specific fields as raw bytes without marking their boundaries. Consequently, a legitimate “seed” proof and a distinct, fraudulent target could generate identical inputs for the cache.
During Alpen’s local simulation, a fresh verification successfully rejected the target, whereas the vulnerable cache wrapper accepted it once the cache had been populated by the seed. A successful cache lookup bypassed the proof verification that ought to have flagged the target. Despite representing entirely different validation requests, both statements shared identical cache input bytes. This served as a local recreation of the suspected consensus breakdown. Alpen noted that exact production validator binaries and historical cache contents were unavailable, meaning the deployed code and active priming path were heavily deduced from source code and blockchain evidence.
SideSwap reported that a private security build running on its personal node in August accepted the attack transaction. While this disclosure clarifies the deployment status for a single operator, it does not confirm the software version used by every federation functionary. On September 8, an Elements patch modified cache keys to properly encode field lengths, incorporated collision-focused tests, and added an option to bypass the range-proof cache. Version 23.3.4 was subsequently released on September 9. These modifications fix the validation hurdle before unbacked L-BTC can be validated as accepted network state.
The authorized exit still needed a separate check
According to SideSwap, the attacker transmitted 4,000 L-BTC to its peg-out service at 14:05 UTC on September 6. SideSwap authorized and burned the tokens correctly one minute later at 14:06. Because the order outstripped its available wallet balance, two preliminary payout attempts failed before federation signers ultimately released 3,996 BTC at 14:28. SideSwap stated that it routed 3,995.99999857 BTC to the recipient’s address within that same Bitcoin block.
This accepted order highlights why a valid key alone was inadequate as a protective measure. SideSwap noted that its authorization key remained online, payouts were processed automatically, and its platform lacked any limits regarding size, velocity, supply proportion, wallet history, or human oversight. Furthermore, the federation signed an unusual request following the two prior failures. Implementing a payout limit or another independent safety hold at the service or federation level—enforced prior to authorization or signing—could have prevented this specific withdrawal even after Liquid accepted the invalid state.
Utilizing an offline authorization key would have introduced a mandatory pause prior to SideSwap approving the peg-out. A delayed manual forwarding process would have operated further down the line. Although it could have kept the Bitcoin disbursed by the federation within SideSwap’s control for retrieval, the federation’s reserve transfer would have already taken place. Ultimately, the exact point where a safeguard operates dictates which specific losses it can successfully prevent.
Gautam’s achievement of a one-hour turnaround reflects a post-mortem analysis. While the local reproduction illustrates how the cache could yield an incorrect result under the examined code, it does not measure the probability of a continuous detection system identifying the vulnerability prior to deployment, nor does it provide an exact log of production cache states. A repaired validator can successfully reject an illegitimate sidechain transaction, whereas a payout limit can restrict damages if a separate flaw ever breaches the bridge. These distinct controls mitigate different vulnerabilities.
On September 17, Liquid announced that standard transactions had resumed while peg-outs remained temporarily suspended. The network stated that withdrawals would only be re-enabled once full one-to-one BTC backing was verified and all mandatory software patches, tests, and independent audits were finalized. The remaining operational question is whether the restored peg will incorporate an independent mechanism to halt an authorized, reserve-sized request before Bitcoin leaves the custody of the federation.
