Deep Dive: The Liquid Peg-Out - How 3,996 Unbacked Bitcoin Cleared a 15-Member Federation

1. The Event: A Peg-Out That Passed Every Check

On September 6, 2026, about 3,996 BTC left the Liquid Federation wallet - roughly 95 percent of the bitcoin backing every L-BTC in circulation, and about $316M at the time. Within about a day, most of it was back. For anyone who moves value across chains, the recovery rate is not the part that matters. The part that matters is that the withdrawal was authorised correctly.

Nothing was stolen in the ordinary sense. No private key was compromised, no insider turned, and Bitcoin's own consensus ran untouched. What failed was the software layer that decides whether a peg-out request is legitimate before the request ever reaches the signers. Roughly 3,996 L-BTC that should never have existed were minted through a bug in Elements, the open-source codebase beneath Liquid, and then redeemed for real bitcoin through SideSwap's ordinary peg-out service.

The federation's 11-of-15 multisig behaved exactly as specified. Every one of the 83 inputs in the drain transaction carried 11 valid signatures. The transaction that moved about $316M out of the reserve paid roughly 21 cents in fees.

Liquid had the first of those three. The incident is what happens when the second and third are treated as someone else's problem.

2. Background: What a Federated Peg Promises

Liquid is a Bitcoin sidechain developed by Blockstream and built on Elements. It exists so that value can move with faster settlement and confidential amounts while remaining a claim on bitcoin rather than a separate asset. The mechanism is a two-way peg: bitcoin is locked with a federation and an equal amount of L-BTC becomes available on the sidechain; in the reverse direction, L-BTC is destroyed and bitcoin is released.

The peg-in direction is deliberately slow. A deposit needs 102 bitcoin confirmations, roughly 17 hours, which protects against deep reorganisations that could otherwise create L-BTC against a deposit that later vanished. The peg-out direction is faster - typically 11 to 35 minutes - and it requires a Peg-out Authorisation Key. Ordinary holders rarely hold one; they go through a federation member, an exchange, or a service such as SideSwap that does.

The promise the whole structure rests on is 1:1 backing: every L-BTC should correspond to bitcoin locked on the main chain, and the federation is the party that has to make that true. Custody is only half of it. The other half is the software that decides which redemption requests are real.

3. Background: The Fix That Was Merged and Never Deployed

The flaw lived in a verification cache. Liquid uses Confidential Transactions, which hide transfer amounts; each hidden-amount output carries a range proof, a zero-knowledge argument that the concealed value sits between zero and 2^64 satoshis without revealing it. Verifying those proofs is expensive, so Elements caches successful verifications instead of recomputing them on every node.

The cache key - the fingerprint used to ask whether a given proof has already been verified - was built from just two inputs: the rangeproof bytes and the value commitment. Two other inputs that determine what the proof actually means were left out: the asset generator, which specifies the token the commitment is denominated in, and the scriptPubKey, which specifies who can spend it. In the Pedersen commitments that underpin confidential amounts, the same 33-byte commitment encodes entirely different values depending on which asset generator it is applied against.

The consequence is simple once stated. A proof that had legitimately passed verification in one context could be replayed in another where it should have failed, because the cache key was identical in both cases.

The timing is the part that will be quoted for a long time. A fix was authored on August 3, 2026, merged to the Elements master branch on September 1, and cherry-picked to the elements-23.x and 23.3.x branches on September 2 and 3. The commit was titled 'Fix caching bug in rangeproof caching' and it was publicly visible on GitHub. No release tag contained it. The federation was running elements-23.3.3, released in April. The hardened release, elements-23.3.4, arrived on September 9 - three days after the drain.

Read that as a deployment problem rather than a secrecy problem. The vulnerability was not unknown when it was used. It was patched, published, and unreleased. For an operator the lesson is the distance between a merged fix and a running node - a distance measured in release engineering, not in security research.

4. The Data: The Attack, Block by Block

This was not one clever transaction; it was a priming exercise followed by a single transaction that used the primed state. The attacker seeded the cache with 68 identical range proofs over roughly fourteen hours, between Liquid blocks 4,049,384 and 4,050,246, then used that cached state in block 4,050,336 to create about 3,996 L-BTC with no bitcoin behind them.

One caveat belongs with that table. The surviving block timestamps put the exploit at about 13:53 UTC on September 6, while the federation's own incident report places it at 15:53:10 UTC - a two-hour difference that has not been reconciled publicly. SideSwap's account sits closer to the block times. Treat the sequence as settled and the minute-level timestamps as approximate.

