About 4,000 BTC left Liquid Network’s wallet on Sept. 6, worth roughly $320 million at the time. The source article describes it as the largest crypto asset theft of 2026 so far.
The most striking part was not the amount. No private key was reported stolen. No hardware security module, or HSM, was said to be breached. There was no phishing incident in the account given by the source, and no insider was identified. The 15 institutions managing the vault still held their own keys, and each signature was produced voluntarily and under the normal rules. The money still went out.
A Bitcoin vault run by 15 institutions
Liquid Network is Blockstream’s sidechain built to address familiar Bitcoin mainnet constraints: slower settlement and fee volatility. Users deposit real BTC into a jointly managed vault and receive an equal amount of L-BTC on Liquid. That asset can move on the sidechain, and when users want their Bitcoin back, they redeem the L-BTC and withdraw the same amount of BTC from the reserve.
The article frames those two steps in standard Liquid terms: peg-in when BTC enters the system, peg-out when L-BTC is redeemed for native Bitcoin. In theory, the circulating supply of L-BTC should always match the amount of real BTC held in the federation wallet on a 1:1 basis.
Control of that reserve is spread across a federation of 15 known institutions, including exchanges and infrastructure providers. Each federation member holds one key, stored in a dedicated HSM. Any vault movement requires at least 11 signatures, a standard 11-of-15 multisig threshold.
Those same 15 nodes also take part in block production and validation. So the federation is not only safeguarding the reserve. It is also maintaining the chain’s ledger. The model is meant to make single-point theft impractical, because draining the vault should require convincing at least 11 unrelated institutions to sign.
Why hidden amounts need extra proofs
Liquid also hides transaction amounts from public view. On Bitcoin mainnet, transfer sizes are visible to anyone, which many institutional users view as a problem for treasury movements and large position shifts. Liquid addresses that with Confidential Transactions, where the amount is concealed and replaced on-chain by a mathematical commitment.
That creates a new verification problem. If the amount is hidden, nodes still need a way to confirm that the sender is not cheating by constructing an invalid value, a negative value, or some overflow condition. The system answers that with range proofs.
In simple terms, nodes can verify that the hidden amount falls within a valid range without learning the amount itself. According to the source article, the cryptography behind that mechanism is not the issue. The issue came from a performance optimization in the software implementation.
The cache bug that let a valid proof be reused in the wrong place
Liquid uses Elements, an open-source node implementation derived from Bitcoin Core. Verifying range proofs is computationally expensive, so Elements cached prior verification results. If a proof had already been checked, the software could skip recomputation the next time it encountered what it considered the same proof.
The problem, as described in the source article, was how Elements decided what counted as the same proof. Its cache key was built from two pieces: the bytes of the proof itself and the encrypted amount commitment. It did not bind that cached result to the asset type, and it did not bind it to the output script.
That opened the door for a proof already accepted in one context to be reused in another context where it should have failed. Based on the reconstruction cited by the article, the attacker spent roughly 14 hours preparing the cache, sending 68 identical range proofs on-chain to populate node caches with previously accepted verification results. Once that setup was in place, the attacker reused the same proof in a context that should have been rejected.
Nodes looked up the cache, saw a prior successful verification, and accepted the transaction. The result, according to the article, was that 3,996 L-BTC with no real BTC backing were recorded into the ledger. Because Confidential Transactions hide amounts, outside observers could not directly see that extra balance being created.
In 35 minutes, unsupported L-BTC became real BTC
At 15:53:10 UTC on Sept. 6, corresponding to 23:53 Beijing time, Liquid block 4,050,336 included the forged transaction.
The newly created L-BTC was then moved into a wallet associated with SideSwap, a third-party platform that provides peg-out services. Once those units were mixed into the normal flow, the ledger no longer distinguished them from any other L-BTC.
Minutes later, a peg-out request for 4,000 L-BTC was submitted to redeem native Bitcoin. The 15 federation nodes then followed the normal withdrawal process. Their HSMs checked two things: whether the withdrawal address was on the whitelist and whether the amount of burned L-BTC matched the amount of BTC being requested. Both checks passed.
But the HSMs did not ask, and were not designed to ask, where those L-BTC originally came from. Eleven keys signed as usual. Roughly 35 minutes later, the Bitcoin mainnet transaction confirmed, and 3,996 real BTC left the federation wallet.
Liquid does have an emergency path in its design. If the normal signing route fails, reserve movement can fall back to a path requiring two-thirds of backup keys plus a 56-day delay. That mechanism was never triggered here because the attacker did not force open a back door. The attacker used the front door. Multisig can decide who is allowed to sign. It cannot determine whether the thing being signed is valid if the software below it has already made the wrong call.
How the discrepancy was noticed
The same flaw also caused node disagreement. One node could accept the block while another rejected it, depending on what each had previously stored in cache.
Bitcoin Core developer Antoine Poinsot publicly pointed out that the critical block was “rejected by mempool but accepted by Blockstream,” according to the source article. The article also notes that mempool.space is itself one of the federation members.
Its real-time audit system reportedly detected an anomalous withdrawal of -4,019 BTC, while Liquid’s official dashboard did not reflect the loss at that moment. Two monitoring views showed different realities. The numbers that followed were even harder to ignore: 4,205 L-BTC were circulating on-chain, while the federation wallet, after several subsequent withdrawals were processed, was left with only 197 BTC in real reserves. That put backing below 5%.
The article uses that point to highlight a trade-off built into Confidential Transactions. Privacy comes at the cost of independent verifiability. Once amounts are hidden, outside observers lose the ability to continuously compare the total amount of claims on the ledger with the actual reserves in the vault. A publicly checkable 1:1 peg becomes, in practice, a statement that must be trusted until something goes visibly wrong.
The patch had already been written
The article argues that the postmortem became even more damaging once the patch timeline came into view.
Code to fix the cache defect had already been submitted on Aug. 3. Its title, the article says, explicitly described binding the range-proof cache to the asset and the output script. The patch was merged into the main branch on Sept. 2.
Yet the federation nodes were still running version 23.3.3 at the time of the incident, a release dated April 13 that did not include the fix. Less than three hours after the Sept. 6 theft, the patch was urgently merged into the release branch.
The source article makes an important qualification here: Blockstream has not formally confirmed that this specific defect caused the incident. The mapping between the exploit and the patch comes from external researchers’ reconstruction. Still, the timeline alone points to a broader operational issue. A vulnerability can be fixed in code long before the fix reaches production.
Casa security lead Jameson Lopp also noted, according to the article, that the public record for the federation node repository showed its previous commit in April 2024, more than two years before the theft. In the article’s framing, this was not just a failure of cryptography. It was also a failure in maintenance and deployment discipline.
“We are whitehats” and the negotiations that followed
On the night of the incident, the recipient address published an OP_RETURN message on-chain: “we are whitehats. contact us on chain.”
Negotiations followed. On Sept. 7, the party returned 3,400 BTC, worth about $272 million at the time and equal to 85% of the amount discussed in the article. It kept 598.5 BTC, roughly $47 million.
At first, the communication stayed private. Blockstream replied with encrypted and PGP-signed messages. On Sept. 8 and 9, however, the other side moved the exchange into public on-chain plaintext and changed tone.
- It accused Blockstream of negligence, claiming the company had spent only $1.5 million, or possibly even $0, to protect $5 billion in assets.
- It demanded an additional bug bounty equal to 10% from Blockstream’s own funds as a condition for returning the rest.
- It threatened that if Blockstream refused, “all your holders” would bear a 15% loss caused by what it called irresponsibility and stinginess.
By that point, the “white hat” label was facing obvious pushback. Ledger CTO Charles Guillemet, as cited in the article, said a genuine white hat would disclose a bug before moving collateral, not after. Draining 95% of reserves before opening talks looked “more like extortion than security research,” in his characterization.
The article contrasts this case with incidents involving Nomad, SafeMoon, and Team Finance, where large portions of stolen funds were returned and a portion was retained as a bounty. In those cases, the article says, there was usually a defined bounty structure, often around 10%. Here, the 15% figure was set unilaterally, with no agreed mechanism for who had the right to price that outcome.
Blockstream’s public refusal
Blockstream then issued a public statement saying it would not pay ransom for the return of stolen assets. The statement described unauthorized removal of assets followed by refusal to return them as criminal conduct, not responsible disclosure and not white-hat behavior. In the company’s words, “this is theft.”
The statement acknowledged that the company had engaged in good-faith communication, with the aim of recovering user funds and protecting the broader Bitcoin community. But it said that should not be read as accepting either the conduct or the demands.
Blockstream also said it would not create a precedent in which developers of open-source software for the Bitcoin community are forced to pay ransom that is “far beyond” their economic participation. In response to the threat that holders might absorb a 15% loss, the company stated that Bitcoin is hard money, cannot be minted at no cost, and would not be haircut to pay ransom.
The company offered two paths. If the remaining funds were returned now, the matter could still be treated under white-hat standards. If not, Blockstream said it would use all lawful means available and work with law enforcement, exchanges, service providers, and on-chain forensics specialists to trace assets and identify those responsible. The statement added that Bitcoin’s transparent design means transactions do not disappear, and neither does the evidence they leave behind.
The dispute is larger than the remaining 598.5 BTC
The article argues that the more important issue is not only the roughly $47 million still missing. Over the past few years, a pattern has become common in crypto incidents: drain funds first, call it white-hat action later, set a self-defined bounty, and let the victim negotiate under pressure. That pattern hands the pricing of a security incident to the attacker. The return ratio, the retained amount, and the pace of negotiations are all set on the attacker’s terms.
In that framing, Blockstream’s refusal was also a refusal to validate the script itself. The cost may be that the remaining funds are never recovered. The trade-off, in the article’s telling, is that the next attacker cannot assume a self-applied white-hat label will automatically produce a paid exit.
The article also notes a side discussion in the community. Three days before the incident, a new AI model had been released and described by some as the first able to independently discover unknown vulnerabilities. Some people speculated about a link, but the article says there is no evidence supporting that idea. Blockstream did mention AI in its statement, saying that advances in AI have changed the world and that the Bitcoin community is responding to the threat. The company did not say AI was used in this attack. Still, the decision to mention AI in the aftermath of a $320 million loss was itself presented as a sign of how the industry is viewing falling discovery costs for deep software flaws.
Where Liquid stands now
Liquid resumed block production at 12:26 UTC on Sept. 10, but has not yet resumed packaging user transactions. Peg-in and peg-out remain paused. The official recovery plan described in the article has three phases: restore block production first, then replay verified transactions, and only after confirming network health reopen the pegging operations.
After 3,400 BTC were returned, L-BTC backing recovered to about 86%. Blockstream co-founder Adam Back said publicly that the 1:1 L-BTC peg would be supported and urged holders not to panic-sell in over-the-counter markets.
With Blockstream now publicly refusing any additional payout, the remaining 598.5 BTC is no longer simply a negotiation issue. The article says it has become a tracing and recovery issue, likely involving on-chain forensics, exchange cooperation, and law-enforcement participation over a timeline measured in months or even years, with no certain result.
That also clarifies what the promise to support the peg means. The shortfall would be absorbed by Blockstream and the federation on their own balance sheets, rather than through a proportional haircut for L-BTC holders. For holders, the article says, the immediate risk is a liquidity freeze lasting days or weeks rather than a direct principal loss, assuming the support commitment is fully honored.
What the incident says about wrapped assets, privacy, and operations
The article closes with several practical takeaways.
First, wrapped or represented Bitcoin is not native Bitcoin. L-BTC, cross-chain BTC products, and other wrapped tokens function more like receipts than the underlying asset itself. Their safety depends on the strongest and weakest links across multiple layers: the issuer, the software implementation, and the redemption path. In this incident, the article says the break occurred at the software layer, while the redemption route carried the false balance forward. SideSwap was not blamed, because it had no way to tell that those units were unsupported at origin.
Second, visibility matters. Privacy is a real demand, but once reserve verification is weakened, outside parties lose the ability to catch a growing mismatch early. In this case, the discrepancy surfaced because different nodes accidentally produced different answers, not because the system had a built-in external proof of reserves.
Third, a user’s risk includes someone else’s maintenance schedule. A patch sitting for five months before deployment, or a codebase showing no meaningful updates for two years, may never appear in a white paper. It still shapes real-world asset safety.
Fourth, multisig remains useful, but it protects against bad actors with keys. It does not protect against bad code. If software already mistakes fake money for real money, multisig can only make the mistaken payout look orderly and legitimate.
Fifth, “white hat” is a behavioral standard, not a title someone can grant themselves. The article’s distinction is about sequence: disclose first and cooperate after, or drain first and name a price later.
From the perspective of custody practice, the article adds three operational warnings. Asset onboarding should not stop at evaluating the issuer; mint logic, redemption paths, and reserve verifiability also need review, and assets lacking independent verification should be separately classified and limited. Any accounting process that depends on a single data source is fragile, especially for critical on-chain states that can be cross-checked through two independent node providers. And address-level segregation with periodic reconciliation can reduce the blast radius when a single judgment call turns out to be wrong.
The article’s bottom line is not that one cache defect broke the system. It is that a trust chain only needs one weak layer, and operational reality can matter as much as formal design.