“White Hacker” Prints $320 Million of L-BTC, Backed by Nothing

Liquid’s Bitcoin sidechain drained yesterday (6th september, 2026), without a stolen key, compromised multisig, or direct attack on the Bitcoin blockchain. A flaw in the software that verifies confidential transactions appears to have allowed unbacked L-BTC to pass as legitimate—and a normal peg-out process turned those tokens into roughly 4,000 real BTC.

Yesterday Liquid Network experienced one of the strangest major crypto security incidents in recent memory. Roughly 4,000 BTC, worth about $320 million at the time, left the Liquid Federation’s Bitcoin reserve, representing around 95% of the approximately 4,200 BTC held there before the incident. Liquid has to subsequently disable its bridge nodes, exchanges paused L-BTC deposits and withdrawals, and the sidechain effectively froze while developers investigated.

Whats most surprising is that this was not a conventional bridge hack. No federation keys were stolen. No SideSwap key was compromised. No Bitcoin consensus rule was broken nor any phishing claims gave away access. The Bitcoin mainnet itself was never hacked.

Instead, the incident appears to have exploited a flaw in Elements Core, the open-source software underlying Liquid Network’s confidential-transaction system. The flaw enabled the creation of non-existent L-BTC without depositing an equivalent amount of Bitcoin into Liquid’s federation reserve. The counterfeit L-BTC then went through a perfectly legitimate redemption process and sideSwap (Liquid Network’s settlement layer) processed it.

The federation of Liquid signed the peg-out, enabling the bitcoin to be moved. The system did exactly what its rules told it to do.

The Verification Flaw

Caching range proofs during transaction verification exposed the suspected vulnerability. Range proofs allow Liquid nodes to verify that confidential transaction amounts are valid without revealing the amounts themselves. The issue has allowed a previously verified proof to be reused in a different context.

The Elements fix tied additional transaction information, including the asset and output script, to identify these cached proofs differently. That detail is significant because it points to a software implementation flaw rather than a failure of the underlying cryptography. The attacker appears to have exploited that flaw to cause the network to accept invalid L-BTC.

How Fake L-BTC into Real Bitcoin

They exploited the vulnerability, and the sequence became simple.

A vulnerability in Liquid’s transaction-validation software allowed the hackers to create unbacked L-BTC tokens and exchange them for real BTC.

The federation wallet reportedly held around 4,200 BTC before the incident.  The attacker removed roughly 95% of the reserve, leaving about 197 BTC. The attacker did not need to break the Bitcoin network. They only needed to make Liquid believe that the Bitcoin represented by the L-BTC already existed.

The most important clue is sitting in the Elements source code. The Liquid network relies on Elements Core, a Bitcoin Core-derived implementation that adds Confidential Transactions, assets, the federated peg, and other functionality. Liquid nodes independently validate transactions and blocks using this software.

We believe one optimization speeds up Confidential Transaction range-proof verification and contains a vulnerability.

Liquid does not reveal transaction amounts. Instead, a cryptographic commitment represents the amount, and a range proof confirms the committed value remains within the permitted range. Without that proof, a malicious transaction could theoretically use a negative hidden amount to balance an arbitrarily large positive output—effectively creating assets from nothing.

Range-proof verification is computationally expensive, so Elements caches successful verification.

That optimization is where the problem appears to have been.

The cache remembered too little

The relevant function in Elements was:

void SignatureCache::ComputeEntryRangeProof(
    uint256& entry,
    const std::vector<unsigned char>& proof,
    const std::vector<unsigned char>& commitment
) const

hasher
    .Write(proof.data(), proof.size())
    .Write(commitment.data(), commitment.size())
    .Finalize(entry.begin());

That looks reasonable at first glance. Those two values do not define a Liquid confidential output. It also has an asset commitment and an output scriptPubKey. Those elements form the context in which the proof is evaluated.

The eventual fix changes exactly this. The patched function now takes four pieces of context:

proof
value commitment
asset commitment
scriptPubKey

and incorporates all four into the cache key:

hasher
    .Write(proof.data(), proof.size())
    .Write(commitment.data(), commitment.size())
    .Write(asset_commitment.data(), asset_commitment.size())
    .Write(scriptPubKey.data(), scriptPubKey.size())
    .Finalize(entry.begin());

That four-line change is arguably the most revealing piece of evidence currently available.

Why does that matter?

The cache should answer a very narrow question, and the vulnerable implementation effectively asked a weaker question.

