CryptoSlate
Liquid’s federation released roughly 3,996 BTC worth about $320 million on September 6 after the sidechain accepted L-BTC that lacked Bitcoin backing. The failure began with a proof-validation bug in Elements, the software underlying Liquid, and ended with an authorized but exceptional peg-out through SideSwap.
Alpen Labs CEO Simanta Gautam says AI agents traced and reproduced the flaw locally in about an hour. The issue involved cached cryptographic proof checks. A September 1 change concatenated cache-key fields without encoding their boundaries, allowing a valid “seed” proof and a different invalid target to produce identical cache input. Once the valid proof primed the cache, the affected wrapper could accept the target without performing the required fresh check.
Why it matters
The incident shows how a consensus failure and weak operational controls can compound each other. SideSwap says an attacker sent 4,000 L-BTC to its peg-out service, which burned the tokens with valid authorization before federation signers released 3,996 BTC. Its automated system had no size, velocity, supply-relative, wallet-history or human-review checks.
A payout limit before authorization or federation signing could have interrupted this specific path. An offline key or delayed manual forward would have created a pause, although the federation’s reserve transfer could still have occurred before funds were returned.
Market impact
Elements’ September 8 repair encoded field lengths in cache keys, added collision-focused tests and introduced an option to bypass the range-proof cache. Version 23.3.4 followed on September 9. Liquid said ordinary transactions resumed on September 17, while peg-outs remained paused pending full one-to-one BTC backing, software updates, testing and independent reviews.
The central operational question is whether a resumed peg-out system has an independent control capable of stopping a reserve-sized authorized request before Bitcoin leaves federation custody. AI-assisted review can expose defects quickly, but the payout controls determine how much loss a future validation failure can cause.
Frequently asked questions
-
How did the Liquid proof-cache bug allow invalid L-BTC to pass?
A September 1 Elements change concatenated cache-key fields without encoding their boundaries. A valid proof and a different invalid target could produce identical cache input, allowing a cached result to bypass fresh verification.
-
How much Bitcoin did Liquid’s federation release?
The federation released roughly 3,996 BTC, worth about $320 million at the time. SideSwap says it forwarded almost the entire amount to the customer’s address.
-
What role did SideSwap’s payout process play in the exploit?
SideSwap says its automated peg-out service accepted a 4,000 L-BTC order without size, velocity, supply-relative, wallet-history or human-review checks. The federation later signed the exceptional request after two payout attempts failed.
-
Could a payout limit have stopped the Bitcoin loss?
A payout limit before authorization or federation signing could have interrupted this particular payout path. It would not have repaired the underlying consensus-validation failure.
-
What fixes did Elements and Liquid implement after the incident?
Elements encoded field lengths in cache keys, added collision-focused tests and introduced an option to bypass the range-proof cache. Version 23.3.4 followed, while Liquid kept peg-outs paused pending backing checks, software updates, testing and independent reviews.
CoinDesk
WatcherGuru
WuBlockchain