This post was originally published on this site.
On September 6, 2026, Blockstream’s Liquid Network — A Bitcoin federated sidechain — watched roughly 4,000 of the 4,200 BTC in its federation reserve walk out the door in a single, devastating peg-out. At Bitcoin’s price of around $79,750, that’s approximately $320 million, drained from the exact wallet that’s supposed to back every unit of L-BTC in circulation.
Blockstream disabled the network’s bridge nodes and paused the sidechain within hours.
The person or people responsible left a message:
“we are whitehats. contact us on chain.”
As of this writing, the funds haven’t moved since, and negotiations over returning them are reportedly underway, once a few conditions are met, aka patching the bug that allowed it to happen.
But the incident raises questions that go well beyond whether this specific actor keeps their word.
How the Vulnerability Worked
Liquid’s security model, on paper, looks robust, but until now.
The peg wallet holding Bitcoin that backs L-BTC is secured by an 11-of-15 multisig, requiring eleven of fifteen vetted federation members — exchanges and institutions known as “functionaries” — to sign off on any withdrawal.
On top of that multisig, peg-outs back to Bitcoin’s mainchain are gated by a second layer: Peg-out Authorisation Keys (PAKs), specifically designed to add friction and reduce the risk that a single compromised functionary could move funds.
Neither of those layers was actually broken.
Blockstream has attributed the incident to a software bug in Elements, the open-source codebase Liquid is built on—not to compromised keys or a phished signer.
The mechanism, based on what we know so far, was a consensus-level inflation bug via their confidential transactions validation caching on the L-BTC side of the chain, which allowed the attacker to mint more than 4,000 L-BTC that were never actually backed by real Bitcoin.
Since the sidechain’s consensus rules accepted this newly created supply as valid, the federation’s automated signing infrastructure—the HSM (hardware security module) servers that sign off on legitimate peg-out requests—had no reason to flag it.
The withdrawal request looked exactly like a normal, valid peg-out. The multisig didn’t fail.
The PAK system didn’t fail.
The layer of logic sitting above both of them, deciding what counts as a legitimate request in the first place, is what broke.
This is the detail that should concern anyone thinking about federated or bridge-based systems generally: the 11-of-15 threshold was built specifically to prevent a scenario where a handful of malicious or compromised signers move funds. It worked exactly as designed. The attacker didn’t need to compromise any signers, because the bug let them manufacture a transaction that worked under the network’s rules; an uncompromised system would sign anyway.
That said, this doesn’t bring any comfort to L-BTC holders with stuck funds, nor to Lightning users with wallets backed by L-BTC, since none of them will be able to transact. It also won’t bring confidence to exchanges or arb traders who use the network regularly to process transfers.
Questions will be asked: How could an inflation bug be sitting there ready to be exposed, with other Elements nodes all watching the network?
How the Funds Moved: SideSwap and Beyond
The specific mechanism used to extract the funds ran through SideSwap, a Liquid-native trading and peg service that holds one of the authorised Peg-out Authorisation Keys used to request withdrawals from the federation reserve.
The attacker withdrew 4,019.4 BTC from the reserve address using SideSwap’s peg-out authorisation pathway, converting freshly minted, illegitimate L-BTC into real, federation-backed Bitcoin on the mainchain. From there, the coins moved to a single on-chain address — one that has no connection to, and is not controlled by, the federation’s multisig.
That address, ending in “6gyqjlte,” is where the funds have sat since. Shortly after receiving them, the same address broadcast a second small transaction carrying the now-famous OP_RETURN message identifying the actor as a white hat and inviting Blockstream to make contact on-chain.
What This Means for Every Holder of L-BTC
This is the part of the story that should unsettle far more people than just Liquid’s federation members. L-BTC is supposed to be a 1:1 representation of real Bitcoin — every unit issued on the sidechain is meant to correspond to one real BTC locked in the federation reserve. After this exploit, the reserve backing all of that circulating L-BTC dropped from over 4,200 BTC to roughly 197 BTC. That’s not a partial shortfall. That’s the peg being, for all practical purposes, unbacked.
Crucially, this isn’t a problem limited to whoever happened to be holding funds at the moment of the exploit. Every single L-BTC in existence, held by every wallet, every exchange, every trading desk, and every application built on Liquid, is backed by the same shared reserve.
There’s no way to distinguish “safe” L-BTC from “compromised” L-BTC — it’s a fungible token, and the entire supply now rests on a reserve that’s a small fraction of what it should be.
Supporting exchanges have responded by pausing L-BTC deposits and withdrawals entirely.
Other assets issued on Liquid — including Tether’s USDT, DePix, and various tokenised real-world assets — were reportedly unaffected by this specific exploit, since they aren’t backed by the same BTC peg mechanism, but the sidechain-wide pause still disrupted their transferability in the interim.
For now, L-BTC is functionally frozen: not because anyone has decided to freeze it, but because the infrastructure that gives it meaning is broken and paused while Blockstream investigates.
The White Hat Claim
The attacker’s own framing — “we are whitehats,” followed by an offer to negotiate returning “most” of the funds once the underlying Elements vulnerability is fixed — fits a pattern that’s become familiar across major crypto exploits in 2026: an actor drains a vulnerable protocol, publicly frames the action as responsible disclosure rather than theft, and offers a partial or full return, sometimes contingent on a bug bounty or simply on the fix being deployed first.
Reporting on the negotiation suggests the actor has asked whether returning “most” of the funds to the federation address would be acceptable, with talks ongoing as of September 7.
Whether this framing should be taken at face value is a separate question from whether it’s technically true that no keys were stolen.
It’s entirely possible for someone to have found a real, serious bug, extracted an enormous sum specifically to force an urgent fix, and still intend to return it — that pattern has played out before in this space with genuine white hats.
It’s also possible for “white hat” to simply be the safest branding available to someone testing whether returning the funds minus a “reward” is more profitable, and less legally risky, than trying to launder $320 million in coins that every exchange on earth is now watching closely.
But nobody outside the attacker knows whether they’ll follow through or bluff to throw people off while they figure out how to launder the funds; either way, this person or team has the entire Liquid side chain’s fate in their hands.
Can Trust Be Rebuilt in a Trust-Based Network?
This is the deepest problem the incident exposes, and it’s structural, not incidental. Liquid was explicitly designed as a federation model — a small set of known, vetted institutions jointly custody the reserve, trading some of Bitcoin’s trust-minimised design for speed, confidentiality, and faster settlement.
That pitch has actually held up reasonably well for years: Liquid avoided the parade of catastrophic bridge hacks that hit various Ethereum-adjacent projects throughout the early 2020s, and its federation model was often held up as the more conservative, more careful alternative to algorithmic or smart-contract-based bridges.
That track record earned trust and helped scale the network to its 4000+ BTC holdings, but it also put a considerable amount of funds at risk.
This incident is the first time that specific design has failed at scale, and the way it failed matters.
Every L-BTC holder was exposed through no action of their own — no bad password, no phished seed phrase, no individual negligence anywhere in the chain. The vulnerability sat in shared protocol code that every participant depended on equally, whether they knew it or not.
That’s the nature of federated trust: you’re not just trusting the honesty of fifteen vetted institutions; you’re trusting the correctness of every line of code those institutions collectively rely on to decide what counts as a legitimate transaction.
A flaw anywhere in that logic doesn’t need a malicious signer to cause catastrophic loss — it just needs to exist.
Rebuilding trust here will likely require more than a fix and a returned sum of Bitcoin.
Blockstream will need a transparent, detailed post-mortem explaining exactly how the inflation bug worked, why it wasn’t caught in Elements’ presumably extensive review process, and what concrete changes prevent a structurally similar bug from existing in some other unreviewed corner of the same codebase.
Institutions and exchanges that route settlement volume through Liquid will be reassessing that decision in real time, and some volume will likely migrate back to Bitcoin’s base layer or toward alternative sidechains like Rootstock and Layer 2 solutions in the interim, regardless of how this specific negotiation resolves.
The uncomfortable truth for federated systems generally is that trust, once shown to rest on unreviewed shared code rather than solely on the integrity of well-known signers, has to be re-earned from a lower starting point — and that process is measured in months of transparent engineering work, not in a single returned transaction, however reassuring that backed multi-sig balance might look on-chain.
The post The Liquid Network Gets Hacked appeared first on The Bitcoin Manual.
(@Liquid_BTC)
The ~$320M abnormal peg-out from Liquid Network may not have been a key-compromise incident at all.