Worked example · 2026-09

Liquid Network — unbacked L-BTC passed consensus, so the federation's 11-of-15 signers approved a peg-out that was valid in every way they were built to check — Liquid Network (Blockstream) / Bitcoin sidechain — 2026-09-06

Loss: ~$320M — 3,996.01834922 BTC paid out on a single peg-out, plus 2.65138358 BTC and 3.99601658 BTC in two follow-on batches, for ~4,002.67 BTC total. The federation's Bitcoin reserve went from ~4,200 BTC that morning to 197 BTC. The recipient has held 3,998.50 BTC unspent since, published an OP_RETURN reading "we are whitehats. contact us on chain", and — per Blockstream on 2026-09-07 — is negotiating a return conditioned on every bridge node being patched first. As of 2026-09-07 no funds had moved back, so this entry records a loss, not a recovery; the disposition is open. Third-largest crypto theft of 2026 to date by value moved.
OAK Techniques observed: OAK-T9.014 (Protocol-Client Consensus Bug — primary. The defect is in Elements, the reference client that defines Liquid's consensus, not in any smart contract or key. Blockstream's own statement is that the L-BTC came from an Elements bug and that "the SideSwap key was not compromised, nor were any others." See techniques/T9.014-protocol-client-consensus-bug.md). Three neighbouring Techniques explicitly do not apply, and saying so is the point of the case. OAK-T10.001 (Validator / Signer Key Compromise) — no key was stolen; enough functionaries signed voluntarily and correctly. OAK-T11.003 (Multisig Contract Manipulation) — the 11-of-15 threshold was not bypassed, degraded, or tricked; it was met. OAK-T5.003 (Hidden-Mint Dilution) — there was no mint authority to exercise; the supply was produced by consensus-layer validation failing to reject it.
Attribution: pseudonymous. On-chain identifiers only, plus PGP-signed Bitcoin messages to Blockstream. Funds consolidated to bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte. The party self-identifies as white-hat; Blockstream has not verified that claim and used the word "purported." OAK records the mechanism and treats the self-description and the pending return as disposition metadata, not as a reclassification of the event.
Key teaching point: A threshold signature can only attest to the questions its signers are built to ask, and "should this coin exist?" was not one of them. The functionary HSMs checked that the peg-out went to a whitelisted address and that the L-BTC burned matched the BTC requested. Both were true. The burned L-BTC was itself unbacked, and no part of the federation was responsible for knowing that — it was delegated to consensus rules that had silently stopped enforcing the invariant. So 11-of-15 hardware modules, an audited whitelist, and a working peg-out authorisation system all functioned exactly as designed while paying out 95% of the reserve. When a signing quorum sits downstream of a consensus check, the quorum inherits that check's correctness and adds nothing to it. The reusable control is not more signers or better key custody: it is a reserve-side invariant the federation enforces itself — total circulating L-BTC must equal BTC held, checked before signing, not derived from the same consensus that produced the request. That number was public and wrong for hours: explorers disagreed about block 4,050,336 (Blockstream's accepted it, mempool.space rejected it and stalled at 4,050,335), and afterwards the reserve read 197 BTC against ~4,205 L-BTC in circulation.

Summary

Liquid Network is a Bitcoin sidechain run by a federation of functionaries. BTC is locked on Bitcoin and L-BTC is issued 1:1 on Liquid; exiting requires a peg-out, in which the federation's 11-of-15 signers release real BTC from the reserve. Liquid uses Confidential Transactions, so amounts are hidden behind Pedersen commitments and validated by range proofs. Peg-outs are gated by Peg-out Authorization Keys (PAKs); SideSwap, a peg-out partner, holds a whitelisted PAK and builds peg-outs on customers' behalf from its own wallet.

On 2026-09-06 a transaction created L-BTC that was never backed by BTC. Because amounts are confidential, the extra coins were invisible to every observer — as one analysis put it, when the verification is wrong, nobody can see the difference. The unbacked L-BTC was routed through SideSwap's normal peg-out flow. SideSwap "had no way to tell those coins from any other L-BTC." At 14:28:56 UTC the federation paid 3,996.01834922 BTC to a fresh Bitcoin address.

