How did 4,000 bitcoins on the Liquid Network walk out of the vault out of thin air?

On September 6, approximately 4,000 bitcoins (worth about $320 million at the time) left the Liquid Network's wallet. This is the largest crypto asset theft of 2026 so far.

But the most intriguing part 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 each kept their keys intact in their own safes, and every signature was made voluntarily, willingly, and in accordance with the rules.

The money simply walked out.

To understand how this happened, we first need to spend a few minutes grasping how this vault was designed.

1. A Bitcoin Vault Co-managed by 15 Institutions

The Bitcoin mainnet has a well-known problem: it's slow and expensive. A transaction takes an average of ten minutes to enter a block, and fees fluctuate with mining difficulty. For an exchange or quant team wanting to make large, frequent transfers, this isn't quite enough.

Liquid Network is one solution offered by Blockstream. It's a "sidechain"—you can think of it as a fast lane alongside the Bitcoin mainnet.

The usage is straightforward: you deposit real bitcoin into a co-managed vault, and the vault issues you a receipt of equal value. This receipt is called L-BTC, and it can circulate rapidly on this fast lane at one transaction per minute. When you want your real bitcoin back, you return the receipt to be redeemed, and the vault takes out an equivalent amount of real coins and returns them to you. The former action is called peg-in, and the latter is called peg-out. In theory, the total amount of L-BTC circulating on-chain should always equal the amount of real bitcoin sitting in the vault—this is the so-called 1:1 peg.

The key question is who manages this vault. Liquid's answer: not any single entity, but a "federation" of 15 known institutions, including multiple exchanges and infrastructure service providers. These 15 nodes each hold a key, stored in their own dedicated hardware security modules (HSMs). Any vault-opening operation requires at least 11 of these keys to sign simultaneously—an 11/15 multisig.

At the same time, these 15 nodes are responsible for taking turns producing blocks and validating each other. In other words, they are both the vault's custodians and the chain's bookkeepers.

The intent of this design is clear: single-point malfeasance won't work; you'd need to simultaneously persuade 11 mutually independent institutions to steal the money. From a "preventing bad actors" perspective, it does this quite well.

2. A Confidential Ledger, and "Verifying Bills Without Opening the Envelope"

Liquid has another feature: its transaction amounts are kept confidential from the outside world.

On the Bitcoin mainnet, anyone can see the exact amount of every transfer. For institutions, this is uncomfortable—your large rebalancing moves would be watched by the whole world. Liquid solved this with a technology called "Confidential Transactions": amounts are encrypted and hidden, leaving only a mathematical commitment on-chain, so outsiders can't see the specific numbers.

But this immediately creates a new problem. If the amounts are invisible, how do nodes know a transaction isn't cheating? For example, writing in a negative number out of thin air, or pushing a number to overflow?

The solution is called a "range proof." To use an analogy: put the amount into an opaque envelope, and attach a mathematical proof that lets anyone—without opening the envelope—be confident that the number inside falls within a legal range. Nodes check these proofs one by one, confirming that each transaction's inputs and outputs balance, but they never know the specific amount.

This mechanism itself is sound cryptography. The problem lies in its performance optimization.

3. The Vulnerability: A Bill Verifier with Too Good a Memory but the Wrong Priorities

Verifying range proofs is computationally expensive. To keep nodes from being overwhelmed, Elements (the open-source node software used by Liquid, a fork of Bitcoin Core) did what every engineer would do: add caching.

Once a proof has been verified, record the result; next time the same one comes up, just let it through without recomputing.

Now here's the problem: how do you determine that "this is the same one you encountered before"?

Elements' approach was to construct an index key from two things: the proof's own bytes, plus that encrypted amount commitment.

What was missing? It missed which asset this is, and who the money is being paid to (the output script).

Let's use a checkout counter analogy. There's a bill verifier on the counter. Every bill it verifies gets its serial number recorded, and the next time the same serial number appears, it passes through directly. But when recording the serial number, it only noted the bill's watermark pattern and denomination—it didn't note which country's currency this bill is, nor who it's supposed to be paid to. So the same "already verified" conclusion could be carried over to a completely inapplicable scenario.

This is exactly what the attacker did, and he was very patient. According to researchers' reconstruction, in the roughly 14 hours before acting, he fed 68 completely identical range proofs onto the chain one after another—repeatedly feeding these "verified" conclusions into each node's cache. When the time was ripe, he submitted the same proof in a context where it should have been rejected.

