PROTOCOL RESEARCH

Nobody stole a key

Liquid lost 95 percent of its Bitcoin reserve in a single authorised withdrawal. Every signature was valid, every threshold was met, and the multisig did exactly what it was built to do. That is the interesting part.

On 6 September 2026, roughly 3,996 BTC left the Liquid Federation's peg wallet in one transaction. At the prices of that week it was about $320 million, and it took the reserve backing every L-BTC in circulation from around 4,205 BTC down to roughly 197. Blockstream disabled the bridge nodes within hours, exchanges suspended L-BTC deposits and withdrawals, and the sidechain stopped producing blocks the following morning.

Almost every write-up since has led with the number. The number is the least instructive thing about it.

What actually failed

A Liquid peg-out works in two steps. The user burns L-BTC on the sidechain, and the federation's watchmen then release the matching BTC on Bitcoin, but only to an address whitelisted in a Peg-out Authorization Key entry. Spending federation funds requires a multisig threshold above two thirds, and changes to the PAK whitelist take three days to take effect. Both of those controls are there to answer one question: what happens if some of the signers go bad, or some of the keys are stolen.

Neither happened. The vulnerability sat in Elements, the open-source software Liquid nodes run, in the way those nodes cached the results of range proof verification. The effect was that invalid L-BTC was accepted as valid at the transaction level — before any peg-out was requested. By the time the withdrawal reached the federation, it was a properly formed, properly authorised request to redeem L-BTC that the network believed existed. The watchmen signed it. The threshold was met. The destination was whitelisted.

The security model held perfectly and produced a catastrophe, because it was defending the wrong layer.

The part that should generalise

Federated systems are usually assessed on the strength of the federation: who the members are, how many signatures are needed, how hard it would be to collude. Liquid scores well on all of it — the members are established firms, the threshold is high, the whitelist has a delay.

None of that helps when every member validates the same way and the validation is wrong. A two-thirds threshold across fifteen signers running one implementation is not fifteen independent checks. It is one check, performed fifteen times, by design. Signature thresholds protect against dishonest signers. They do nothing against honest signers agreeing on a false premise.

This is the same shape as a consensus bug on a single-client chain, and it is worth noting how rarely bridge and sidechain risk gets discussed in those terms. The public debate is almost entirely about custody — who holds the keys, how many, under what governance. The failure that actually occurred was one layer below, in whether the system could correctly tell what existed.

What confidentiality cost

Here is the part I have not seen stated plainly.

Liquid's headline feature is Confidential Transactions: amounts are hidden on-chain. Hiding an amount while still proving it is neither negative nor inflated requires a range proof, and verifying range proofs is expensive, which is why nodes cache the results. The bug was in that cache.

On Bitcoin, checking that a transaction does not create coins from nothing is trivial — the amounts are in the clear and you add them up. On Liquid, that same check is a cryptographic proof with a performance optimisation in front of it. The optimisation is where the supply guarantee broke.

That is not an argument against confidential transactions. It is an argument for pricing them honestly: the privacy feature and the supply-integrity surface are the same machinery. Anyone assessing a chain with confidential amounts should be asking how supply is verified, who has reviewed that code, and whether more than one implementation exists. On Liquid, the answer to the last question is no.

Where it stands

The gap between circulation and reserve is roughly 600 BTC, and Blockstream has said it will be covered rather than paid as ransom, with recovery pursued legally. Whether that holds is a solvency question with a known number attached, which is a far better position than the one the network was in on 7 September.

The operational point for anyone holding L-BTC is narrower and easier to miss: block production resuming is not redemption resuming. Until peg-outs are live, L-BTC cannot be converted back to BTC through the federation, and the market is free to price that gap however it likes. Other Liquid-issued assets, including USDT, were never affected.

What I would take from it

• Ask what the threshold is defending. Multisig counts answer one threat — dishonest or compromised signers. They say nothing about whether the thing being signed is real.
• Count implementations, not signers. Fifteen nodes running one codebase is a single point of failure wearing a governance costume.
• Treat privacy features as supply-integrity surface. Wherever amounts are hidden, something must prove they add up. That proof is now part of your risk.
• Separate liveness from redeemability. A chain producing blocks and a chain honouring withdrawals are different claims, and the first is much easier to announce.

Liquid will probably come through this. The bug is patched, most of the Bitcoin came back, and the remaining shortfall is small against Blockstream's balance sheet. But the reason it happened is not specific to Liquid, and the questions above go unasked on most of the bridges and sidechains holding client funds today.

Analysis, not investment advice. Figures reflect public reporting and the federation's own updates as of mid-September 2026 and are still moving — verify current numbers before relying on them.