Liquid Network Hack Drains $320 Million, Then Returns Most of the Bitcoin

The Liquid Network hack removed nearly 4,000 BTC from the sidechain’s federation wallet on September 6, representing about 95% of its reported reserves. The unidentified actors called themselves white hats and demanded a software fix before returning the money.

That claim initially offered little reassurance. The withdrawal had already converted apparently unbacked Liquid Bitcoin into real bitcoin through an authorized peg-out process. Liquid paused network activity, while exchanges suspended deposits and withdrawals involving its Bitcoin-backed asset.

The story then changed. The actors returned 3,400 BTC after Blockstream said affected bridge nodes had been patched. However, approximately 598.5 BTC, valued near $47 million when reported, remained under their control on September 8.

This was not a compromise of the Bitcoin network itself. It was a failure within Liquid, a federated sidechain that uses software and designated operators to connect its internal asset with Bitcoin. The distinction protects Bitcoin’s base layer from the incident, but it also exposes the central promise that Liquid must now repair.

The Liquid Network Hack Turned a Valid Withdrawal Into a Reserve Drain

The defining fact is not simply that bitcoin moved, but that Liquid’s normal redemption machinery reportedly approved the movement.

Liquid Network disclosed that approximately 4,000 BTC, then valued around $320 million, had been withdrawn from its federation wallet. Before the incident, the wallet reportedly contained about 4,200 BTC.

The withdrawal therefore removed roughly 95% of that wallet’s balance. According to the initial security incident reporting, Liquid disabled bridge nodes and coordinated with exchanges to stop L-BTC deposits and withdrawals.

Liquid Bitcoin, usually written as L-BTC or LBTC, represents bitcoin transferred onto the Liquid sidechain. Liquid’s documentation says each LBTC should be backed by an equivalent amount of BTC held by the federation.

The conversion process is called a two-way peg. A peg-in locks bitcoin and creates the corresponding LBTC. A peg-out destroys LBTC and releases bitcoin from the federation wallet.

The actors apparently attacked the accounting before the withdrawal, rather than stealing the wallet’s signing keys. SideSwap said 4,000 LBTC reached its peg-out service with valid authorization. The service burned those tokens, and the federation released about 3,996 BTC to the supplied Bitcoin address.

SideSwap said its systems and Peg-out Authorization Key were not compromised. A Peg-out Authorization Key, or PAK, restricts withdrawals to registered operators and approved destination formats.

That distinction matters because the transaction passed through expected channels. The federation did not necessarily see an obviously forged withdrawal request. Instead, it reportedly processed tokens that should never have existed without matching collateral.

The unidentified actors later placed a short message inside a Bitcoin transaction. They claimed, “we are whitehats. contact us on chain.”

Bitcoin’s OP_RETURN field allows a transaction to carry a small amount of arbitrary data. In this case, it became a public communications channel between the actors and Blockstream.

Blockstream responded with contact instructions, followed by encrypted and cryptographically signed messages. The actors then said they would return the money after every affected node received a fix.

That sequence made the Liquid Network exploit unusually visible. Anyone could inspect the transactions and messages, even while the actors’ identities and intentions remained unknown.

The drain therefore produced two simultaneous records. Liquid and SideSwap described the operational response, while Bitcoin preserved the withdrawal, later messages, and eventual partial return.

The Software Accepted Bitcoin That Was Never Deposited

The reported failure broke the relationship between LBTC supply and the bitcoin reserve without breaking the federation’s keys.

SideSwap said Blockstream traced the incident to a bug in Elements, the open-source software underlying Liquid. According to that account, the vulnerability allowed the actors to create unbacked LBTC.

That mechanism attacks the most important invariant in any asset bridge. A system must never release more of its reserve asset than users previously locked.

Liquid’s peg documentation describes a strict one-to-one model. Every LBTC should correspond to bitcoin held by the federation. Destroying one LBTC should release one BTC.

If software accepts an invalid transaction that increases the sidechain supply, that guarantee fails before the peg-out begins. The attacker can then present newly created LBTC to a legitimate withdrawal service.

