On September 6, approximately 4,000 bitcoins (around 320 million USD at the time) left the wallets of the Liquid Network. This is the largest theft of cryptocurrency assets so far in 2026.

However, the most intriguing aspect of this case is not the amount.

Not a single private key was stolen, not one hardware security module (HSM) was compromised, no one was phished, and there were no inside jobs. The 15 institutions managing this vault each had their keys securely stored in their own safes, and every signature was completed proactively, voluntarily, and according to the rules.

The money simply went out.

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

1. A Bitcoin Vault Co-managed by 15 Institutions

There is a well-known problem with the Bitcoin mainnet: it is slow and expensive. A transaction typically takes ten minutes to enter a block, and fees fluctuate with mining difficulty. This is not sufficient for exchanges or quantitative teams that wish to make large, frequent transfers.

Liquid Network is a solution provided by Blockstream. It is a "sidechain"—you can think of it as a fast lane next to the Bitcoin mainnet.

The usage is quite simple: you deposit real bitcoins into a co-managed vault, and the vault issues you a corresponding deposit certificate called L-BTC, which can be quickly transacted on this fast lane once a minute. When you want to redeem the actual bitcoins, you return the certificate for cancellation, and the vault retrieves an equivalent amount of real currency for you. The first action is called peg-in, and the second is called peg-out. In theory, the total amount of L-BTC circulating on the chain will always equal the amount of real bitcoins lying in the vault—which is what is referred to as 1:1 pegging.

The key lies in who manages this vault. Liquid's answer is: not assigned to any single entity, but rather entrusted to a "federation" composed of 15 known institutions, including several exchanges and infrastructure service providers. These 15 nodes each hold a key stored in their dedicated hardware security modules (HSMs), and any operation to open the vault requires at least 11 keys to sign simultaneously, thus 11/15 multi-signature.

At the same time, these 15 nodes are also responsible for block generation and mutual verification. That is to say, they are both the custodians of the vault and the accountants of this chain.

The intent of this design is clear: a single point of failure is not viable; you need to persuade 11 unrelated institutions simultaneously to steal the money. From the perspective of "preventing bad actors," it indeed performs well.

2. A Confidential Ledger and "Cash Verification Without Opening the Envelope"

Liquid also has a feature: its transaction amounts are kept confidential.

On the Bitcoin mainnet, anyone can see the specific amount of each transaction. This is uncomfortable for institutions—your large rebalancing acts would be observed by the entire world. Liquid addresses this issue with a technology called "Confidential Transactions": the amounts are encrypted and hidden, leaving only a mathematical commitment on the chain, so outsiders cannot see the specific numbers.

But this immediately introduces a new problem. If the amounts are not visible, how can nodes know that the transaction is not fraudulent? For example, what if someone wrote a negative number out of thin air, or inflated the number to overflow?

The solution is called "range proof." For example: place the amount into an opaque envelope, along with a mathematical proof that allows anyone to be sure that the number inside falls within a legitimate range without opening the envelope. The nodes check these proofs one by one, confirming that the incoming and outgoing of each transaction matches, but they never know what the specific amount is.

This mechanism is inherently reliable cryptography. The issue lies in its performance optimization.

3. Vulnerability: A Counterfeit Detection Machine with an Impeccable Memory but Wrong Focus

Validating range proofs is computationally intensive. To prevent nodes from being overwhelmed, Elements (the open-source node software used by Liquid, which is a branch of the Bitcoin core code) did something that any engineer would do: it implemented caching.

Once a proof is validated, the result is recorded, so when the same one is encountered again, it is directly allowed through without recalculation.

Now, the problem arises: how to determine "it is the same one"?

Elements' approach was to construct an index key from two pieces: the bytes of the proof itself, plus the encrypted amount commitment.

What was left out? What was left out is what kind of asset this is, and who the money is to be paid to (output script).