5. The Data: What the Reserve Looked Like Afterwards

Before the incident the federation wallet held roughly 4,205 BTC. It fell to about 202-203 BTC - the on-chain reading taken one minute after the drain was 202.63 BTC. On the numbers as they stood on September 7, outstanding L-BTC was backed by roughly 4.8 percent of the reserves it was supposed to have.

The last two rows are the ones to carry away. Because the counterfeit tokens had been burned as part of the fraudulent peg-out, the claims outstanding on Liquid shrank along with the reserve, so the on-chain accounting held. Holders were not short a satoshi. The loss landed on the network - the federation and the exchanges that settle on it - rather than on user balances. That is a better outcome than most bridge failures produce, and it comes from how the peg is accounted for rather than from anyone's goodwill.

6. The Data: Eleven Signatures, Correctly Applied

It is worth being precise about what the multisig did, because the reflex conclusion - that a threshold of 15 institutions was somehow bypassed - is wrong. The federation is an 11-of-15 arrangement: 11 of 15 vetted functionaries must sign for coins to leave. Each of the drain transaction's 83 inputs carried 11 valid signatures. The keys did what they were asked to do.

A key threshold protects against key theft and against a single rogue insider. It offers no protection against software that presents a corrupted state as a valid one, and in this case the functionaries' signing software had already accepted unbacked L-BTC as legitimate before the request reached the keys. The threshold was not the weak link. The layer above it, deciding what the threshold was being asked to bless, was.

That is the structural lesson for every federated bridge, and it is the one most of the coverage has skipped while arguing about the word whitehat.

7. The Data: The Recovery, and the 598.5 BTC

The return was not unconditional. The counterparty asked for every affected node to be patched before any bitcoin moved, and Blockstream confirmed the patch in a cryptographically signed message recorded on the Bitcoin blockchain: 'The bridge nodes have been patched, it is safe to return the funds.' About 3,400 BTC came back to the federation's peg wallet at bitcoin block 965,950 - roughly 85 percent of what left, and about $270M at prevailing prices.

What did not come back is 598.5 BTC, roughly $47M, which the counterparty retained. No public statement has identified that sum as an agreed reward or a bug bounty. On September 9 the counterparty made its own position public, publishing the exploit code on-chain and demanding that Blockstream pay a ten percent bug bounty out of its own funds; Blockstream has not accepted that framing. That absence of any agreement is what keeps the white-hat question open. Genuine researchers do sometimes find a hole and hand the money back, and an 85 percent recovery is a rate most bridge exploits never approach. Ledger's chief technology officer, Charles Guillemet, put the other reading plainly: researchers do not normally drain a bridge and then ask the project to contact them, and they do not move hundreds of millions in collateral before disclosing.

The on-chain record supports neither story completely, and for an operator it does not need to. What can be used is the measurable part: the return was contingent on a patch, the network stayed paused, and $47M was retained with no contract on file.

8. The Data: The Reorg Could Not Reach the Coins

Liquid halted block production at 04:49 UTC on September 7 and, when it resumed, it resumed from the block before the exploit. The chain's own timestamps show the shape of that: the block at height 4,050,335 is still stamped 13:52:10 UTC on September 6, while the block now at height 4,050,336 carries a timestamp from late on September 9, when production quietly resumed. The exploit block and roughly fifteen hours of history were removed, and the federation's recovery plan replays the transactions it has verified as valid before peg-ins and peg-outs reopen. The resumption - blocks without user transactions - was announced on September 10.

This is the limitation every sidechain operator inherits. A reorg removes the counterfeit L-BTC from Liquid's own ledger, which is exactly what it should do. It cannot reach bitcoin that has already left on the main chain. Once the peg-out settled, the transfer was final in the only ledger that does not roll back - which is why the recovery had to be negotiated rather than undone.

9. Impact: Concentration Is the Failure Mode

The headline is that 95 percent of a network's backing went out in one transaction. The more useful framing is that fifteen independent institutions were running the same software version, and the bug was in that version. A federation count measures how many parties hold keys. It does not measure how many independent implementations stand between a bad input and a payout.

• ☐Ask which protocol version each functionary runs, and whether the versions differ.
• ☐Ask how fast a merged fix reaches production, and who signs off on the release.
• ☐Ask whether the peg-out authorisation key is held online or offline.
• ☐Ask what size, rate, velocity and destination-history checks apply to a large peg-out from a new wallet.
• ☐Ask what the rollback plan is, and how holders are treated while the network is paused.
• ☐Ask how much of a network's backing sits under a single upstream dependency.

