TheBlockRadar
Trend· Independently researched

Liquid Network Bitcoin Theft

Explore the Liquid Network Bitcoin theft, partial recovery, and the security flaws behind the $320M exploit affecting federated sidechains.

Liquid Network Bitcoin Theft

Liquid Network’s Bitcoin Theft Shows the Cost of Federated Bridge Risk

The shift is from key theft to validation failure

The immediate story has changed from a $320 million Bitcoin drain to an incomplete recovery. Attackers returned 3,400 BTC after Blockstream said affected bridge nodes had been patched, leaving roughly 598 BTC under the attacker’s control. [3][4]

The risk is that the recovery can obscure the original failure. Liquid’s multisignature keys were reportedly not stolen, yet valid federation signatures released Bitcoin against L-BTC that should not have existed, exposing a software and governance weakness rather than a simple custody breach. [5][6]

That distinction matters for infrastructure operators. Multisignature custody is often presented as a hard boundary around bridge reserves, but it cannot prevent losses if the systems deciding whether a withdrawal is legitimate accept invalid state.

Liquid Network is a Bitcoin sidechain operated by a federation of participating companies. Its L-BTC token is intended to be backed one-for-one by Bitcoin held in a federation wallet, allowing faster and more confidential transfers than the main Bitcoin chain. [5][10]

On Sept. 6, roughly 4,000 BTC left that reserve through the Liquid peg-out process. The withdrawal reduced the wallet to about 197 BTC while thousands of L-BTC remained outstanding, creating an immediate backing shortfall. [5][6]

Multiple records confirm the return, not a complete resolution

The partial recovery is not merely a claim from Liquid’s operators. Bitcoin Magazine reported that a transaction confirmed on Sept. 7 returned exactly 3,400 BTC to a labeled Liquid peg script, while approximately 598.5 BTC returned as change to the attacker-controlled address. [2]

Blockhead and CryptoBriefing also reported that the funds moved only after Blockstream communicated that bridge nodes had been patched. The sequence is important because it shows the return was conditional on the attacker’s assessment of the technical fix. [3][4]

The discussions were unusually visible. Messages embedded in Bitcoin transactions asked Liquid’s operators to establish on-chain contact, requested confirmation that the bug was fixed, and preceded the eventual 3,400 BTC transfer. [2]

That transparency has limits. On-chain messages can establish that addresses communicated and coins moved, but they do not establish the identity, jurisdiction, intent or legal status of the party calling itself a white-hat.

Nor do the messages establish a contractual bounty. Bitcoin Magazine described the 598.5 BTC retention as an implied finder’s fee, but Blockstream and Liquid Network have not disclosed a formal compensation agreement or accepted that characterization publicly. [2]

At Bitcoin’s approximate Sept. 8 price of $78,449, the unrecovered balance was worth about $47 million. That amount is too large to treat as an incidental disclosure reward, even if the attackers ultimately return it. [1]

“White-hat” is a description under dispute

Calling an attacker a white-hat can be analytically convenient because most of the Bitcoin was returned. It is not, however, a settled legal or ethical classification when nearly 15% of the proceeds remain retained without a disclosed agreement. [2][3]

Responsible vulnerability disclosure normally involves reporting a flaw before exploiting it against live reserves, coordinating a remediation process, and agreeing on any reward. Here, the funds were first removed from the federation wallet, then used as leverage in negotiations.

Some observers have described the retained BTC as a bounty. Others have argued that retaining funds after an unauthorized withdrawal looks closer to extortion, particularly when the amount is measured in tens of millions of dollars.

The available evidence does not settle that dispute. It also does not identify the attackers, reveal the content of encrypted negotiations, or show whether any regulator or law-enforcement authority has intervened.

For market participants, the practical point is simpler than the terminology. Until the 598 BTC is returned, recovered through a legal process, or otherwise accounted for, Liquid’s reserve restoration remains incomplete.

