Liquid's $320M Bug Was Bad. The 22-Minute Payout Was Worse.

TL. DR at the top. A cache collision let invalid L-BTC pass a proof check on Liquid. Then the payout plumbing did the rest. The bug is patched. The payout design isn't, and that's the part keeping me up at night.

What Actually Broke

Here's the chain of events. On September 6, 2026, roughly 3,996 BTC left Liquid's federation reserve. About $320 million at the time. The sidechain had accepted L-BTC with no bitcoin behind it.

Why? Elements, the software under Liquid, caches the results of successful cryptographic proof checks on confidential transactions. A September 1 code change tried to make those cached results depend on the full verification context, including the asset generator and the output script. Alpen Labs says the change pasted those fields together as raw bytes without encoding where one ends and the next begins.

So a valid seed proof and a completely different, invalid target could produce the same cache key. Populate the cache once with the seed, and the invalid target sails straight through. Alpen's local replay showed exactly that. Fresh verification rejected the target. The cache wrapper accepted it right after the seed primed the lookup.

That's the whole exploit. No stolen private key. No 51% attack. A boundary-less byte concatenation. If that sounds boring, good. it's. Most consensus failures are.

The One Hour Flex

Simanta Gautam, Alpen's CEO, says his AI agents traced the flaw and reproduced it locally in about an hour. His September 22 writeup and technical report walk through the failed proof check in detail.

Impressive? Sure. Also, mostly irrelevant to the question everyone's actually asking.

The demonstration came after the money moved. A one-hour reproduction speedrun tells you nothing about whether a standing monitor would've raised a workable warning before 14:05 UTC on September 6. Give Alpen credit here. They say it plainly. Exact production validator binaries and historical cache contents weren't available, so the deployed code and the live priming path are inferred from source and chain evidence.

That's a strong theory. It isn't a smoking gun. The difference matters a lot if you're deciding whether to trust a sidechain with nine figures of your capital.

Twenty-Two Minutes

SideSwap's account of the exit is the part that should scare people. At 14:05 UTC the attacker sent 4,000 L-BTC into its peg-out service. At 14:06 SideSwap burned the tokens with valid authorization. Two payout attempts failed because the order exceeded its own wallet funds. At 14:28 the federation signers released 3,996 BTC. SideSwap forwarded 3,995.99999857 BTC to the customer's address in the same bitcoin block.

Twenty-two minutes from request to signed release of roughly $320 million.

And per SideSwap, its authorization key was online, payouts were automatic, and there were no size, velocity, supply-relative, wallet-history, or human-review checks. None of them. The federation also signed an exceptional request after the two failed attempts.

So what's the point of a federation with named signers if it rubber-stamps a reserve-sized withdrawal in under half an hour? That's not a security model. That's a formality with extra steps.

The Other Side

Now the counterpoint, because there's a real one. Liquid's federation design is old. It predates most of the tooling people now take for granted. Federations trade speed for trust assumptions by definition, and a heavy payout cap has genuine costs. Stuck withdrawals. Angry market makers. Users fleeing to wrapped BTC on Ethereum where liquidity shows up instantly and nobody asks questions.

You can also argue the fix landed fast. A September 8 repair changed cache keys to encode field lengths, added collision-focused tests, and shipped an option to bypass the range-proof cache entirely. Version 23.3.4 followed on September 9. Three days from disclosure to release on a consensus-level bug is quick. I'll give them that.

And SideSwap disclosing that a private security build on its own node in August also accepted the attack transaction cuts both ways. It narrows the deployment question for one operator. It says nothing about what every federation functionary was running that day.

My Verdict

Here's my call. The cache bug is a two-day patch and it's already patched. The payout architecture is the systemic problem, and it isn't patched at all.

A corrected validator stops this specific attack. A payout limit stops the next one, whatever shape it takes. Those are different defenses against different failures, and Liquid showed it had neither engaged at the right layer. Liquid said on September 17 that ordinary transactions had resumed while peg-outs stayed paused. Withdrawals restart only after full one-to-one BTC backing is confirmed and the software updates, testing, and independent reviews wrap up.

Fine. But here's the question I want answered before anyone sends bitcoin back in. When the peg reopens, what independent mechanism stops a reserve-sized authorized request before bitcoin leaves federation custody?

Because if the answer is "the bug is fixed now," that's not an answer. That's a hope.

There's also the messy part nobody wants to say out loud. L-BTC came back trading with reserves covering roughly 85% of supply. That gap is the market pricing in exactly this doubt. Reasonable, honestly. A bridge that can lose $320 million to a byte-boundary mistake in its proof cache has to earn trust back with process, not with patch notes.

Two things can be true at once. Alpen's rapid diagnosis is genuinely useful work. And it's retrospective. The funds were already gone. A detector that finds a bug after the exploit isn't a detector. It's a very good autopsy.

That's the week. The interesting number from September 6 isn't 3,996 BTC. It's 22 minutes.