A software bug, not stolen keys, drained $320 million from Liquid Network

Liquid Network’s federation wallet released $320 million in Bitcoin on September 6, 2026, not because a key was stolen, but because its software was tricked into believing the withdrawal was legitimate.

Approximately 4,000 BTC was withdrawn from Liquid Network’s federation wallet, representing roughly 95% of the approximately 4,200 BTC the federation held before the incident. Liquid subsequently paused the sidechain and disabled bridge activity while its developers investigated what happened.

It was initially assumed to be another crypto hack. But a closer examination of the possible links behind the incident, some of which challenge the first account of what happened, makes the story far more uncomfortable.

Liquid said the Peg-out Authorization Key used through SideSwap was not compromised, and neither were its other federation keys. Yet the federation still released 3,996 BTC to a Bitcoin address controlled by the party behind the transaction.

This is a story about what happens when the software responsible for determining whether an asset is legitimate may itself be compromised. And that distinction could have implications far beyond Liquid.

Liquid is a Bitcoin sidechain with a simple system. Every LBTC is backed by an equal amount of Bitcoin held by the federation. Bitcoin is locked with the federation and LBTC is created on Liquid. When someone wants their Bitcoin back, the LBTC is burned and the federation releases the Bitcoin.

Liquid says there should never be more LBTC in circulation than the amount of Bitcoin held by the federation. The system also has several security measures in place. Only the authorised  can request peg outs, and 11 of the 15 federation members must approve a transaction before Bitcoin can leave the wallet.

How did an attacker get enough authority to make the federation release it?

They may have found a way to make the system believe the transaction deserved to be processed.

SideSwap, the authorised settlement platform involved in the transaction, said a customer sent approximately 4,000 L-BTC to its peg- out service at about 14:05 UTC on September 6.

SideSwap processed the order as it would a normal request while the L-BTC was burned on Liquid with a valid peg-out authorisation.

At approximately 14:28 UTC, the Liquid Federation released 3,996 BTC to the customer’s Bitcoin address, there was no stolen SideSwap key, there was no broken 11-of-15 federation signature scheme.

There was no compromise of the Bitcoin network itself.The transaction apparently passed through the machinery designed to make a legitimate redemption possible.

Blockstream later established, according to SideSwap, that the L-BTC in the order had been created through a bug in Elements, the software underlying Liquid. SideSwap said its service could not distinguish those coins from ordinary L-BTC.

If that account is correct, then the attacker did not need to steal the Bitcoin first.They needed to create the conditions under which the system would release it.

Questions to reflect on:

Who stole the Bitcoin?

Why did the system believe the Bitcoin should be released?

According to a further report, researchers are examining a possible vulnerability involving Elements confidential transaction and range-proof validation mechanisms.

Independent technical analysis has pointed to a possible range-proof cache issue that could allow validation information to be reused incorrectly across different transaction contexts, potentially resulting in L-BTC that was not properly backed by Bitcoin.

The exact vulnerability has not yet been publicly established to the standard required to declare a definitive root cause.

What is much harder to dispute is the sequence.

L-BTC was presented for redemption. The transaction passed the relevant authorisation process – The federation released real BTC- Blockstream subsequently traced the L-BTC to an Elements software bug.

That sequence points toward a software-level failure and if that is eventually confirmed, it exposes an uncomfortable weakness in the architecture.

The vault can be perfectly protected.The people holding the keys can follow the rules.The signatures can be valid.And the wrong person can still walk away with the money if the system feeding information into that decision has been deceived.

Reports indicate the actors later told Blockstream that the vulnerability should be patched and every affected node updated before most of the Bitcoin would be returned.That is potentially consistent with someone who discovered a dangerous vulnerability and wants to prevent another attacker from exploiting it.

Another problem is that a responsible security researcher normally discloses the vulnerability to the affected project and allows the project to respond.

Ledger CTO Charles Guillemet has questioned whether the behaviour fits the normal white-hat model, while acknowledging that the attackers’ attempt to communicate with Liquid also makes the situation unusual.

Here are several possibilities

The actors could genuinely be security researchers who took an extreme approach.

They could be attackers who discovered a vulnerability and later adopted the language of a white-hat operation.

They could be researchers who crossed a legal and ethical line while believing they were protecting the network.

They could know considerably more about the vulnerability than Liquid and Blockstream did when the incident began.

At this point, none of those explanations should be presented as fact but the most reasonable conclusion from the evidence available right now is not that Liquid’s cryptography failed, it is that the software surrounding the cryptography may have failed.

Liquid had the keys while the federation had the signing threshold.SideSwap had an authorised peg-out mechanism.The Bitcoin wallet was not simply opened by an intruder but the system appears to have processed a redemption that it believed was valid.

If the L-BTC involved was indeed created through an Elements vulnerability, then the failure happened somewhere between creating the asset and deciding that the asset deserved to be redeemed for real Bitcoin.

Does this L-BTC represent real BTC?

If the answer can be manipulated, then protecting the wallet alone is not enough.The keys can remain untouched while the assets they are being asked to redeem are fraudulent.

That is why I think the most important lesson from this incident is not that a $320 million crypto hack that happened but that security is only as strong as the assumptions made before a key is asked to sign.

The Bitcoin network itself was not compromised. The incident occurred within Liquid’s federated sidechain and its mechanisms for moving value between Liquid and Bitcoin.

Users interacting with Liquid are relying on a combination of software, federation members, authorised peg-out mechanisms and the processes used to validate transactions.

The September 6 incident raises a broader question for other networks built around similar assumptions:

How many systems are protecting the keys while paying less attention to the software that tells those keys when to move money?

The crypto industry has spent years making wallets harder to penetrate.

Multi-signature wallets.

Hardware security modules.

Threshold signing.

Cold storage.

Authorisation keys.

Because there is little value in requiring 11 signatures if all 11 signers are presented with information that falsely tells them the transaction is legitimate.

The lesson from the 4,000 BTC

There is an instinct in crypto to celebrate mathematics as the ultimate security boundary.

If the private key was not stolen, the cryptography worked.

If the multisig was not broken, the wallet was secure.

If the transaction was correctly signed, the system behaved as designed.

Was the thing being signed actually valid?

That is where software bugs become financially dangerous.A vulnerability does not always need to give an attacker the private key.Sometimes it only needs to convince the system that the attacker already deserves access to the money.

That is arguably what makes the Liquid incident so important as it demonstrates a form of failure that is much harder to explain in a security checklist.

Liquid and Blockstream need to establish exactly how the L-BTC involved in the transaction was created, how it passed validation, why the redemption process accepted it and whether the same weakness could affect other Elements-based systems.

They also need to establish when the vulnerability entered the software, when it was discovered, whether anyone knew about it before September 6 and whether other parties could have exploited it.

If they are genuinely white hats, the industry needs to understand why a responsible security disclosure escalated into the movement of nearly $320 million.

If they are not, then the “white-hat” message may simply be another session of the investigation.

And if the funds are returned, that will resolve the immediate financial crisis but not the architectural problem.

The bug still needs to be understood.The validation process still needs to be rebuilt.The software still needs to be independently audited.

And the industry needs to determine whether other networks relying on the same underlying technology have the same exposure.

Because the most important question coming out of Liquid is not,Where is the $320 million? But Why did the system allow $320 million in real Bitcoin to leave without anyone stealing the keys?

But if the software can be convinced that something worthless is worth billions, millions can still walk out through the front door.

And that may be the most important lesson hidden inside Liquid’s $320 million problem.