Liquid Network Hack: Inside the Bizarre $320M Bitcoin Exploit

Someone withdrew almost $320 million in Bitcoin from the Liquid Network on 6 September. The network was paused, exchanges were asked to stop L-BTC deposits and withdrawals, and around 4,000 of the roughly 4,200 BTC held in Liquid’s federation wallet were suddenly gone. So far, that sounds like a fairly conventional cryptocurrency hack. 

Almost everything that happened next makes it considerably stranger. The people controlling the Bitcoin say they’re white-hat hackers. They haven’t moved the bulk of the funds onwards and say they intend to return most of them. But first, they want Blockstream to fix the vulnerability they apparently exploited and make sure every node is patched. 

Then there’s the hack itself. The attackers don’t appear to have stolen the cryptographic keys protecting Liquid’s Bitcoin reserves. Instead, the system apparently accepted L-BTC that shouldn’t have existed and then used its legitimate peg-out process to release real Bitcoin against it. And somehow, that still isn’t the strangest part. 

A code change addressing what independent researchers believe is related to the underlying weakness had already been moving through the public Elements repository before the exploit. Now, separate analysis has raised questions about whether that attempted fix introduced another vulnerability of its own. 

Blockstream hasn’t yet confirmed either connection. The result is a security incident that becomes more complicated the closer you look at it. And somewhere inside that sequence is a much bigger question about what it actually means to fix a vulnerability.

The Security Controls Apparently Did What They Were Supposed To Do

Liquid is a Bitcoin sidechain built using Elements, open-source software developed by Blockstream. Bitcoin moved onto Liquid is represented as L-BTC, with each L-BTC intended to be backed one-to-one by real BTC held by the Liquid Federation. Moving it back works in reverse. L-BTC is burned on Liquid and the corresponding Bitcoin is released from the federation wallet through a process known as a peg-out. 

On 6 September, SideSwap says a customer sent 4,000 L-BTC to its peg-out service. The service processed the request normally, burned the L-BTC with valid authorisation and the Liquid Federation subsequently released 3,996 BTC to the customer’s Bitcoin address. SideSwap says neither its systems nor its Peg-out Authorization Key had been compromised. 

The problem came earlier. According to SideSwap, Blockstream determined that the L-BTC presented for redemption had been created through a bug in Elements. In simple terms, the attackers appear to have found a way to create L-BTC without the real Bitcoin that was supposed to back it. 

That distinction changes how the Liquid Network hack should be understood. The attackers didn’t necessarily need to defeat the controls protecting the Bitcoin if they could make those controls process something the wider system had already accepted as valid. Independent on-chain analysis from Bitquery points towards a flaw involving range proofs. 

These are cryptographic proofs that let Liquid keep transaction values private while still checking that the transaction is valid. Nodes cache successful checks because verifying the same proofs repeatedly takes processing power. Bitquery identified 68 identical range proofs placed on Liquid during the 14 hours before the exploit, which it believes may have been used to prepare the network’s verification cache. 

Neither Blockstream nor Liquid has publicly confirmed the exact vulnerability yet. But the emerging technical picture suggests the problem sat deeper than compromised credentials or stolen keys. More importantly, evidence of a related problem was already sitting in the software’s public development history.

A Potential Fix Was Already Moving Through The Code

On 3 August, an Elements developer authored a change with the rather revealing title: “fix: range proof cache bind to asset and scriptpubkey.” The change altered what information Elements included when creating an entry in its range-proof verification cache. Previously, the cache used the proof and value commitment. 

The change added the asset commitment and output script. The pull request was opened on 31 August, merged into the main branch on 2 September and backported to the 23.x line the following day, according to Bitquery’s reconstruction of the repository history. The exploit happened on 6 September. 

At that point, the change hadn’t appeared in a released Elements version. There’s an important caveat here. Blockstream hasn’t confirmed that this code change fixed the vulnerability used in the attack. The connection comes from independent analysis of the repository and transactions, so it remains exactly that: a connection researchers have identified, not a confirmed root cause. 

But the timing exposes a problem regardless. A vulnerability isn’t fixed simply because somebody has written the corrected code. The change still has to be reviewed, merged, released, distributed and deployed. Until that process reaches the systems actually running the software, vulnerable code can remain in production. 

And when development happens in public, there’s another complication. Other people can see what changed too.

Public Fixes Can Also Reveal What Was Broken