Take a cash counter as an analogy. There is a cash detection machine on the counter that records the numbers of verified notes, and when the same number appears again, it goes through directly. But when it records the number, it only noted the watermark pattern and denomination, lacking information on what currency the bill is or to whom it is to be given. Thus, the same conclusion of "verified" may be wrongly applied in a completely inappropriate context.

That is exactly what the attacker did, and with great patience. According to researchers' timeline, about 14 hours before the attack, they submitted 68 identical range proofs to the chain—feeding these "verified" conclusions to the cache of various nodes repeatedly. When the time was ripe, they submitted the same proof in a context that should have been rejected.

The nodes checked the cache, found "I have verified this, no problem," and thus allowed it.

As a result, 3,996 L-BTC, which had no real bitcoins backing, were recorded in the ledger.

Since the amounts were originally hidden by confidential transactions, no external observers on the chain could see this additional money.

4. The 35 Minutes: Every Step Was 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 fully compliant with the rules, which is the most unsettling part of the whole affair.

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

A few minutes later, a peg-out request for 4,000 L-BTC was submitted: to cancel the deposit certificate and withdraw the real bitcoins.

The 15 nodes began fulfilling their roles, and their hardware security modules conducted two checks: whether the withdrawal address was on the whitelist and whether the number of L-BTC destroyed matched the Bitcoin amount requested. Both checks were satisfied.

It would not—and could not—ask the third question: how did these L-BTC originate?

11 keys signed as usual. About 35 minutes later, the Bitcoin mainnet confirmed that transaction, and 3,996 real bitcoins left the federation's wallet.

It is worth mentioning that Liquid had a panic insurance: if the normal signing path failed, funds could only be accessed using 2/3 of backup keys and requiring a 56-day waiting period. This insurance was never triggered—because the attacker didn't go for the backdoor; they went through the front door, and the front door opened for them.

The multi-signature threshold manages "who can sign," but it cannot answer "is what is being signed correct." When forgery occurs at a layer lower than the signature—where the node software determines what constitutes real money—the higher the threshold, the more neatly an erroneous expenditure is signed.

5. How It Was Discovered

Ironically, this vulnerability created divergences between different nodes: for the same block, some nodes accepted it while others rejected it—depending on what had previously been stored in their caches.

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

And mempool.space itself is one of the federation members. Its real-time audit system captured an anomaly of a -4,019 BTC withdrawal, while the Liquid official dashboard did not synchronously reflect this loss at the time—two monitoring systems gave different worlds.

The subsequent figures were glaring: there were 4,205 L-BTC circulating on the chain, while the real bitcoins in the federation's wallet were reduced to only 197 after several subsequent withdrawals were processed, leaving a support rate of less than 5%.

This also hides another aspect of confidential transactions: the price of privacy is verifiability. With amounts hidden, no one externally can compare "the total number of deposit certificates on the ledger" with "the balance of real coins in the vault" in real-time. The 1:1 peg transitioned from being a fact that anyone could verify into a statement that needs to be believed. By the time it was debunked, the gap had already reached 320 million USD.

6. A More Striking Issue than the Vulnerability Is the Patch

If the story ended here, it would merely be a high-level cryptographic attack. But there is a later part.

The code fixing that caching flaw was submitted to the code repository on August 3, titled clearly: binding range proof cache to the 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—which was released on April 13 and 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 is worth clarifying that the official has not formally confirmed that this incident was caused by this specific flaw; the correlation comes from external researchers' reviews. But the timeline itself sufficiently reveals a more general issue: fixing a vulnerability and having the fixed code actually run in a production environment are two different things, and there can be a gap of five months in between.

Jameson Lopp, the security chief at Casa, pointed out another thing: the code repository of the federation nodes shows that the last submission was in April 2024—over two years after the incident.

320 million USD in assets were entrusted to software that had not been properly maintained for two years. This is not a failure of cryptography but a failure of operations.

7. "We Are Whitehats," and Blockstream's Response

That evening, the receiving address sent an OP_RETURN message to the chain:

We are whitehats. Contact us on chain.

Negotiations began. On September 7, they returned 3,400 bitcoins (approximately 272 million USD, accounting for 85%), keeping 598.5 (about 47 million USD).

Initially, the two parties communicated privately, with Blockstream responding through messages that were encrypted and PGP signed. However, on September 8 and 9, they took their shouting to the public on the chain, and the tone changed:

They accused Blockstream of negligence—"You only put out 1.5 million USD (possibly even 0) to protect 5 billion USD in assets; this is a blatant disregard for security."

They proposed conditions—demanding Blockstream pay an amount equivalent to 10% of the vulnerability bounty from its own funds as a precondition for returning the remaining part.

And they issued threats—if refused, they would make "all your holders pay 15% of the loss for your irresponsibility and stinginess."

At this point, the self-proclaimed "whitehats" became increasingly difficult to justify. Charles Guillemet, Chief Technology Officer of Ledger, commented quite directly: real whitehats would disclose vulnerabilities before using the collateral assets, not after; negotiating conditions after emptying 95% of reserves "resembles extortion rather than security research."

Comparing with history shows the differences. In cases like Nomad, SafeMoon, and Team Finance, an outcome often occurs where "most is returned, and a bounty is kept," but these typically have a clear bounty arrangement, often around 10%. The uniqueness of this situation is that the 15% was unilaterally retained, and it was never clear who set the "price."

Then, Blockstream publicly declined.

In a public statement, Blockstream indicated that it would not pay a ransom for the return of stolen funds and made it unequivocal: unauthorized removal of assets and refusal to return is a crime, not responsible vulnerability disclosure, nor whitehat behavior—"this is theft."

The statement acknowledged that previously, good faith communication was made with the intent to recover user funds and protect the broader Bitcoin community, but emphasized that this should not be misconstrued as acceptance of the other party's actions or terms. It also made it clear that it would not set a precedent: developers of open-source software created for the benefit of the Bitcoin community should not be compelled to pay a ransom "far exceeding their economic participation."

In response to the threat of "letting holders bear 15% of the loss," the statement's counter was a declaration of position—Bitcoin is hard currency that cannot be minted at no cost, Bitcoin will not be marked down to pay a ransom.

Finally, it provided two options: return the funds now, and the situation could still be handled under whitehat standards; if not returned, Blockstream would use all lawful means to cooperate with law enforcement, exchanges, service providers, chain forensic experts, and others to trace and recover assets and identify the individuals responsible. It also reminded of a common sense in the crypto world: the design of Bitcoin itself is transparent, "transactions will not disappear, and the evidence they leave behind will not either."

Why this matter is more important than the 47 million USD. Over the past few years, "take it first, negotiate conditions later" has gradually crystallized into a semi-standardized script: attackers empty the funds, self-proclaim as whitehats while leaving an arbitrarily defined "bounty," and project teams accept this to stop losses quickly. The substance of this script is that the pricing power of a security incident rests in the hands of the attacker—the return ratio, retention amount, and negotiation pace are all set by the other party.

Blockstream's refusals this time are less about the money and more about this script. The cost may be 47 million USD unrecoverable; what it gains is not setting a price for the next attack. Whether this judgement is correct will depend on whether subsequent investigations yield results. But it at least laid bare a long-ambiguous issue: willingness to communicate in good faith and acceptance of terms are two entirely different things.

Another detail worth noting. Just three days before the incident, a model rated as "the first capable of independently discovering unknown vulnerabilities" was released, and there were speculations in the community linking the two events—there is currently no evidence to support this, so it is best considered as talk. However, interestingly, Blockstream's statement also proactively mentioned AI: "Advancements in AI have made the world different, and the Bitcoin community is fully coping with this threat."

The official did not say that AI was used for this attack. But a company that just lost 320 million USD wrote AI into the threat context in its incident statement, which speaks volumes about the industry's assessment: the cost of discovering deep vulnerabilities is decreasing, while the speed of patching and deploying has not sped up in sync. The patch that lay dormant for five months in this incident is the most concrete annotation of this statement.

