Thirty-Six Minutes From Mint to Payout: How the Liquid Bug Actually Worked

The Elements range proof bug let attackers mint roughly 4,000 unbacked L-BTC and withdraw real bitcoin against it, from first mint to federation payout in 36 minutes.

On this page

• The Elements range proof bug mechanism
• The timeline
• Why the federation signed it
• What this means for confidential systems generally
• What has been done
• What is still missing
• What to watch
• Why this class of bug is so hard to catch

The first accounts of the Liquid Network exploit described a flaw in the peg-out authorisation path. The technical analysis that followed says something different and considerably more interesting.

The attackers did not steal bitcoin that was there. They created L-BTC that never had bitcoin behind it, and then withdrew real bitcoin against it.

The Elements range proof bug mechanism

Liquid uses confidential transactions, which hide the amounts being moved. Because amounts are hidden, the network cannot simply check that inputs equal outputs. Instead it verifies a range proof — a cryptographic attestation that a hidden value falls within valid bounds and, critically, that no value was created out of nothing.

Range proof verification is expensive, so the validation software caches results. A flaw in that cache appears to have let an invalid output pass as though it had already been verified.

Once that check can be skipped, the confidentiality that protects users becomes the thing that hides the fraud. Nobody watching the chain could see that the amounts did not add up, because the amounts are not visible by design.

The timeline

Thirty-six minutes from creating fake tokens to holding real bitcoin.

Why the federation signed it

This is the part that corrects the initial reporting, and it matters for every other federated bridge.

The eleven-of-fifteen multisig did exactly what it is designed to do. It received a peg-out request, verified that the requester held the L-BTC being burned, and released the corresponding bitcoin. The L-BTC was in the requester's possession. The burn was valid. The signature threshold was met.

The failure happened one layer earlier, at issuance. By the time the federation saw the withdrawal, the fraudulent tokens were indistinguishable from legitimate ones.

A threshold signature scheme guarantees that enough parties agreed. It guarantees nothing about whether the thing they agreed to was created honestly.

What this means for confidential systems generally

Confidential transaction schemes trade auditability for privacy, and the range proof is what buys back the auditability. It is the single mechanism preventing inflation in a system where you cannot see the numbers.

That makes range proof verification the highest-consequence code path in any such system. A caching optimisation there is not a performance detail; it sits directly on the solvency guarantee.

The same architectural shape appears in other confidential and shielded systems. Whether the specific caching flaw generalises is exactly what a technical post-mortem would answer, and it has not been published.

There is a broader point about supply verification. On Bitcoin, anyone can sum the UTXO set and confirm the total supply. On a confidential chain, nobody can. Users are trusting that the range proof code is correct, and here it was not.

What has been done

Blockstream patched the bridge nodes and confirmed funds were safe to return. The attackers returned 3,400 of the roughly 4,000 BTC, retaining 598.5 BTC — about $47 million — as a self-declared bounty.

The Liquid Network remains paused, and exchanges have not resumed L-BTC trading.

What is still missing

A technical post-mortem. Every federated bridge and confidential-transaction system needs to know whether this flaw is specific to Liquid's Elements implementation or generic to the pattern.

A supply audit. Confirmation that no other unbacked L-BTC exists from earlier, undetected use of the same flaw. Given that the exploit was invisible on-chain by design, this is not a trivial question.

A monitoring answer. The attack ran for 36 minutes with no automated detection. What triggers an alert next time is a design question, not a patch.

What to watch

The Elements release notes. The patch is public code. The diff will tell the story before any blog post does.

Whether the pause lifts. Resuming without a published post-mortem would be a choice worth noting.

Other confidential systems. Any project using similar range proof caching should be reviewing it now, and disclosure of that review is the responsible move.

L-BTC's price on resumption. With 598.5 BTC unreturned against roughly 4,200 BTC of normal reserves, a shortfall near 14% remains unless someone covers it.

Why this class of bug is so hard to catch

Caching bugs occupy a specific blind spot in software assurance.

Tests verify that code produces correct outputs for given inputs. A cache is correct in exactly that sense — it returns the right answer for anything it has genuinely seen. The failure happens when it returns an answer for something it has not seen, which requires a test that deliberately constructs a cache-key collision.

Nobody writes that test unless they are specifically looking for it, because the cache is an optimisation and optimisations are assumed not to change behaviour.

Formal verification does catch this class, because it proves the cached path and the uncached path are equivalent for all inputs rather than for tested ones. It is notable that the Ethereum Foundation listed formal verification as cross-cutting tooling across its entire post-quantum programme in the same week this incident happened.

About this report. The mechanism, block number, timestamps and amounts are from TRM Labs' analysis and reporting by The Hacker News and Crypto Briefing, 7-9 September 2026. The description of the caching flaw follows TRM's wording that a flaw in the cache may have let an invalid output pass as already verified. No technical post-mortem has been published.

Not investment or security advice. Technical details remain subject to revision.

Frequently asked questions

What was the Elements range proof bug?

A flaw in the caching mechanism of Liquid's validation software. Range proofs are cryptographic attestations that a hidden transaction value falls within valid bounds and that no value was created from nothing. According to TRM Labs, a flaw in the cache may have let an invalid output pass as already verified.

How long did the attack take?

Thirty-six minutes. Roughly 4,000 L-BTC were minted with no backing at 13:53 UTC on 6 September in block 4,050,336, a withdrawal was submitted through SideSwap at 14:06, and the federation paid out around 4,000 BTC at 14:28.

Why did the federation approve the withdrawal?

Because by the time it saw the request, the fraudulent tokens were indistinguishable from legitimate ones. The eleven-of-fifteen multisig verified that the requester held the L-BTC being burned and released the corresponding bitcoin. The failure happened one layer earlier, at issuance.

Could this affect other confidential-transaction systems?

Unknown, and that is the problem. No technical post-mortem has been published. Range proof verification is the single mechanism preventing inflation in any system where amounts are hidden, and a caching optimisation there sits directly on the solvency guarantee.

Sources

• 2026's Biggest Hack To Date: Attackers Drained $319 Million From Liquid Network — TRM Labs
• Liquid Hackers Return 3,400 Bitcoin Taken via Elements Bug — The Hacker News
• Blockstream confirms bridge nodes patched, funds safe to return — Crypto Briefing
• Liquid Network Hack: $320M Bitcoin Sidechain Exploit — Shattered.io