On September 6, approximately 4,000 BTC worth around $320 million left the Liquid Network’s federation wallet.

The incident forced Liquid to pause new transactions and affected L-BTC deposits and withdrawals. Around 4,000 BTC represented roughly 95% of the approximately 4,200 BTC held in the federation wallet before the incident.

At first glance, this looks like a classic crypto hack:

Someone got into a wallet and took hundreds of millions of dollars in Bitcoin.

But that is not what the available evidence shows.

There is no indication that the federation’s signing keys were stolen. Liquid said the SideSwap Peg-out Authorization Key used in the withdrawal was not compromised, and Reuters reported the same.

So how did almost $320 million leave a wallet protected by an 11-of-15 multisig? The answer appears to begin much further upstream.

What Happened to Liquid Network?

Liquid is a federated Bitcoin sidechain operated by a set of functionaries. Its federation currently uses an 11-of-15 quorum to manage the Bitcoin peg.

Bitcoin deposited into Liquid is represented on the sidechain as L-BTC. When L-BTC is redeemed for Bitcoin, a process called a peg-out takes place.

In simplified terms:

L-BTC → burned → peg-out authorized → BTC released

According to SideSwap's account of the incident, a customer sent approximately 4,000 L-BTC to its peg-out service at around 14:05 UTC.

The request was processed normally. The L-BTC were burned with valid peg-out authorization. Around 23 minutes later, the Liquid Federation released approximately 3,996 BTC to the corresponding Bitcoin address. The important part came afterward.

Blockstream traced the L-BTC involved in the transaction to a vulnerability in Elements, the open-source software underlying Liquid, according to SideSwap's statement. SideSwap said its own systems and Peg-out Authorization Key were not compromised and that its service could not distinguish the affected L-BTC from other L-BTC.

The precise technical details of the Elements vulnerability have not yet been fully disclosed. So the safest description at this stage is:

L-BTC involved in the withdrawal were created through an Elements software vulnerability and subsequently passed through the normal peg-out process.

The Attack in Simple Terms

The easiest way to understand the incident is to follow the asset.

The critical point is that the Bitcoin withdrawal did not appear to require someone to simply steal a federation private key. Instead, the affected L-BTC reached a mechanism designed to convert L-BTC back into real Bitcoin. That distinction is what makes this incident unusual.

Why Didn't the 11-of-15 Multisig Stop It?

This is where the architecture matters. Liquid's federation protects the Bitcoin backing L-BTC with an 11-of-15 multisig wallet. Each of the 15 functionaries holds a key, stored in specialized hardware security modules.

For a normal peg-out, the federation functionaries verify that:

• the destination is an authorized address;
• the corresponding L-BTC has been burned;
• the required federation threshold signs the Bitcoin transaction.

The system therefore has strong protection against one of the most obvious attack scenarios:

An attacker steals one private key and drains the wallet.

That is not what appears to have happened here. The available evidence instead shows that the withdrawal went through the normal peg-out authorization path.

This creates a much more subtle security problem: A signing system can correctly enforce its rules while the information those rules rely on is already wrong.

The multisig can prove that enough authorized parties signed a transaction. It does not, by itself, prove that the economic state behind that transaction was created correctly.

A Simple Example

Imagine a bank with a highly secure vault. The vault has a rule:

Release $1 million when the accounting system produces a valid withdrawal certificate.

The vault has:

• multiple employees required to approve the withdrawal;
• hardware security devices;
• strict access controls;
• cameras;
• audit logs.

Now imagine that a bug in the accounting system allows someone to create a legitimate-looking certificate for $1 million that should never have existed.

The employees check the certificate. It is valid. They approve it. The vault opens. The money leaves. The vault security did not necessarily fail. The problem happened earlier:

The system created a false fact that every downstream security layer trusted.

That is the important lesson from the Liquid incident.

What Role Did SideSwap Play?

SideSwap is a service authorized to process Liquid peg-outs. In this incident, the affected L-BTC were sent to SideSwap's peg-out service.

SideSwap has stated that its service processed the request normally and that its systems could not distinguish the affected L-BTC from other L-BTC. It also said its Peg-out Authorization Key was not compromised.

That distinction is important. SideSwap did not necessarily need to be hacked for the incident to work. If an asset reaches a downstream service looking like a valid L-BTC balance, the service can process it according to the rules it was built to follow.

In other words: A downstream system may have no way to detect that an upstream assumption has already been broken.

What About the HSMs?

Liquid's federation uses Hardware Security Modules, or HSMs, to protect the cryptographic keys used by its functionaries.

HSMs are an important security layer. They help protect private keys and restrict how those keys can be used. But they are not a replacement for protocol-level validation.

An HSM can help answer: Can this key authorize the operation?

It does not necessarily answer: Was the underlying asset created correctly? or: Does the economic state of the system make sense? That distinction is crucial.

Different security mechanisms protect against different classes of failure.

Key security - Who can authorize the transaction?