Security researchers have been comparing software updates with the code they replace for years. The practice is known as patch diffing, and it can reveal far more than the developer intended. 

If a previously ordinary-looking piece of code suddenly changes because additional information needs to be checked, someone examining that difference can ask a fairly obvious question: what could I do with the old version that I can’t do anymore? There’s no evidence that the people behind the Liquid exploit discovered the vulnerability this way. 

We don’t currently know how they found it. But the public repository history makes the question difficult to ignore. A security-related change was visible days before the attack, while software without that change was apparently still in use. Could someone have worked backwards from the fix? 

That window between a vulnerability becoming visible and every affected system being protected is known as the patch gap. Recent research suggests AI is making it considerably more dangerous. In June 2026, Anthropic tested how well frontier AI models could turn published security patches into working exploits. 

Across 18 Firefox security patches, its most capable research model autonomously created eight working code-execution exploits. Against 21 Windows kernel patches, it produced eight complete privilege-escalation chains. Anthropic’s conclusion was that work which once demanded scarce reverse-engineering expertise can increasingly be compressed into hours. 

None of that proves AI had anything to do with Liquid. But it changes the environment around incidents like this one. Publishing a fix while vulnerable systems remain exposed no longer carries quite the same assumptions about how much time defenders have before somebody understands what the change reveals. 

And in Liquid’s case, there may have been another problem hiding inside the fix itself.

What If The Fix Creates Another Vulnerability?

Gregory Maxwell, a former Blockstream developer who worked on the cryptographic range proofs that preceded the code involved here, reviewed the public transactions and Elements repository after the incident. His interpretation adds another twist. Maxwell believes there was a longstanding problem with the way Elements cached validation results. 

But after examining the recent change intended to correct that behaviour, he argued that the fix may have introduced a separate hash-collision vulnerability because the new fields added to the hash weren’t properly separated. Put much more simply, the software may have started checking more information without defining the boundaries between those pieces of information clearly enough. 

That could allow two different sets of inputs to produce something the system treats as equivalent. Maxwell believes this newer weakness offers a more straightforward route to creating funds that shouldn’t exist. But his analysis is independent. 

Blockstream hasn’t confirmed that the attempted fix introduced the vulnerability used on 6 September, and Maxwell himself has been clear about the limits of his assessment. That uncertainty is important because there are several possible technical sequences still being investigated. 

What we do know is that remediation changes software, and changed software has to be treated as new code that needs scrutiny of its own. The race isn’t simply to get from vulnerability discovery to patch deployment as quickly as possible. A rushed or incomplete fix can change the problem rather than solve it. 

Which makes the demands coming from the people holding the Bitcoin particularly interesting.

The People Holding $320M Want The Network Patched First

After the withdrawal, the actors consolidated the Bitcoin into another address and left an on-chain message identifying themselves as “whitehats” and asking Blockstream to contact them. Blockstream did, using Bitcoin transactions and PGP-signed messages to communicate with the group. 

The actors later asked whether sending “most” of the Bitcoin back to the federation wallet would be acceptable. Blockstream agreed. Then they added a condition. They told Blockstream to fix the bug first, make sure every node was patched and confirm that the repair was safe before they would transfer the money back. 

They also claimed the chain remained at risk under the latest code at the time. Blockstream subsequently sent a signed message saying its bridge nodes had been patched and that the funds could safely be returned. At the time of writing on 7 September, the roughly 4,000 BTC remained in the receiving wallet. 

The actors also haven’t said how much of the money “most” actually means. It’s an extraordinary way to disclose a vulnerability. It also leaves the “white hat” part of their description doing quite a lot of work.

Calling Yourself A White Hat Doesn't Settle The Question

White-hat security research normally works very differently. Researchers identify vulnerabilities, disclose them through an agreed or responsible process and give the affected organisation an opportunity to investigate and remediate the problem. Bug-bounty programmes can then reward them for doing so. 

Taking control of nearly an entire $320 million Bitcoin reserve before making contact doesn’t fit neatly into that model. Ledger CTO Charles Guillemet publicly questioned the label after the incident, arguing that white hats don’t normally empty a bridge and then ask its operator to contact them. 

But he also acknowledged the other side of the problem: conventional criminal groups don’t usually take hundreds of millions of dollars and then open negotiations about returning most of it either. We don’t know what motivated the actors, so trying to decide whether they’re researchers, criminals or something awkwardly between the two gets ahead of the evidence. 

