On September 6, 2026, Liquidâs federation released roughly 3,996 BTC after its network accepted L-BTC that lacked Bitcoin backing. Liquid is a Bitcoin sidechain whose L-BTC is meant to represent bitcoin held in a federation reserve. A validly authorized withdrawal turned the invalid sidechain state into a real Bitcoin payment worth about $320 million at the time. A payout limit before federation signing might have interrupted that exit.
Alpen Labs CEO Simanta Gautam now says his AI agents traced the flaw and reproduced it locally in about an hour. The work began after he heard of the September 6 attack. His September 22 account and technical report give a detailed explanation of the failed proof check. The demonstration came after the funds left, so its speed says little by itself about whether a standing AI monitor would have raised an actionable warning before the attack.
Elements, the software underlying Liquid, caches successful checks of the cryptographic proofs attached to confidential transactions. A September 1 code change tried to make each cached result depend on all the context that affects verification, including the asset generator and output script. Alpen says the change concatenated those fields as raw bytes without encoding their boundaries. A valid âseedâ proof and a different, invalid target could therefore produce identical cache input.
In Alpenâs local replay, fresh verification rejected the target, while the affected cache wrapper accepted it after the seed had populated the cache. A successful cache lookup bypassed the proof check that should have rejected the target. The two statements had the same input bytes for the cache even though they represented different verification requests. This was a local reproduction of the suspected consensus failure. Alpen says exact production validator binaries and historical cache contents were unavailable, leaving the deployed code and live priming path strongly inferred from the source and chain evidence.
SideSwap says a private security build installed on its own node in August accepted the attack transaction. That account narrows the deployment question for one operator but does not identify every federation functionaryâs build. On September 8, an Elements repair changed cache keys to encode field lengths, added collision-focused tests and introduced an option to bypass the range-proof cache. Version 23.3.4 followed on September 9. Those changes address the validation gate before invalid L-BTC can become accepted state.
The authorized exit still needed a separate check
According to SideSwapâs account, the attacker sent 4,000 L-BTC to its peg-out service at 14:05 UTC on September 6. SideSwap burned the tokens with valid authorization at 14:06. The order exceeded its own wallet funds, causing two attempted payouts to fail before federation signers released 3,996 BTC at 14:28. SideSwap says it forwarded 3,995.99999857 BTC to the customerâs address in the same Bitcoin block.
The accepted order shows why a valid key was insufficient as a safety check. SideSwap says its authorization key was online, payouts were automatic, and its service had no size, velocity, supply-relative, wallet-history or human-review checks. The federation also signed an exceptional request after the two failed attempts. A payout limit or other independent hold at the service or federation, applied before authorization or signing, could have stopped this particular payout path even after Liquid admitted invalid state.
An offline authorization key would have created a pause before SideSwap approved the peg-out. A delayed manual forward would have acted later. It could have left the Bitcoin paid by the federation under SideSwapâs control for return, but the federationâs reserve transfer would already have occurred. The precise place a safeguard acts determines which loss it can prevent.
Gautamâs one-hour result describes a retrospective investigation. The local replay demonstrates how the cache could return the wrong answer under the assessed code; it does not measure a continuous detectorâs chance of finding the defect before deployment or provide a record of the exact production cache state. A corrected validator could reject the invalid sidechain transaction. A payout limit could contain losses if another defect still reaches the bridge. The controls address different failures.