Blockstream confirmed the bug was in Elements and that no keys were compromised. Blockstream has not published the specific defect. Independent analysis attributes it to the range-proof verification cache: the cache key covered the proof hash and value commitment but omitted the asset commitment and the output script, so a proof verified once could be replayed in a different asset/script context and accepted — a consensus-level inflation bug. A matching upstream fix exists (commit 212c43f4, 2026-08-03, adding asset commitment and output script to the cache key), and its cherry-pick to the 23.3.x branch (PR #1599) merged at 17:21 UTC on 2026-09-06 — about three hours after the peg-out confirmed. The current release at the time, 23.3.3 (2026-04-13), did not contain it. No CVE has been assigned. OAK records the cache mechanism as strong independent analysis corroborated by an upstream commit, not as operator-confirmed.

The signature of a consensus bug was visible in public infrastructure before anyone diagnosed it: block 4,050,336 was accepted by Blockstream's explorer and rejected by mempool.space, whose chain tip stopped at 4,050,335. Two nodes running what should be the same rules reached different verdicts on the same block.

Timeline (UTC, 2026-09-06 unless noted)

When	Event	OAK ref
2026-04-13	Elements 23.3.3 released — the shipped build lacking the later cache fix	(standing T9.014 surface)
2026-08-03	Upstream commit `212c43f4` adds asset commitment + output script to the range-proof verification cache key	(upstream fix exists, unshipped)
13:53:10	Disputed Liquid block 4,050,336 signed; Blockstream's explorer accepts it, mempool.space rejects it and stalls at 4,050,335	T9.014 — consensus divergence, observable in public
~14:05	4,000 L-BTC sent into SideSwap's peg-out service; SideSwap builds the peg-out with its own whitelisted PAK	(legitimate path, unbacked input)
14:06:10	Peg-out transaction in Liquid block 4,050,349	T9.014 exploitation
14:28:56	Bitcoin block 965,783: federation pays 3,996.01834922 BTC from `bc1qdlld6a…uhwxxr`; 11-of-15 HSMs sign — whitelist check and burn-amount check both pass	(quorum met, invariant unchecked)
16:01:28 / 16:48:45	Two follow-on peg-out batches process (2.65138358 and 3.99601658 BTC)	(continued drain)
18:23:18	An independent researcher flags the transaction publicly	(external detection)
18:30:10	Bitcoin block 965,818: recipient's OP_RETURN — "we are whitehats. contact us on chain"; 1,000 sats sent to the federation wallet to guarantee visibility	(disposition signal)
17:21	PR #1599 cherry-picks the cache fix into the `23.3.x` branch — ~3 hours after the peg-out confirmed	(patch lands post-hoc)
20:25	Blockstream statement: Elements bug, no keys compromised, bridge nodes disabled	(operator response, T+5h56m)
2026-09-07	Blockstream says bridge nodes are patched and safe for funds to be returned; PGP-signed messages exchanged; recipient conditions return on all nodes being patched. No BTC returned as of this date.	(open disposition)

What defenders observed

The multisig was never the control it appeared to be. Every published defence of Liquid's security model rests on 11-of-15 hardware functionaries. That quorum answered its two questions correctly and released 95% of the reserve, because the question that mattered — is this L-BTC real? — was answered upstream by consensus code and simply passed through. A quorum downstream of a broken check ratifies the break.
Confidential Transactions removed the observer of last resort. In a transparent chain, an inflation bug shows up as arithmetic anybody can redo. Under Pedersen commitments the amounts are hidden by design, so a verification failure produces no visible artefact at all. Privacy at the value layer means the supply invariant must be enforced by explicit accounting, because it can no longer be spot-checked by inspection.
Client disagreement was the earliest available alarm and nobody was wired to it. Two independent explorers disagreed about block 4,050,336 roughly 13 minutes before the peg-out. Cross-implementation validity divergence is the canonical T9.014 detection surface, it was firing in public, and it was noticed only when a researcher looked, at 18:23 — four hours after the money left.
The fix existed upstream for 34 days and shipped three hours late. 212c43f4 landed 2026-08-03; the release in production was from April. This is the T9.014 response-latency problem in its sharpest form: patch availability and patch deployment are different states, and only the second one is a control.
A reserve-parity check is cheap, external, and would have fired. Circulating L-BTC versus BTC held in the federation address is two numbers from two chains. Enforced as a pre-signing condition inside the functionaries, it makes a consensus inflation bug non-monetisable through the peg-out path regardless of what the consensus code believes.
The peg-out partner was structurally unable to help. SideSwap did nothing wrong and could not have: its whitelisted PAK is an authorisation instrument, not a validation one, and it had no means to distinguish backed from unbacked L-BTC. Delegated peg-out authority scales the blast radius of a consensus bug without adding a check anywhere.

Public references

[defiprimeliquid2026] — DeFiPrime, "The Liquid Network Exploit: $320M Pegged Out, Every Key Intact" (block heights, UTC timeline, the range-proof cache key analysis, HSM check semantics, explorer divergence, commit 212c43f4 and PR #1599): https://defiprime.com/liquid-network-peg-out-exploit
[cryptobriefingliquid2026] — Crypto Briefing, "Blockstream confirms bridge nodes patched, funds safe to return after $320M Liquid Network exploit" (2026-09-07; PGP-signed Bitcoin messages, return conditioned on patching): https://cryptobriefing.com/blockstream-liquid-network-exploit-funds-return/
[cryptoslateliquid2026] — CryptoSlate, "A whitehat hacker is holding $320 million in drained Bitcoin until developers prove they patched a fatal network flaw": https://cryptoslate.com/a-whitehat-hacker-is-holding-320-million-in-drained-bitcoin-until-developers-prove-they-patched-a-fatal-network-flaw/
[shatteredliquid2026] — Shattered, "Liquid Network Hack: $320M Bitcoin Sidechain Exploit" (peg-out mechanics, PAK whitelist, unverified white-hat status as of 2026-09-07): https://shattered.io/liquid-network-320-million-hack-2026/
[cryptotimessept2026] — The Crypto Times, "Crypto Hacks Reached $322M in September's First Week" (2026-09-07; Liquid as >99% of the week's reported total): https://www.cryptotimes.io/2026/09/07/crypto-hacks-cross-322m-in-septembers-first-week-as-liquid-network-alone-loses-320m/
[spaziocryptoliquid2026] — Spazio Crypto, "Liquid Network: 4,000 BTC Exit in $320M Software Bug Exploit" (reserve before/after, federation halt): https://en.spaziocrypto.com/security/liquid-network-4000-btc-reserve-crisis-blockstream-sidechain-halted/

Discussion

T9.014 has been the corpus's thinnest well-defined Technique: one canonical anchor from 2010 (the Bitcoin value overflow bug), one unexploited disclosure (Zcash Orchard, 2026-06), and a pipeline of near-misses. Liquid is the first fully-exploited consensus bug in the corpus since 2010 and the first outside Bitcoin Core itself, which makes it the anchor the Technique's promotion criteria were written for. The two full-exploit anchors rhyme structurally — an arithmetic/validation defect in the client that defines consensus, producing coins that violate the supply invariant — and diverge in a way worth recording: in 2010 the fraudulent 184.5 billion BTC was visible to anyone who read the block, and the fix landed in about five hours. In 2026 the fraudulent supply was cryptographically hidden, the bug was diagnosed from the outside, and the money was gone before anyone framed the question.

What generalises beyond Liquid is the layering error, not the cache bug. Liquid's public security story is a federation: hardware modules, geographic distribution, a signing threshold. Everything in that story was intact. The federation was never validating whether the sidechain's money supply was sound — it was validating that a request was well-formed and whitelisted, and inheriting soundness from consensus. Any system with this shape — a signing quorum, bridge committee, or attestation set that acts on a request whose validity was decided upstream — has the same property: the quorum's guarantee is capped by the weakest check it does not perform. Contributors documenting incidents in this class should record, explicitly, which invariant the signers checked and which one they assumed, because the gap between those two is where the loss lives.

The near-miss on the patch deserves its own note for the T9.014 record. The fix was in the upstream tree for over a month, the cherry-pick to the shipping branch merged three hours after the money left, and the deployed release predated the fix by four months. Nothing about that is unusual, which is exactly the problem: for a chain whose consensus is one client, "the fix exists" and "the fix is running" are separated by an interval an attacker can read off a public repository.