There are a lot of explanations about what happened floating around. @mononautical seems to me to have the best grasp of it.

There's some confusion about what, exactly, was exploited here.

I've seen claims that this was a long-standing bug, exploited after the "fix" was pushed to the open source repo but before that fix could be rolled out in production.

That does not appear to be true.

Instead, it seems that the fix was deployed, but inadvertently introduced a new bug which was subsequently exploited.

Most of the network was still running official releases, none of which contain the new bug. Those nodes correctly rejected the block containing the exploit and stalled at height 4050335.

The timeline is roughly as follows:
• 2016-07-12: Range proof caching added
• 2017-11-08: Range proofs extended to support assets
• 2019-03-19: Range proof cache key "simplified", dropping asset & script fields. introduces Bug A.
• 2026-09-01: Bug A "fixed" by extending cache key to include asset + script. introduces Bug B.
• 2026-09-06: Bug B exploited, reserves drained, chain split.

The original "Bug A" allows some limited cache poisoning because the cache key doesn't commit to the asset and script, allowing a cached result for a range proof for one asset to be applied to a different asset or context.

Exploiting this in practice looks quite difficult, since the amount must match the primer and the proof must be genuine.

The 2026 "fix" added those missing fields to the cache key, producing a format like:

"proof | amount | asset | scriptpubkey"

But this unfortunately made the key easier to manipulate and exploit:

The four fields are concatenated without separators or length indicators.

Since both the proof and the scriptpubkey are variable length, an attacker can stretch the proof and shrink the script to produce the exact same cache key from different proofs, amounts, assets and scripts.

This lets an attacker smuggle arbitrary confidential output amounts and junk proofs past the range proof checker without proper validation, which breaks the guarantees that prevent hidden inflation.

On-chain evidence suggests that this second bug is what was exploited:

Two primer transactions each created an op_return with carefully constructed scriptpubkey and valid range proof for a (presumably) zero value output.

https://blockstream.info/liquid/tx/271147100a94f6337b6c3db39b30c92d5b97ed91597307b6f721f73a15187ec5

https://blockstream.info/liquid/tx/71c93d4339fe8328981a2ec0dd23808d1ff104dc4c4cbcfc5c06fb2bb622f411

This produced a cache key like:

"<valid proof> | <valid amount> | <L-BTC> | OP_RETURN <negative amount> <L-BTC> OP_RETURN"

The exploit transaction then created a large negative op_return output with an invalid range proof:

https://blockstream.info/liquid/tx/f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f

The invalid proof is padded with bytes corresponding to the primer's valid amount and asset fields, aligning the actual amount and asset fields with the same bytes from the primer's opreturn payload:

"<valid proof> <valid amount> <L-BTC> OP_RETURN | <negative amount> | <L-BTC> | OP_RETURN"

The exploit transaction could then include a second output crediting the attacker with a large positive value, balanced out by the fake negative amount.

Because the success was already cached, the invalid proof was never actually checked and the transaction was accepted as valid by nodes running versions of the software vulnerable to bug B.

Although the amounts are blinded, this is the only output with an invalid range proof anywhere in the peg-out's recent ancestry, so this must be where the inflated coins were created.

And since the padding only produces a cacheable key under the new format, it must have been the newer bug that was exploited.