The withdrawal service sees authorized tokens. It burns them as designed and asks the federation to release real bitcoin. Each component can appear to perform its assigned role, even though the system-wide result is invalid.

This is the core reversal in the Liquid Network hack. The authorization controls reportedly worked, but they authorized a claim based on corrupted supply accounting.

The federation wallet’s multisignature design did not prevent that outcome. Multisignature means several designated key holders must approve a transaction before the reserve can move.

That arrangement protects against one stolen key or one rogue signer. It does not automatically detect an upstream consensus or validation failure that presents a withdrawal as legitimate.

On-chain analysis published by Bitquery traced two small peg-ins before the large withdrawal. The researchers also identified testing activity and repeated cryptographic patterns on Liquid before the final transaction.

Their transaction reconstruction reported a 3,996 BTC federation payment at 14:28 UTC on September 6. The analysis also documented the messages exchanged after the withdrawal.

Those findings suggest preparation rather than an accidental transaction. However, the actors have not publicly identified themselves or provided a complete technical disclosure.

Some reports have connected the failure to range-proof validation. A range proof is cryptographic evidence that a confidential transaction’s hidden amount remains valid and does not create assets improperly.

Liquid uses Confidential Transactions, which conceal transferred assets and amounts while letting network nodes check transaction validity. A flaw in that checking process can be especially serious because nodes rely on proofs rather than visible amounts.

The exact root cause still requires a detailed postmortem from Blockstream. Public reporting supports the broader conclusion that unbacked LBTC entered the peg-out path, but it does not establish every technical step.

That verification gap should remain explicit. A plausible reconstruction is not the same as a complete vendor disclosure, audited patch, or independent reproduction.

Liquid Bitcoin security now depends on proving more than key integrity. Blockstream must show why nodes accepted the invalid state, which versions were affected, and how the patch blocks related variants.

Liquid’s One-to-One Promise Is Now Under Pressure

The incident pressures Liquid because its product promise depends on both cryptographic validation and the federation’s operational judgment.

Liquid is designed to offer faster settlement and greater transaction privacy than Bitcoin’s base network. It also supports assets such as stablecoins and tokenized securities.

Those features come from a separate blockchain with different trust assumptions. Bitcoin miners do not validate Liquid transactions, and Bitcoin’s consensus rules do not enforce the LBTC supply.

Instead, Liquid relies on a federation of functionaries to sign blocks and manage the two-way peg. Other federation participants can provide services, but the system’s security does not mirror Bitcoin mining.

That model is not inherently defective. Every sidechain or bridge introduces additional software, governance, and custody assumptions. Users accept those assumptions in exchange for capabilities unavailable on the base layer.

The incident exposed how those assumptions interact during failure. Liquid could pause its network, disable bridge nodes, coordinate with exchanges, distribute a patch, and negotiate with the actors.

Those actions limited further damage. They also demonstrated that Liquid’s emergency response depends on identifiable operators who can stop infrastructure and influence asset movement.

Bitcoin itself did not pause. Its miners continued processing blocks, including the transactions carrying the actors’ messages and the returned funds.

That contrast does not mean every application should run directly on Bitcoin. It means users must separate Bitcoin security from the security of assets representing bitcoin elsewhere.

Liquid’s own technical overview describes bridge nodes, functionary hardware, signing controls, and emergency recovery mechanisms. The architecture combines cryptography with institutional coordination.

The pressure now falls on Blockstream and the federation to explain how those layers failed together. Saying that no private keys were compromised answers only one part of the question.

Users also need to know why the signers released bitcoin for improperly created LBTC. Exchanges need evidence that resumed deposits cannot expose them to an unresolved supply discrepancy.

Asset issuers face a related concern. Liquid said other issued assets were not affected, but the network pause still interrupted the shared infrastructure that carries them.

An asset can remain technically intact while becoming temporarily difficult to transfer or redeem. Operational availability therefore becomes part of the security assessment.