Protocol security - Is the underlying state correct?

Transaction controls - Is this transaction valid according to the rules?

Risk controls - Is this transaction unusual enough to require additional review?

A system can be extremely strong in one of these areas and still have a serious weakness in another.

The Real Problem: A Broken Security Assumption

The exact technical root cause of the Elements vulnerability is still being investigated. But the incident demonstrates a broader security problem. Liquid relies on a fundamental relationship between the L-BTC circulating on the sidechain and the Bitcoin held in the federation's reserve.

In simplified terms: The amount of L-BTC redeemable for Bitcoin should correspond to the Bitcoin available to back it.

If a software vulnerability allows L-BTC to exist outside the assumptions that normally guarantee this relationship, the problem can propagate downstream.

The resulting L-BTC can potentially:

• appear legitimate;
• move through the network;
• reach a peg-out service;
• be burned;
• satisfy the conditions expected by the federation;
• and ultimately result in real Bitcoin leaving the reserve.

That is why simply describing the event as a “multisig failure” misses the interesting part. The multisig may have been doing exactly what it was designed to do. The problem was potentially that the system presented it with a transaction based on an invalid upstream state.

Why This Wasn't a Typical Wallet Hack

It is tempting to describe every large crypto loss as a wallet hack.

But there is an important difference between: Private key compromise and Protocol-level failure.

The first looks like:

Private key stolen → Unauthorized transaction → Funds drained

The Liquid incident appears closer to:

Elements vulnerability → Affected L-BTC → Valid-looking redemption → Normal peg-out process → Federation authorization → Real BTC released

Those are fundamentally different attack paths. And they require different defenses. Adding more signing keys does not necessarily fix a protocol vulnerability. Adding another HSM does not necessarily fix incorrect asset accounting. And increasing the multisig threshold does not necessarily make invalid upstream state valid.

Could This Have Been Prevented?

It is too early to say exactly which control would have prevented this incident. That will depend on the final technical post-mortem. But the incident raises obvious questions about additional safeguards around unusually large peg-outs.

For example:

• limits on individual withdrawals;
• rate limits;
• independent reserve checks;
• anomaly detection;
• additional validation of asset issuance;
• circuit breakers for extraordinary withdrawals;
• manual review for unusually large redemptions.

Consider a hypothetical situation where a system normally processes relatively small withdrawals and suddenly receives a request representing almost the entire reserve. Even if every cryptographic check passes, another question could be asked: Does this transaction make sense in the context of the system's overall state?

That is a different type of security control. It is not about whether a signature is valid. It is about whether the event itself is plausible.

What Does This Mean for Bitcoin Users?

The incident also highlights an important difference between holding native Bitcoin and using Bitcoin through a sidechain. When BTC is moved into Liquid, the user is no longer relying only on Bitcoin's base-layer rules.

The system also relies on:

• Liquid's consensus;
• Elements software;
• the federation;
• the federated peg;
• the L-BTC/BTC relationship;
• the mechanisms controlling peg-ins and peg-outs.

Liquid's own documentation describes it as a federated sidechain, with 15 functionaries and an 11-of-15 quorum managing the Bitcoin peg. That does not mean that sidechains are inherently unsafe. It means that moving an asset into another system introduces another set of assumptions and another security model.

Was Bitcoin Hacked?

No.

The Bitcoin base layer itself was not compromised. The incident occurred within the Liquid ecosystem and involved the mechanisms used to represent and redeem Bitcoin through L-BTC.

The roughly 4,000 BTC were withdrawn from Liquid's federation wallet through a peg-out process; this was not a Bitcoin protocol exploit. Reuters likewise reported that the incident affected Liquid's federation wallet rather than Bitcoin's base network.

What Happened to the Bitcoin?

After the withdrawal, the receiving address included an on-chain message: “we are whitehats. contact us on chain.”

Liquid described the actors as “purported white-hat hackers.”

That wording matters.

The actors' claim to be white-hat researchers has not been independently verified.

Liquid and Blockstream began attempting to communicate with the parties through on-chain messages. The status of the funds and whether they will ultimately be returned remains unresolved at the time of publication.

Liquid has also paused new transactions while the incident is investigated. Exchanges were asked to suspend L-BTC deposits and withdrawals, and bridge nodes were disabled.

The Bigger Security Lesson

The most interesting lesson from the Liquid incident is not that multisig is useless. It is not. It is not that HSMs are useless. They are not. And it is not that cryptography failed.

The more uncomfortable lesson is this: A security mechanism can work exactly as designed while an assumption upstream of it is wrong.

• A multisig can correctly enforce a signing threshold.
• An HSM can correctly protect a private key.
• A peg-out system can correctly process an authorized request.

And the final outcome can still be wrong if the state those systems rely on has already been corrupted.

This is one of the hardest problems in security: You can perfectly enforce a rule without proving that the assumptions behind the rule are correct.

The Liquid incident is a particularly expensive demonstration of that principle.

FAQ