The node checked the cache, found "I've verified this one, no problem," and let it through.

Thus, 3,996 L-BTC with no real bitcoin backing was conjured into the ledger out of thin air.

Since the amounts were already hidden by confidential transactions, no observer on-chain could see the extra money.

4. 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 followed was completely compliant with the rules—this is the most unsettling part of the whole affair.

This batch of conjured L-BTC was transferred into the wallet of SideSwap (a third-party platform providing peg-out services). Once mixed in, they became indistinguishable from any normal L-BTC. In the eyes of the ledger, they were real money.

More than ten minutes later, a peg-out request for 4,000 L-BTC was submitted: redeem the receipt, take out real bitcoin.

The 15 nodes began performing their duties. Their HSMs would perform two checks: whether the withdrawal address is on the whitelist, and whether the amount of L-BTC burned matches the amount of bitcoin requested. Both checked out.

It would not, and could not, ask a third question: how did these L-BTC come into existence in the first place?

11 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 designed an emergency safeguard: if the normal signing path fails, 2/3 of the backup keys along with a 56-day wait would be required to move funds. This safeguard was never triggered—because the attacker didn't go through the back door at all. He walked through the front door, and the front door opened for him.

The multisig threshold governs "who can sign." It cannot answer "is what's being signed correct?" When forgery occurs at a layer below signing—the node software's judgment of what constitutes real money—no matter how high the threshold, it merely signs an erroneous expenditure more neatly.

5. How It Was Discovered

Ironically, this vulnerability would cause disagreement between different nodes: the same block, some nodes accepting it, others rejecting it—depending on what had previously been stored in their respective caches.

Bitcoin Core developer Antoine Poinsot publicly pointed out at the time that the critical block was "rejected by mempool but accepted by Blockstream."

And mempool.space itself is one of the federation members. Its real-time auditing program caught an anomalous withdrawal of -4,019 BTC, while the official Liquid dashboard did not reflect this loss in sync at the time—two monitoring systems presented different worlds.

The subsequent numbers were stark: 4,205 L-BTC circulating on-chain, while the real bitcoin in the federation wallet, after several subsequent withdrawal processes, was down to only 197—a backing ratio of less than 5%.

Here also lies the other side of confidential transactions: the cost of privacy is verifiability. With amounts hidden, no outsider can compare in real time "the total receipts on the ledger" against "the real coin balance in the vault." The 1:1 peg degraded from a fact anyone could verify into a claim that needed to be believed. By the time it was proven false, the gap was already $320 million.

6. More Glaring Than the Vulnerability Is That Patch

If the story ended here, it would just be a high-level cryptographic attack. But there's a second half.

The fix code for that cache flaw had already been submitted to the code repository on August 3, with a title that made it perfectly clear: bind the range proof cache to the asset and output script. On September 2, it was merged into the main branch.

But at the time of the incident, the federation nodes were running version 23.3.3—a version released on April 13, which did not include this fix. Less than three hours after the incident on September 6, this patch was urgently merged into the release branch.

It should be noted that the official team did not formally confirm that this incident was caused by this specific flaw; the above correspondence comes from external researchers' reconstruction. But the timeline itself is enough to illustrate a more general problem: a vulnerability being fixed and the fixed code actually running in production are two different things, and five months can lie between them.

Casa's head of security, Jameson Lopp, also pointed out another thing: the public records of the federation nodes' code repository show that the last commit was in April 2024—more than two years before the incident.

$320 million in assets entrusted to a piece of software that hadn't been seriously maintained in two years. This is not a failure of cryptography; it's a failure of operations.

7. "We Are Whitehats," 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 (about $272 million, or 85%), keeping 598.5 bitcoins (about $47 million) for themselves.

Initially the two sides communicated privately, with Blockstream replying via encrypted and PGP-signed messages. But from September 8 to 9, the other party moved the messaging to public on-chain plaintext, and the tone changed:

Accusing the other side of negligence—"You only put up $1.5 million (possibly even 0) to protect $5 billion in assets. This is a blatant disregard for security."

Setting conditions—demanding that Blockstream pay an additional bug bounty equivalent to 10% from its own funds as a precondition for returning the remaining portion.

And threatening—if refused, "all your holders will bear a 15% loss for your irresponsibility and stinginess."