What appears to have failed

Liquid’s federation wallet uses an 11-of-15 multisignature arrangement, with functionary keys held in hardware security modules. The reported exploit did not compromise those keys or bypass the wallet through a stolen-signature attack. [10]

Instead, reporting and technical analysis point to a validation failure that enabled invalid or unbacked L-BTC to enter the peg-out process. Those tokens could then be redeemed through an apparently authorized withdrawal route. [5][6]

CertiK’s incident analysis described the event as a failure involving Liquid’s transaction validation and peg-out architecture. The attacker was able to obtain real BTC after transactions that certain nodes should have rejected were accepted by the relevant federation infrastructure. [6]

A more specific technical explanation has focused on validation caching for confidential transactions. Liquid uses cryptographic range proofs to verify hidden amounts, and a cache-related flaw may have allowed an invalid proof to avoid the check that should have rejected inflationary token creation. [6]

That explanation should still be treated as provisional. Public reporting has identified a plausible mechanism, but Blockstream has not published a full technical postmortem detailing the exact bug, the complete patch, or the sequence of production failures.

The deployment question is equally material. Reports suggested that federation functionaries may have run code from Elements’ development branch that had not appeared in a tagged release, while other nodes rejected the disputed transaction. [6]

If confirmed, that would make the issue larger than a single coding error. It would raise questions about release management, independent validation, change-control procedures, and the authority of federation nodes when their view of valid chain state diverges.

A chain split turned monitoring into a control issue

Liquid’s incident also demonstrated why public dashboards and independent observers matter. Mempool.space’s Liquid monitoring showed the reserve loss, while the official Liquid dashboard did not immediately reflect the same reduction in backing. [5]

That gap was not cosmetic. A reserve-backed asset depends on users, exchanges and issuers being able to verify both the liabilities, outstanding L-BTC, and the Bitcoin reserves supposed to support them.

When different nodes accept different blocks, the bridge’s nominal multisig threshold becomes less reassuring. Eleven valid signatures can still authorize a harmful withdrawal if the signers are operating from a state view that has accepted invalid token issuance.

Liquid paused the sidechain, disabled bridge nodes and asked exchanges to suspend L-BTC deposits and withdrawals after the exploit. Reports indicated that other issued assets, including USDT on Liquid, were not directly affected by the withdrawal mechanism. [5]

That is a narrower outcome than a complete loss of the network’s assets, but it does not eliminate disruption. Exchanges and users still face an inactive peg, uncertain settlement availability, and reputational damage around an asset designed to track Bitcoin one-for-one.

Why this is happening now

The strongest explanation is not that attackers suddenly discovered multisignature wallets are vulnerable. Rather, the incident illustrates a familiar infrastructure problem: complex systems fail at the boundary between code validation, deployment practices and operational authority.

Confidential transactions, federated signing and peg-out authorization are each defensible design tools. Combining them adds dependencies, and a failure in one validation layer can move risk into another layer that users may assume is independent.

The timing also matters because bridge infrastructure now handles larger pools of collateral and more institutional-style assets. A flaw that might once have affected a small experimental reserve can now freeze exchange operations and create a material reserve mismatch.

Still, evidence for a wider trend should not be overstated. This is one major Liquid incident, not proof that every federated sidechain is running unreviewed development code or can be drained through the same range-proof validation issue.

The more defensible trend is in scrutiny. Independent block explorers, technical researchers and industry publications rapidly compared reserve balances, transaction history and node behavior, rather than relying solely on a project’s initial incident statement. [2][5][6]

That kind of monitoring is becoming a basic market requirement. For wrapped, bridged or federated assets, users increasingly need evidence of reserves and validation health that remains visible when an operator’s own dashboard is delayed or disputed.

What project teams should take from Liquid’s response

A project planning a Bitcoin bridge, sidechain or reserve-backed token should separate key security from transaction-validity security. Hardware security modules and threshold signatures protect signing credentials, but they do not prove that signers are authorizing economically valid actions.