What their behaviour does show is how messy vulnerability disclosure can become when discovery, exploitation and remediation happen at different speeds. The developers are trying to establish what went wrong. The software is being changed. The network needs those changes deployed. 

Meanwhile, the people who demonstrated the weakness are sitting on the assets that proved how serious it was. There’s also a more basic question underneath all of this. Even if the peg-out was technically valid according to the controls checking it, should one transaction have been able to remove almost the entire Bitcoin reserve without another layer of scrutiny?

Valid Doesn't Always Mean Safe Enough To Proceed

Liquid’s federation wallet held roughly 4,200 BTC before the incident. The exploit resulted in 3,996 BTC being released through a single peg-out. That’s around 95 per cent of the Bitcoin that had been held in the wallet. The transaction was extraordinary even before anyone knew something was wrong with the L-BTC behind it. 

That creates a separate security question from the Elements vulnerability itself. High-impact systems can’t always rely on a binary decision between authorised and unauthorised. Sometimes the consequence of an action is enough to justify another check. A payment can carry valid credentials and still be wildly unusual. 

An administrator can have permission to delete data without it making sense for them to erase an entire production environment. An automated process can satisfy every rule it has been given while doing something far outside normal operating conditions. This doesn’t mean every large or unusual action should be blocked. 

It means security controls can account for consequence as well as permission, particularly when one valid decision can create an irreversible outcome. For Liquid, we’ll need a fuller incident report before we know exactly which safeguards existed around the peg-out and how they behaved. 

But the scale of the withdrawal gives organisations another reason to look beyond the moment a control says “yes”. The same thinking applies to the vulnerability itself. A developer saying “fixed” is only one decision inside a much longer process.

The Dangerous Part Of A Vulnerability Isn't Over When The Code Is Fixed

Traditional patch management can make vulnerability remediation sound almost linear. Someone finds a problem, developers create a fix, organisations deploy it and the vulnerability is closed. The Liquid Network hack shows why reality can be considerably messier. 

There’s a period between discovery, remediation, public visibility, validation, release and deployment where the security state is still changing. The original weakness may remain exploitable while a fix moves through development. Public code changes can provide clues about what was wrong. AI can make those clues faster to analyse. 

And the fix itself still has to be tested carefully enough to establish that it hasn’t introduced another problem. Then there’s deployment. Code that has been corrected in a repository doesn’t protect a system that’s still running the vulnerable version. This is the security remediation gap that organisations need to account for. 

It isn’t simply the number of days between a patch becoming available and someone installing it. It begins when knowledge of the weakness starts changing who knows what, which code is running and what an attacker may be able to learn. 

For security teams, that makes remediation an active period of exposure rather than an administrative process that follows vulnerability discovery. The question isn’t only how quickly a patch can be deployed. It’s how safely the organisation can move from knowing something is broken to knowing the systems depending on it are protected.

Final Thoughts: A Vulnerability Isn't Fixed Until The System Is Safe

The Liquid Network incident is still developing, and some of its most important technical questions remain unanswered. Blockstream hasn’t published a full root-cause analysis, the exact relationship between the public Elements changes and the exploit remains unconfirmed, and we still don’t know how the actors discovered the weakness. 

But the sequence we can see already challenges the neat line organisations tend to draw between vulnerable and fixed. A fix can exist while production systems remain exposed. Publishing it can reveal information about the problem it was designed to solve. Moving too quickly can create new risk if the remediation itself isn’t properly validated. 

And deployment still has to reach every system that depends on the corrected code before the vulnerability can genuinely be considered closed. AI is making that uncomfortable period harder to ignore. 

As models become better at analysing software changes and developing exploits from public patches, the time defenders can assume exists between disclosure and exploitation is shrinking. A security fix, then, isn't a commit in a repository. It's a process that ends when the weakness has been corrected, the correction has been tested and the systems relying on it are actually protected. 

For a story that began with someone apparently creating Bitcoin-backed assets out of thin air, withdrawing nearly $320 million and then offering most of it back once everyone patches their software, that's perhaps the least bizarre lesson to come out of it. 

As vulnerability discovery and exploitation continue to accelerate, EM360Tech will keep examining how security teams can adapt the processes between finding weaknesses, fixing them and keeping increasingly complex enterprise systems protected.