Two specific gaps reported here are worth naming. The peg-out authorisation key was kept online, and peg-out orders faced no meaningful size, rate, velocity or wallet-history checks - so a very large order originating from a new wallet cleared automatically. Neither is a cryptographic failure. Both are policy failures that sat in the same path as the keys.

10. Impact: Where Single-Chain Settlement Carries Less of This Risk

There is a quieter implication for anyone planning routes. The Liquid incident is a failure of a claim: L-BTC is a promise about bitcoin held elsewhere, and the promise is only as strong as the machinery that issues and redeems it. A native transfer on a chain that is itself the settlement layer carries no such leg. A USDT transfer on TRON, for instance, moves a token issued directly on that chain - there is no peg-out, no federation, and no second ledger whose accounting has to hold before the transfer is real.

That does not make single-chain settlement safe in general; it moves the risk to issuance, custody and the chain's own consensus. But it removes an entire class of failure at the settlement step. The trade-off is the one this site keeps returning to: the cheapest route is not automatically the safest, and the safest route is not automatically the cheapest. What this week added is a concrete worked example of the second half of that sentence.

11. Impact: For Payment Firms and Treasury Desks

For a firm that treats a bridge as a settlement rail rather than a curiosity, three operational conclusions follow. First, counterparty review has to include software, not only entities: which version, whose release process, how quickly a published fix is deployed. Second, suspension is a live scenario rather than a tail risk - L-BTC deposits and withdrawals were suspended, Liquid paused block production, and exchanges that settle on the network, Bitfinex, BitMEX and BTSE among them, had to react. Third, the accounting model decides who absorbs a loss, and it is worth knowing before an incident which side of that line your balance sits on.

One number belongs here, because it is the week's neatest comment on fee-based risk assessment. The transaction that moved about $316M out of the federation paid roughly 21 cents in fees. The largest transfer of the week and the cheapest transfer of the week were the same transaction. Cost tells you what a rail charges. It does not tell you what a rail is worth trusting.

12. What Would Change the Read

13. Outlook: The Rest of September

The immediate calendar belongs to Liquid rather than to the market: restoring L-BTC support, returning the peg to 1:1 - a shortfall Adam Back has publicly committed to covering - and reopening peg operations without replaying anything it has not verified. Beyond that, three things are worth tracking. Whether the retained bitcoin is ever formally characterised, given the counterparty's standing ten percent demand. Whether the range-proof cache fix is deployed network-wide, since a merged fix that is not running is not a fix. And whether the incident changes how much value institutions are willing to leave sitting on a federated bridge at any one time.

The argument against reading too much into it is fair. Bitcoin itself lost nothing, holders were made whole, and 85 percent came back within about a day - outcomes most bridge incidents do not produce. But the mechanism that produced those outcomes was reserve accounting and a negotiation with the party holding the coins, not a security control that can be relied on next time.

14. Notes on the Numbers

Dollar values in this report are as reported at the time of the incident, when bitcoin traded near $79,000; the site's weekly reference price for the same week is $77,300, so figures converted at that rate would be about two percent lower. Reported totals vary slightly between sources: the peg-out transaction itself moved 3,996.0183 BTC, while the breakdown of 3,400 BTC returned plus 598.5 BTC retained sums to 3,998.5 BTC; SideSwap's post-mortem accounts for part of the gap, noting it forwarded 3,995.99999857 BTC to the counterparty and later returned its roughly four-BTC peg-out fee to the federation. Where the federation's incident report and the surviving block timestamps disagree - the exploit is placed at 13:53 UTC by block time and at 15:53:10 UTC by the report - both are reported rather than reconciled. Sources: Blockstream and SideSwap statements; The Block; Decrypt; The Hacker News; Reuters coverage; TRM Labs; and on-chain data.

15. Conclusion

The Liquid peg-out is not a story about a stolen key or a broken threshold. It is a story about a fifteen-member federation, eleven valid signatures, and a cache key that was missing two of the four inputs that decide what a proof means. The transaction settled, the multisig did its job, and 95 percent of a network's bitcoin left anyway.

For crypto transfers, the practical lesson is where to look. Bridge risk is not concentrated in the key ceremony or the signer count. It is concentrated in the code every operator runs, and in the policy that decides what a large, unexpected request is allowed to do. Those are reviewable, testable questions - and this week supplied a very expensive worked example of why they matter.