The partial recovery improved the reserve position but did not erase the event. A system advertised as one-to-one backed briefly lost most of the bitcoin supporting that claim.

The remaining 598.5 BTC also leaves an accounting question. Blockstream must explain how the outstanding amount affects LBTC backing, liabilities, and any recovery commitment.

A returned asset does not reverse lost availability, market uncertainty, or the need for exchange controls. Nor does it prove that no related vulnerability remains elsewhere.

Liquid’s operators face both a technical audit and a credibility test. The first asks whether the bug is fixed. The second asks whether users can verify that answer independently.

A Partial Return Does Not Settle the White-Hat Question

Returning 3,400 BTC supports the actors’ stated intention, but retaining nearly 600 BTC prevents a clean white-hat conclusion.

After Blockstream said its bridge nodes had been patched, the actors transferred 3,400 BTC back to the federation address. The transaction restored approximately 85% of the withdrawn amount.

A September 8 recovery update reported that nearly $47 million in bitcoin remained outstanding. Talks concerning the balance were continuing.

The actors had previously instructed Blockstream to fix the bug first. They said every node needed the patch before they would return the funds safely.

That message aligns with one aspect of white-hat security work. Publishing or demonstrating a vulnerability before remediation can expose other users to copycat attacks.

However, conventional responsible disclosure normally starts with a private report and coordinated testing. It does not begin by removing 95% of a system’s reserve without documented authorization.

The actors’ label is therefore a claim, not a verified professional status. Liquid’s early use of “purported white-hat hackers” appropriately preserved that uncertainty.

The remaining funds sharpen the issue. No public evidence reviewed for this article establishes that Blockstream approved a 598.5 BTC bounty.

Without such approval, retaining the coins can resemble a unilateral fee, leverage for negotiations, or continued possession of misappropriated assets. The partial return alone cannot determine motive or legal responsibility.

There is also no public identity against which readers can assess experience, authorization, or past conduct. An on-chain signature proves control over an address, not the ethical character of its controller.

This ambiguity has a historical precedent. In 2021, an attacker removed more than $600 million from Poly Network and later returned most of the assets.

Poly Network called that attacker a white hat and offered a bounty. Contemporary Poly Network coverage showed how a large return could change the public narrative without eliminating legal or governance questions.

The Liquid case is not identical. The reported mechanism, assets, operators, and communications differ. Still, both incidents show how quickly “hacker” becomes “white hat” when recovery depends on cooperation.

That language can serve a practical purpose during negotiations. Publicly attacking a cooperative counterparty might reduce the chance of recovering funds.

Yet operational diplomacy should not substitute for security classification. An authorized researcher, an opportunistic exploiter, and an extortionist can all return funds for different reasons.

The useful evidence will come from the final disposition of the remaining BTC and any disclosed agreement. A complete technical report could also clarify whether the actors attempted earlier private contact.

Until then, the most accurate description remains self-identified or purported white hats. Calling the operation an approved security test would exceed the available evidence.

The Exploit Revives an Old Problem for Bitcoin Bridges

Liquid’s architecture differs from many crypto bridges, but the failure follows a familiar pattern: a false claim crossed into a reserve holding real assets.

Cross-chain systems concentrate risk because they translate activity between environments with different security rules. One system must decide whether an event on another system justifies releasing value.

For Liquid, that decision connects LBTC on the sidechain with BTC held on Bitcoin. The federation’s wallet is the reserve, while Liquid’s validation rules govern the claims against it.

The reported bug created a mismatch between those two ledgers. The sidechain accepted LBTC without corresponding bitcoin, then the peg-out process honored the false claim.

A similar economic pattern has appeared in other bridge incidents. Wormhole’s 2022 exploit allowed an attacker to create wrapped assets without the deposit that should have backed them.

Ronin’s bridge failed through a different route. Attackers gained enough validator keys to authorize withdrawals from its reserve.

These mechanisms differ technically, but they reach the same pressure point. The bridge must preserve a strict relationship between issued claims and locked collateral.