At this point, the self-designation of "whitehat" is already very hard to sustain. Ledger CTO Charles Guillemet's assessment was quite direct: a real whitehat would disclose the vulnerability before moving collateral assets, not after; emptying 95% of the reserves first and then negotiating terms "looks more like extortion than security research."

Comparing with history also reveals the difference. In cases like Nomad, SafeMoon, and Team Finance, outcomes of "returning most, keeping a bounty" have appeared, but those usually had a clear bounty arrangement, mostly around 10%. What's special this time is: the 15% was unilaterally retained, and who sets the "price" was never answered from beginning to end.

Then, Blockstream publicly refused.

In a public statement, Blockstream said it would not pay a ransom for the return of stolen funds, and left no room in its words: taking assets without authorization and refusing to return them is a crime, not responsible vulnerability disclosure, nor whitehat behavior—"this is theft."

The statement acknowledged that communication had indeed been conducted in good faith previously, with the aim of securing the return of user funds and protecting the broader Bitcoin community, but stressed that this should not be misread as accepting the other party's behavior or proposed conditions. It also explicitly refused to set a precedent: developers of open-source software built for the benefit of the Bitcoin community should not be forced to pay a ransom "far exceeding their economic involvement."

In response to the threat of "making holders bear a 15% loss," the statement's response was a declaration of position—bitcoin is hard money, it cannot be minted at no cost, and bitcoin will not be written down for users in order to pay a ransom.

Finally, it offered two paths: return now, and the matter can still be handled according to whitehat standards; if not, Blockstream will use all legal means, cooperating with law enforcement, exchanges, service providers, on-chain forensics experts, and other parties to trace, recover assets, and hold those responsible accountable. And it reminded of a common-sense fact in the crypto world: bitcoin's design is inherently transparent—"transactions don't disappear, and neither does the evidence they leave behind."

Why This Matters More Than That $47 Million. Over the past few years, "take first, negotiate later" has gradually solidified into a semi-standardized script: attackers empty the funds, claim to be whitehats, leave a self-determined "bounty," and the project team accepts in order to stop the bleeding as quickly as possible. The essence of this script is that the power to price a security incident falls into the attacker's hands—the return ratio, the retained amount, the pace of negotiation, all decided by the other party.

What Blockstream refused this time is less about that money and more about this script. The cost may be that $47 million cannot be recovered; what's gained is not endorsing pricing for the next attack. Whether this judgment is correct depends on whether the subsequent investigation yields results. But at least it lays out a long-vaguely-handled question: the attacked party being willing to communicate in good faith and the attacked party accepting conditions are two completely different things.

There's one more detail worth noting. Because exactly three days before the incident, an AI model evaluated as "the first capable of independently discovering unknown vulnerabilities" was released, speculation linking the two events appeared in the community—this has no evidence to support it to date, so just treat it as chatter. But interestingly, Blockstream's statement also proactively mentioned AI: "Advances in AI have changed the world, and the Bitcoin community has already mobilized to address this threat."

Officially, it wasn't said that this attack used AI. But a company that had just lost $320 million writing AI into the threat background of its incident statement itself speaks to the industry's judgment: the cost of discovering deep vulnerabilities is falling, while the speed of patching and deployment has not accelerated in sync. That patch that sat for five months in this incident is the most concrete footnote to this statement.

8. The Current Situation

Liquid resumed block production at 12:26 UTC on September 10, but is temporarily not packaging user transactions; peg-in and peg-out remain suspended. The official team has given a three-phase recovery path—first resume block production, then replay verified transactions, and finally reopen peg operations after network status is confirmed correct.

After the return of 3,400 bitcoins, L-BTC's backing ratio returned to about 86%. Blockstream co-founder Adam Back publicly stated that the 1:1 LBTC peg will be backstopped, and urged holders not to panic-sell off-market.

With Blockstream publicly refusing to pay, the remaining 598.5 bitcoins are no longer a negotiation issue but an investigation issue—on-chain forensics, exchange cooperation, law enforcement involvement, with timelines measured in months or even years, and highly uncertain outcomes.

This also makes the meaning of the promise "1:1 will be backstopped" clear: the gap will be borne by Blockstream and the federation's own balance sheets, rather than having holders take a proportional write-down. This is precisely where the statement's line "bitcoin will not be written down for users in order to pay a ransom" lands. For L-BTC holders, this means what's at stake right now is a liquidity freeze lasting from days to weeks, not a loss of principal—provided this backstop commitment is fully executed. This "provided" should be evaluated by holders themselves, not optimistically assumed on their