8. Current Situation

Liquid resumed block production on September 10 at 12:26 UTC, but is not yet packaging user transactions; peg-in and peg-out remain suspended, with the official providing a three-phase recovery path—first resuming block production, then re-processing validated transactions, and finally reopening anchoring operations once the network status is confirmed correct.

After returning 3,400 bitcoins, the support rate for L-BTC returned to about 86%. Blockstream co-founder Adam Back publicly stated that the 1:1 L-BTC peg would be sustained and urged holders not to panic sell in the market.

With Blockstream's public refusal to pay, the remaining 598.5 bitcoins are no longer a negotiation issue, but rather a matter of investigation—on-chain forensics, exchange cooperation, law enforcement involvement—a timeline measured in months or even years, with a result highly uncertain.

This also clarifies the meaning of the promise that "1:1 will be sustained": the gap will be borne by Blockstream and the federation's own balance sheets, not proportionately written down by holders. This is exactly the point made in the statement that "Bitcoin will not be marked down to pay a ransom." For L-BTC holders, this means a liquidity freeze lasting several days to weeks, rather than a principal loss—provided this backstop commitment is fully honored. This "proviso" should be assessed by the holders themselves, rather than being taken on with optimism.

9. The Expensive Lesson for Institutions

This event offers several conclusions without needing one to understand cryptography.

First, "packaged assets" are not equivalent to original assets. 

The L-BTC in your hands, various cross-chain BTC, and packaged tokens are not the native assets themselves, but rather a deposit certificate. Their security equals that of the weakest layer among the three: whether the distributor is trustworthy, whether there are bugs in the node software implementation, and whether the channels for depositing and withdrawing can distinguish between real and fake. In this case, the issue was with the second layer, while the third layer—the one that bore the bad money—was innocent; it simply couldn't distinguish. Most people, when assessing risks, only look at the first layer.

Second, visibility is more important than invisibility. 

Privacy is a real need, but when the verifiability of reserves is sacrificed, you lose the capability to discover problems before they escalate. This gap was only caught because different nodes inadvertently gave different answers, rather than any designed verification mechanism.

Third, your risks include other people's operational rhythms.

A patch lay dormant for five months without being deployed, and a code repository that had not been touched for two years—none of this is documented in any whitepaper, but it determines how safe your money is. When evaluating a protocol, it is worthwhile to glance at its code commit records and version release discipline, in addition to reading its design documents.

Fourth, multi-signature is necessary, but it guards against bad actors, not bad code.

11/15 is a strong line of defense in cases of stolen keys; in scenarios where software mistakes fake money for real, it is of no use and may even veil the erroneous expenditure, making it appear particularly orderly and valid.

Fifth, "whitehat" is a standard of behavior, not an identity that can be self-proclaimed.

The distinction lies not in how much is ultimately returned, but in the sequence: disclose first, then cooperate; or empty out first, then negotiate. Blockstream would rather risk not recovering 47 million USD than publicly pay ransom, leaving precisely this boundary for the industry. It may not be able to recover the money, but at least it makes it impossible for the next attacker to determine if "self-proclaimed whitehat" will still carry a get-out-of-jail-free card.

As a custody service provider, Cactus Custody realizes that the most alarming aspect of this incident is not the vulnerability itself, but the three actions that could have been managed in advance:

• Asset admission cannot only review the issuer; the logic of minting, redemption channels, and the verifiability of reserves must be assessed together; assets lacking independent verification should be categorized and limited separately.

• Any accounts confirmation relying on a single data source is fragile; the state on the chain should be cross-verified by two independent node service providers—this gap was captured precisely when "two nodes gave different answers."

• Isolating user assets by address and reconciling them regularly can contain the explosion radius of any single judgment error within manageable limits.

In the end, safety is not about whose lock is tighter, but about who has fewer entities to trust.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。