Historical data shows why that boundary receives sustained scrutiny. Chainalysis estimated that attackers stole $2 billion across 13 bridge hacks during part of 2022.

Its bridge risk analysis said those incidents represented 69% of cryptocurrency stolen that year at the time of publication. The figures describe 2022, not the current market, but the architectural lesson remains relevant.

Bridges accumulate assets in predictable locations. Their validation code and signer policies also create narrow pathways through which large reserves can move.

Liquid’s federation provides a more structured operator set than an anonymous smart-contract bridge. It can coordinate upgrades, halt services, and communicate directly with exchanges.

Those advantages helped the response. They did not stop the initial reserve drain because the reported vulnerability sat in the logic determining which transactions were valid.

This distinction should shape future audits. Testing only key custody and access controls will miss inflation, proof-validation, and state-consistency failures.

Auditors should also test the entire redemption route. That path includes asset creation, validation, authorization, burning, federation signing, and final payment on Bitcoin.

The Liquid Network exploit demonstrates why local correctness is insufficient. SideSwap says its authorization key remained safe, yet its valid service still became part of an invalid system outcome.

The federation signers also appear to have followed expected rules. The defect reportedly changed the information those rules received.

Operators therefore need controls that compare multiple sources of truth. Supply changes, peg-in history, peg-out volume, and reserve movement should reconcile before an extraordinary withdrawal completes.

A single request involving most reserves should also receive exceptional review, even if protocol rules mark it as valid. Software validity and operational plausibility are different checks.

That approach introduces friction, which Liquid was designed partly to reduce. The security tradeoff is unavoidable when faster settlement can move nearly an entire reserve through one path.

Three Signals Will Decide Whether Liquid Has Contained the Damage

The next stage depends on the outstanding bitcoin, a reproducible technical explanation, and a controlled return to normal operations.

The first signal is the remaining 598.5 BTC. A full return would strengthen the actors’ white-hat account, although it would not retroactively establish authorization.

A negotiated bounty could also resolve the balance, but only if Blockstream discloses enough information to distinguish agreement from unilateral retention. Continued silence or movement to unrelated addresses would weaken the white-hat interpretation.

The second signal is Blockstream’s technical postmortem. It should identify the vulnerable Elements versions, the failed validation rule, the affected transaction path, and the patch’s precise protection.

A useful disclosure should also explain whether independent developers reproduced the bug. Reproduction matters because a closed description leaves users dependent on the same organization whose software failed.

The report should address detection timing. Public transaction analysis suggests preparatory activity preceded the major peg-out, raising questions about monitoring and anomaly thresholds.

The third signal is Liquid’s restart process. Exchanges and users need a defined path for deposits, withdrawals, and reserve verification before routine activity resumes.

Restarting bridge nodes is not equivalent to restoring confidence. Operators must reconcile the LBTC supply with bitcoin held by the federation after the partial return.

They should also explain how the remaining shortfall is covered. That answer determines whether holders bear any residual exposure or whether another party absorbs it.

A careful restart would include version checks across functionaries and bridge nodes. It would also provide visible confirmation that outdated software cannot reconnect to the production network.

The broader Liquid Bitcoin security question will remain after services resume. The federation must show that it has added defenses against both the disclosed defect and comparable validation failures.

For developers, the lesson is to trace security guarantees across component boundaries. A protected key cannot rescue a system that authorizes the wrong transaction.

For exchanges, the lesson is to monitor collateral independently. A token’s normal appearance does not guarantee that its reserve relationship remains intact.

For asset holders, the immediate question is simpler. They should watch official service notices, reserve data, and exchange withdrawal status before treating the incident as closed.

The partial return turned a catastrophic loss into a recoverable crisis. It did not restore the one-to-one promise by itself.

The Liquid Network hack will be contained only when the remaining balance is resolved, the bug is independently understood, and normal withdrawals resume against reconciled reserves. Until those conditions are visible, “most funds returned” is an update, not an ending.