The first operational requirement is independent validation. Production signers, public explorers and reserve monitors should not all rely on the same software version, build process or interpretation of transaction rules.

The second is release discipline. If untagged or development-branch code reaches systems controlling pooled collateral, teams should document why, identify the approvers, and ensure rollback and independent-review processes are practical rather than theoretical.

The third is an emergency plan that extends beyond pausing services. Liquid’s pause limited further peg activity, but a pause alone does not restore reserves, resolve chain divergence, compensate affected users, or settle negotiations with an attacker.

Blockstream is reportedly rolling out Dynamic Federations, or DynaFed, changes intended to expand multisignature key capacity, improve emergency key management and extend timelocks. Those changes may improve resilience, but they are not yet fully deployed. [10]

That means the market cannot yet judge whether DynaFed would have prevented this incident. Planned controls should be assessed as future mitigations, not booked as completed risk reduction.

Finally, project teams should avoid promising recovery timelines they cannot support. Liquid remains paused, and no public timetable has established when normal L-BTC deposits, withdrawals or peg-ins will resume. [5]

For users and exchanges, the outstanding questions remain concrete: whether the remaining 598 BTC will be recovered, whether L-BTC backing will be fully restored, how federation software will be audited, and what protections apply if a similar divergence occurs again.

Frequently Asked Questions

How much Bitcoin was stolen in the Liquid Network theft?

Approximately 4,000 BTC were withdrawn from the Liquid Network reserve during the theft. Of this, 3,400 BTC have been returned, leaving roughly 598 BTC still under the attacker’s control.

What caused the Liquid Network Bitcoin theft?

The theft exploited a software validation flaw in the Liquid Network’s peg-out process, allowing valid federation signatures to release Bitcoin that should not have existed. This was a governance and software failure rather than a theft of multisignature keys.

How much Bitcoin has been recovered after the Liquid Network hack?

3,400 BTC have been returned to the Liquid Network after Blockstream patched the affected bridge nodes. However, about 598 BTC remain unrecovered and are retained by the attacker.

What security vulnerabilities did the Liquid Network exploit reveal?

The exploit revealed weaknesses in the software validation and governance processes that determine legitimate withdrawals, rather than a breach of multisignature key security. It showed that multisig custody alone cannot prevent losses if invalid state is accepted by the system.

What are the implications of the Liquid Network theft for federated sidechains?

The incident highlights that federated custody models must address not only multisignature key security but also production validation, software-release controls, and chain-divergence monitoring. However, the failure appears specific to Liquid’s implementation and does not necessarily imply identical risks for all Bitcoin sidechains or federated bridges.

How we researched this

This article was assembled from 5 published articles, 10 cited references.

Nothing here is based on hands-on testing. Where a figure or finding appears, it belongs to the source cited beside it, and the writing says so rather than implying otherwise. Every source is listed below so you can check it.

Sources

Trezor Data Breach Expansion: Over 80,000 Customers Affected

Trezor Data Breach Expansion: Over 80,000 Customers Affected

Learn about the Trezor data breach expansion affecting 80,000+ customers and how to protect yourself from phishing risks linked to exposed data.

Tectonic Crypto Exploit

Tectonic Crypto Exploit

Explore the Tectonic crypto exploit, its impact on Cronos, and how collateral manipulation led to a $75M loss in DeFi lending protocols.

Crypto Security Incidents and Protocol Responses Explained

Crypto Security Incidents and Protocol Responses Explained

Explore recent crypto security incidents and how protocols respond with halts, patches, and recovery strategies to limit losses.

Bitcoin Technical Analysis and Trading Strategies Explained

Bitcoin Technical Analysis and Trading Strategies Explained

Learn bitcoin technical analysis, key support/resistance levels, volume signals, and trading strategies to navigate crypto market movements effectively.

Topics

Infrastructure