Have I already verified this exact cryptographic statement? ||. Have I already verified this proof with this value commitment?

Those are not necessarily the same thing in a multi-asset confidential transaction system.

A useful way to think about it is:

Before:Cache key = H(range_proof || value_commitment)

After:
Cache key = H(
    range_proof ||
    value_commitment ||
    asset_commitment ||
    scriptPubKey
)

The difference is small in code but enormous in a consensus-critical system.

If two different transaction contexts can produce the same cache entry, the second verification can potentially become a cache lookup instead of a fresh cryptographic verification. And that is exactly what the vulnerable code does.

Inside CachingRangeProofChecker::VerifyRangeProof(), Elements first computes the cache entry and then calls:

if (rangeProofCache.Get(entry, !store)) {
    return true;
}

The exploit theory: make the node remember a valid proof, then reuse the memory

On-chain researchers reconstructed attack sequence using crafted transactions to place identical range proofs in Liquid caches before the inflation event.

Bitquery identified 68 transactions carrying an identical range proof over roughly 14 hours before the main withdrawal. Researchers believe these transactions were used to prime the cache by unknown parties. Bitquery explicitly cautions that the connection between those transactions and the publicly observed source-code fix remains a reconstruction rather than an official confirmation from Blockstream.

The conceptual attack is easier to understand without reproducing the exploit itself.

Imagine a node has already evaluated:

Proof P + Commitment C
        ↓
      VALID
        ↓
   cache entry X

Proof P + Commitment C
+ different asset context
+ different script context

Which still resolve to the same cache entry. If the node finds X in its cache, the code path shown above returns true.  The expensive range-proof verifier never gets another chance to examine the new context. This is why describing the vulnerability simply as a “bad range proof” is misleading. The mathematical proof itself did not appear to be broken in this case. The problem arose from the identity assigned to a previously verified proof.

The Thin Boundary Between Verification and Caching

We describe the Liquid incident as a consensus-critical cache-key failure rather than as a conventional bridge hack. The federation’s security controls were still operating. The SideSwap authorization mechanism was still operating. The Bitcoin blockchain was still operating. The failure happened earlier, when Elements had to answer a much simpler question: Is this confidential transaction actually valid? The network appears to have had a situation where the answer could become: I already checked something with this cache key.

That sentence is perfectly safe in an application. In consensus software, it can be catastrophic. Because once a cached true becomes equivalent to a fresh cryptographic verification, the cache itself becomes part of the consensus boundary. And in this incident, that boundary appears to have been where the $320 million problem began. Liquid paused the network in response, disabling its bridge nodes, which prevented new transactions from being submitted to the network.

Exchanges were also notified and began pausing L-BTC deposits and withdrawals. Liquid reported that the incident left other assets on the network, including USDT, DePix, and RWAs, unaffected. With the team currently identifing how the counterfeit L-BTC originated, patch all affected nodes, and evaluate whether any other wallets or applications accepted the invalid tokens.

White Hats or Black Hats?

The party behind the exploit has claimed to be white-hat hackers and has communicated with Blockstream through on-chain messages. They have reportedly indicated their plan to return most of the stolen Bitcoin once they fix the vulnerability. That has not yet resolved the incident. The funds remain an important part of the investigation, while Blockstream and the Liquid Federation work to restore the network.

Failure of Verification Turns Costly

The Liquid incident is notable because the usual defenses did not fail in the conventional way unlike most of the recent hacks. There was no leaked private key. There was no compromised federation multisig.

)There was no attack on Bitcoin’s foundation itself (thank god, but quantum threat is coming soon). The verification process failed to determine whether the asset being redeemed were real or fake. That makes the incident particularly important for Bitcoin sidechains and other systems that move assets between networks.

Someone stole the key that controlled the Bitcoin, preventing the liquid from draining. The system accepted Bitcoin-backed tokens that lacked Bitcoin backing, draining the account.

Current Status:

As of the latest available reporting on September 7, Liquid remains paused, with bridge nodes disabled and L-BTC deposits and withdrawals suspended at exchanges. Blockstream told the party holding the funds that the bridge nodes were patched. The party holding the funds had not yet publicly confirmed the return of approximately 4,000 BTC at the time of publication.

Our team continues to investigate the incident, and we will treat the technical explanation as provisional until Blockstream and Liquid publish a formal post-mortem.

Sources: Liquid Network, SideSwap, Elements Project, Reuters, The Block, BlockCritics research guides, and independent on-chain analysis.

Updated Status: The white hackers have returned the money minus a 10% reward.