On September 6, approximately 4,000 bitcoins (worth around $320 million at the time) left the Liquid Network's wallet. This is the largest cryptocurrency theft event to date in 2026.
But the most puzzling aspect of this case is not the amount.
No private key was stolen, no HSM (Hardware Security Module) was breached, no one was phished, and there was no insider. The 15 institutions managing this vault all kept their keys perfectly intact in their own safes, and every signature was made by them actively, voluntarily, and according to the rules.
And just like that, the money walked out.
To understand how this happened, we need to spend a few minutes understanding how this vault was designed.
I. A Bitcoin Vault Co-managed by 15 Institutions
The Bitcoin mainnet has a well-known problem: it's slow and expensive. A transaction typically takes about ten minutes to be included in a block, and the fees fluctuate with mining difficulty. This is not sufficient for exchanges or quantitative teams that need to make large, frequent transfers.
Liquid Network is a solution proposed by Blockstream. It is a "sidechain"—think of it as a fast lane next to the Bitcoin mainnet.
The usage is simple: you deposit real bitcoin into a jointly managed vault, and the vault issues you a receipt of equivalent value. This receipt is called L-BTC and can circulate rapidly on this fast lane, handling a transaction per minute. When you want to withdraw the real bitcoin, you return the receipt for cancellation, and the vault gives you the equivalent amount of real coins. The former action is called peg-in, the latter peg-out. In theory, the total amount of L-BTC circulating on-chain should always equal the amount of real bitcoin lying in the vault—this is the so-called 1:1 peg.
The key is who manages this vault. Liquid's answer: it is not entrusted to any single entity, but to a "federation" of 15 known institutions, including multiple exchanges and infrastructure service providers. Each of these 15 nodes holds a key stored in its own dedicated Hardware Security Module (HSM). Any operation to open the vault requires simultaneous signatures from at least 11 of these keys, i.e., an 11/15 multisig.
Simultaneously, these 15 nodes are also responsible for taking turns producing blocks and validating each other. In other words, they are both the custodians of the vault and the bookkeepers of this chain.
The intention of this design is clear: single-point malfeasance is impossible; you would need to persuade 11 unrelated institutions simultaneously to steal the money. From the perspective of "defending against bad actors," it indeed does a good job.
II. A Private Ledger and "Verifying Money Without Opening the Envelope"
Liquid has another feature: its transaction amounts are kept confidential from the public.
On the Bitcoin mainnet, anyone can see the specific amount of each transfer. This is uncomfortable for institutions—your large-scale position adjustments are watched by the whole world. Liquid solves this with a technology called "Confidential Transactions": amounts are encrypted and hidden, leaving only a mathematical commitment on-chain; outsiders cannot see the specific numbers.
But this immediately introduces a new problem. If the amounts are invisible, how do nodes know that a transaction is not cheating? For example, writing a negative number out of thin air or inflating a number to overflow?
The solution is called "range proof." To use an analogy: put the amount into an opaque envelope, and attach a mathematical proof. This proof allows anyone to be convinced, without opening the envelope, that the number inside falls within a legitimate range. Nodes check these proofs one by one, confirming that the income and expenditure of each transaction balance, but never knowing the specific amount.
This mechanism itself is sound cryptography. The problem lies in its performance optimization.
III. The Vulnerability: A Verifier with Too Good a Memory, but Remembering the Wrong Thing
Verifying range proofs is computationally expensive. To prevent nodes from being overwhelmed, Elements (the open-source node software used by Liquid, a fork of Bitcoin Core) did something any engineer would do: add caching.
A proof that has been verified once is recorded; next time the same one is encountered, it is directly approved without recalculation.
Now the question arises: how to determine if "the encountered proof is the same one"?
Elements' approach was to create an index key using two things: the bytes of the proof itself, plus the encrypted amount commitment.
What was missed? It missed which asset this was, and who this money was to be paid to (the output script).
Using a checkout counter analogy. There is a bill verifier on the counter. Bills it has verified are recorded by serial number; the same serial number is directly approved next time. But when recording the serial number, it only recorded the watermark pattern and denomination of the bill, not which country's currency it was, nor which payee it was meant for. Thus, the same "verified" conclusion could be applied to a completely different, inapplicable scenario.
This is exactly what the attacker did, and very patiently. According to researcher analysis, in the approximately 14 hours before taking action, they gradually sent 68 identical range proofs to the chain—feeding these "verified" conclusions into the caches of various nodes, over and over. When the time was ripe, they submitted the same proof again, but placed it in a context where it should have been rejected.
The node checked its cache, found "I've verified this, no problem," and approved it.
Thus, 3,996 L-BTC, unsupported by any real bitcoin, was recorded into the ledger out of thin air.
Since the amounts were already hidden by Confidential Transactions, no observer on-chain could see this extra money.
IV. Those 35 Minutes: Every Step Compliant
At 23:53 Beijing Time on September 6 (15:53:10 UTC), Liquid block 4,050,336 packaged this forged transaction.
Every step that happened next was completely in accordance with the rules. This is the most unsettling part of the whole incident.
These newly minted L-BTC were transferred to SideSwap's wallet (a third-party platform providing peg-out services). Once mixed in, they became indistinguishable from any normal L-BTC. To the ledger, they were real money.
A dozen minutes later, a peg-out request for 4,000 L-BTC was submitted: cancel the receipts and withdraw the real bitcoin.
The 15 nodes began to perform their duties. Their HSMs performed two checks: whether the withdrawal address was on the whitelist, and whether the amount of L-BTC being destroyed matched the amount of bitcoin requested. Both checked out.
It would not, and could not, ask the third question: where did these L-BTC originally come from?
Eleven keys signed as usual. About 35 minutes later, the Bitcoin mainnet confirmed that transaction, and 3,996 real bitcoins left the federation wallet.
It's worth noting that Liquid had an emergency insurance mechanism: if the normal signing path fails, it requires using 2/3 of the backup keys and waiting 56 days to access the funds. This insurance was never triggered—because the attacker never went for the back door; they walked through the front door, and the front door opened for them.
The multisig threshold controls "who can sign"; it cannot answer "whether what is being signed is correct." When the forgery occurs at a layer below the signing—the node software's judgment of what constitutes real money—a higher threshold only serves to sign an erroneous expenditure more neatly.
V. How It Was Discovered
Ironically, this vulnerability caused discrepancies between different nodes: for the same block, some nodes accepted it, while others rejected it—depending on what was previously stored in their respective caches.
Bitcoin Core developer Antoine Poinsot pointed out publicly at the time that the key block was "rejected by mempool but accepted by Blockstream."
And mempool.space itself is a member of the federation. Its real-time auditing program caught an abnormal withdrawal of -4,019 BTC, while Liquid's official panel did not reflect this loss at the time—two monitoring systems presented different realities.
The subsequent numbers were stark: 4,205 L-BTC were circulating on-chain, while after processing a few subsequent withdrawals, only 197 real bitcoins remained in the federation wallet—a backing rate of less than 5%.
This also reveals the other side of Confidential Transactions: the cost of privacy is verifiability. With amounts hidden, no external party can cross-check in real time the "total receipt amount on the ledger" with the "balance of real coins in the vault." The 1:1 peg degenerates from a fact verifiable by anyone into a statement that needs to be believed. By the time it was proven false, the gap was already $320 million.
VI. More Striking Than the Bug Is the Patch
If the story ended here, it would just be a high-level cryptographic attack. But there is a second half.
The code to fix that caching flaw had already been submitted to the code repository on August 3, with a clear title: bind range proof caching to asset and output script. On September 2, it was merged into the main branch.
At the time of the incident, the federation nodes were running version 23.3.3—released on April 13, which did not contain this fix. Less than three hours after the incident on September 6, this patch was urgently merged into the release branch.
It needs to be clarified that the official has not formally confirmed that this incident was caused by this specific flaw; the above correspondence comes from external researcher analysis. But the timeline itself is sufficient to illustrate a more common problem: a vulnerability being fixed and the fixed code actually running in the production environment are two different things, and there can be a five-month gap between them.
Casa's Head of Security, Jameson Lopp, pointed out another thing: the public commit history of the federation node code repository showed that the last commit was in April 2024—over two years before the incident.
$320 million in assets was entrusted to software that hadn't been seriously maintained for two years. This is not a failure of cryptography; it's a failure of operations.
VII. "We Are White Hats," and Blockstream's Response
That evening, the receiving address sent an OP_RETURN message on-chain:
we are whitehats. contact us on chain.
Negotiations began. On September 7, the other party returned 3,400 bitcoins (approximately $272 million, 85%), keeping 598.5 bitcoins (approximately $47 million) for themselves.
Initially, communication was private, with Blockstream replying using encrypted and PGP-signed messages. But between September 8 and 9, the other party moved the messages to plaintext on the public chain, and the tone changed:
Accusing the other side of negligence—"You only spent $1.5 million (possibly even $0) to protect $5 billion in assets; this is a blatant disregard for security."
Proposing conditions—demanding that Blockstream pay an additional vulnerability bounty equivalent to 10% from its own funds as a precondition for returning the remainder.
And threatening—if refused, to make "all your holders bear a 15% loss for your irresponsibility and stinginess."
At this point, the self-proclaimed "white hat" status became difficult to maintain. Ledger's CTO, Charles Guillemet, was quite direct: a real white hat would disclose the vulnerability before moving the collateralized assets, not after; emptying 95% of the reserves first and then setting terms "resembles extortion more than security research."
Comparing with history also reveals the difference. In cases like Nomad, SafeMoon, and Team Finance, there have been outcomes where "most was returned, and a bounty was kept," but those usually involved a clear bounty arrangement, often around 10%. The peculiarity here is that the 15% was unilaterally taken, and the question of who set the "price" remained unanswered throughout.
Then, Blockstream publicly refused.
In a public statement, Blockstream stated it would not pay a ransom for the return of stolen funds and left no room for ambiguity: taking assets without authorization and refusing to return them is a crime, not responsible vulnerability disclosure, nor white-hat behavior—"this is theft."
The statement acknowledged that good-faith communication had indeed taken place earlier, aiming to recover user funds and protect the broader Bitcoin community, but emphasized that this should not be misinterpreted as accepting the other party's actions or conditions. It also explicitly refused to set a precedent: developers of open-source software created for the benefit of the Bitcoin community should not be forced to pay a ransom that "far exceeds their economic participation."
In response to the threat of "making holders bear a 15% loss," the statement's reply was a declaration of principle—bitcoin is hard money, it cannot be minted costlessly, and Bitcoin will not impose a write-down on users to pay a ransom.
Finally, it presented two paths: return now, and things can still be handled according to white-hat standards; if not returned, Blockstream will use all legal means, collaborating with law enforcement, exchanges, service providers, on-chain forensics experts, and other parties to trace, recover the assets, and identify the responsible parties. And it reminded everyone of a common knowledge in the crypto world: Bitcoin's design is inherently transparent; "transactions do not disappear, and the evidence they leave does not either."
Why this matter is more important than those $47 million. In recent years, "take first, negotiate terms later" has gradually solidified into a semi-standardized playbook: attackers drain the funds, claim to be white hats, keep a self-determined "bounty," and the project accepts to mitigate losses quickly. The essence of this playbook is that the pricing power of a security incident falls into the hands of the attacker—the return ratio, the retention amount, the negotiation pace are all decided by the other party.
What Blockstream refused this time was not so much the money, but this playbook. The price might be that the $47 million cannot be recovered; what is gained is not endorsing the pricing for the next attack. Whether this judgment is correct depends on whether subsequent investigations yield results. But it at least lays out a long-term ambiguity: the victim's willingness to communicate in good faith and the victim's acceptance of conditions are two entirely different things.
Another detail worth noting. Since an AI model, evaluated as "the first capable of independently discovering unknown vulnerabilities," was released just three days before the incident, there was speculation in the community linking the two events—there is still no evidence to support this; treat it as chatter. But interestingly, Blockstream's statement also proactively mentioned AI: "Advances in AI are making the world different, and the Bitcoin community has been working hard to address this threat."
The official did not say that this attack used AI. But the fact that a company that just lost $320 million mentions AI in the threat context of its incident statement itself indicates the industry's judgment: the cost of discovering deep vulnerabilities is decreasing, while the speed of patching and deployment has not kept pace. The patch that lay dormant for five months in this incident is the most concrete footnote to this statement.
VIII. The Current Situation
Liquid resumed block production at 12:26 UTC on September 10, but does not yet package user transactions; peg-in and peg-out remain suspended. The official has outlined a three-phase recovery path—first resume block production, then replay verified transactions, and finally reopen pegging operations after confirming the network state is correct.
After the return of 3,400 bitcoins, the backing rate of L-BTC returned to approximately 86%. Blockstream co-founder Adam Back publicly stated that the 1:1 L-BTC peg will be backed and advised holders not to panic sell on the over-the-counter market.
With Blockstream's public refusal to pay, the remaining 598.5 bitcoins are no longer a negotiation issue but have become an investigation issue—on-chain forensics, exchange cooperation, law enforcement involvement, with timelines measured in months or even years, and outcomes highly uncertain.
This also clarifies the meaning of the promise that "the 1:1 peg will be backed": the shortfall will be borne by Blockstream and the federation's own balance sheets, not by imposing a proportional write-down on token holders. This is precisely the implication of the statement's line, "Bitcoin will not write down users to pay a ransom." For L-BTC holders, this means that, for now, they face a liquidity freeze lasting from days to weeks, not a loss of principal—provided this guarantee of backing is fully executed. This "proviso" should be assessed by the holders themselves, not taken as grounds for optimism on their behalf.
IX. An Expensive Lesson for Institutions
This incident yields several conclusions that don't require you to understand cryptography.
First, "wrapped assets" are not the original assets.
The L-BTC in your hands, various cross-chain BTC, various wrapped tokens—they are not the native assets themselves, but deposit receipts. Their security equals the weakest link among three layers: the issuer's credibility, potential bugs in the node software implementation, and whether the entry/exit channels can distinguish between real and fake. In this case, the problem occurred in the second layer, and the party that accepted the bad money was the third layer—SideSwap did nothing wrong; it simply had no way to distinguish. Most people only look at the first layer when assessing risk.
Second, visibility is more important than invisibility.
Privacy is a genuine need, but when the verifiability of reserves is sacrificed, you lose the ability to detect a problem before it becomes catastrophic. The gap in this case was caught because different nodes accidentally gave different answers, not because of any designed verification mechanism.
Third, your risk includes others' operational rhythms.
A patch lying dormant for five months without being deployed; code that hasn't been touched for two years—these aren't written in any whitepaper, but they determine how safe your money is. When evaluating a protocol, besides reading its design documents, it's also worth looking at its commit history and version release discipline.
Fourth, multisig is necessary, but it defends against bad actors, not bad code.
An 11/15 multisig is a good defense in a key-theft scenario; in a scenario where software mistakes fake money for real money, it is useless. It might even make that erroneous expenditure appear exceptionally proper and legal.
Fifth, "white hat" is a behavioral standard, not an identity one can claim.
The difference lies not in how much is ultimately returned, but in the sequence: disclose first, then collaborate; or drain first, then set a price. Blockstream's choice, even risking the non-recovery of $47 million to publicly refuse payment this time, draws exactly this line for the industry. It may not recover the money, but it at least makes the next attacker uncertain whether claiming to be a white hat will still grant a get-out-of-jail-free card.
As a custody service provider, what alarms us most at Cactus Custody about this incident is not the vulnerability itself, but that it exposed three actions that could have been managed proactively:
- Asset vetting should not only examine the issuer; the minting logic, redemption channels, and the degree of reserve verifiability must be assessed together. Assets lacking independent verification means should be categorized and limited separately.
- Any entry confirmation relying on a single data source is fragile. Critical on-chain states are worth cross-verifying using two independent node service providers—the gap in this case was precisely caught because "two nodes gave different answers."
- Holding user assets in address-isolated accounts and conducting regular reconciliations can limit the blast radius of any single misjudgment to a manageable scope.
In the end, security is not about whose lock is stronger, but about who needs to trust fewer entities.
