{"id":13668,"date":"2026-09-24T13:11:57","date_gmt":"2026-09-24T13:11:57","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=13668"},"modified":"2026-09-24T13:11:57","modified_gmt":"2026-09-24T13:11:57","slug":"could-a-payout-limit-have-stopped-liquids-320m-exploit","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=13668","title":{"rendered":"Could a payout limit have stopped Liquid\u2019s $320M exploit?"},"content":{"rendered":"

<\/p>\n

\n

On September 6, 2026, Liquid\u2019s 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.<\/p>\n

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.<\/p>\n

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 \u201cseed\u201d proof and a different, invalid target could therefore produce identical cache input.<\/p>\n

In Alpen\u2019s 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.<\/p>\n

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\u2019s 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.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Tokens created out of thin air may explain how $320 million in Bitcoin left the Liquid sidechain<\/h3>\n<\/p>\n

<\/span> <\/div>\n

The authorized exit still needed a separate check<\/h2>\n

According to SideSwap\u2019s 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\u2019s address in the same Bitcoin block.<\/p>\n