The Liquid exploit was two failures stacked, and the second one is still open. A flaw in how Elements caches cryptographic proof checks let the network accept L-BTC that had no Bitcoin behind it. A peg-out path with no independent safety check then converted that invalid state into roughly 3,996 BTC, worth about $320 million at the time, according to CryptoSlate.
The bug has been patched. The question of what should stop a reserve-sized withdrawal before federation signers release Bitcoin has not been answered publicly.
Key Takeaways
- On September 6, 2026, Liquid’s federation released roughly 3,996 BTC after the network accepted L-BTC that lacked Bitcoin backing.
- Alpen Labs says the cause was a September 1 change to Elements’ proof cache, which built cache keys from raw concatenated bytes without encoding field boundaries.
- SideSwap says its 4,000 L-BTC peg-out faced no size, velocity, supply-relative, wallet-history or human-review checks.
- Elements fixed the cache keys on September 8 and shipped version 23.3.4 on September 9. Peg-outs remained paused as of September 17.
How the cache accepted an invalid proof
The flaw sat in a performance optimisation, not in the proof system itself. Elements, the software underlying Liquid, caches successful checks of the cryptographic proofs attached to confidential transactions, so nodes don’t re-verify the same proof repeatedly. Liquid is a Bitcoin sidechain whose L-BTC is meant to represent bitcoin held in a federation reserve.
A September 1 code change tried to make each cached result depend on everything that affects verification, including the asset generator and the output script. Alpen Labs says the change joined those fields as raw bytes without encoding where one field ends and the next begins. That made it possible for two different verification requests to produce identical cache input.
In practice, a valid “seed” proof could populate the cache. A different, invalid target statement with the same input bytes would then hit that cache entry and skip the proof check that should have rejected it. In Alpen’s local replay, fresh verification rejected the target, while the affected cache wrapper accepted it once the seed was cached.
This was a consensus-level failure. Nodes running the affected code agreed that invalid state was valid, so the unbacked L-BTC was accepted by the network itself.
What the evidence does and doesn’t establish
Alpen’s account is a local reproduction of the suspected failure. The company says it did not have the exact production validator binaries or the historical cache contents. The deployed code and the live cache-priming path are therefore strongly inferred from source code and chain evidence, not directly observed.
SideSwap adds one data point on deployment. It says a private security build installed on its own node in August accepted the attack transaction. That narrows the question for one operator, but it doesn’t identify which build every federation functionary was running.
The authorized exit still needed a separate check
Accepting invalid L-BTC only created a claim. Turning it into Bitcoin required a peg-out, and the timeline SideSwap gives shows how little friction that step had.
According to SideSwap, 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 the service’s own wallet funds, so two attempted payouts failed. Federation signers then 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.
Two details stand out. SideSwap says its authorization key was online, payouts were automatic, and the service had no size, velocity, supply-relative, wallet-history or human-review checks. And the federation signed an exceptional request after the two failed attempts, so the order was not a routine one by that point.
A valid key was not a safety check. A payout limit or other independent hold at the service or the federation, applied before authorization or signing, could have stopped this particular payout path even after Liquid admitted invalid state. CryptoSlate notes, though, that the public record does not establish a tested rule that would stop an attack like this while preserving normal withdrawals.
The AI replay is a hindsight result
Alpen Labs CEO Simanta Gautam 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, and his September 22 account and technical report lay out the failed proof check in detail.
The speed is notable, but the timing limits what it proves. The demonstration came after the funds left. It says little on its own about whether a standing AI monitor would have raised an actionable warning before the attack, since diagnosing a known incident and detecting an unknown one are different problems.
The fix and the recovery
Elements moved quickly once the flaw was understood. On September 8, a 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, the point where invalid L-BTC could become accepted state.
Liquid said on September 17 that ordinary transactions had resumed while peg-outs remained paused. It said withdrawals would restart only after full one-to-one BTC backing was confirmed and required software updates, testing and independent reviews were complete.
What to Watch
The restart of peg-outs is the next checkpoint. Liquid has tied it to confirmation of full one-to-one BTC backing plus completed software updates, testing and independent reviews, but has not given a date in the reporting available.
The open question is design, not code. The cache fix closes the route that let invalid L-BTC in. What remains unanswered is whether the resumed peg will have an independent reason to stop a reserve-sized authorized request before Bitcoin leaves federation custody.
