I have spent about four years running security at cryptocurrency exchanges. What happened on Liquid Network on 6 September 2026 is one of the most interesting incidents I have seen in that time, because it fits none of the usual patterns. No key was stolen, nobody fell for a phishing lure, the signing process worked exactly as designed, and 95% of the reserve still walked out the door. This post is my attempt to explain what it was and how it happened, in technical detail.

I. What Liquid Network is

Liquid is the oldest Bitcoin sidechain, launched by Blockstream in 2018. Its purpose is straightforward: settle transfers between exchanges and institutions quickly and confidentially, without writing every movement to the main chain. Bitcoin blocks arrive roughly every ten minutes and you wait several confirmations before treating a payment as final; on Liquid, blocks come once a minute and amounts can be hidden using Confidential Transactions.

The critical difference is in the security model. Liquid is not secured by mining. The reserve is held by fifteen dedicated signing units called functionaries, each holding one key to a shared wallet, and releasing Bitcoin from the reserve requires 11-of-15 signatures. In other words, Liquid trades proof-of-work for trust in a federation. That is a deliberate tradeoff, and it explains why this incident landed as hard as it did.

II. Why L-BTC exists

Bitcoin itself cannot circulate on Liquid, because Liquid is a separate chain with its own UTXO set. Instead there is a one-to-one representation of it: L-BTC.

The logic works like a custody receipt:

The entire security of the system rests on a single invariant: the circulating supply of L-BTC must equal the BTC held in the federation wallet. The moment that equality breaks, L-BTC becomes an uncollateralised IOU. That is exactly where this incident lives.

III. How a peg-out runs

A peg-out is not simply the mirror image of a peg-in, because in this direction money is leaving custody. So withdrawal authority on Liquid is constrained by a mechanism called PAK (Peg-out Authorization Key): an arbitrary address cannot request an exit, only authorised key holders can. In practice most end users go through a service such as SideSwap.

The flow looks roughly like this:

1. user      --L-BTC-->  peg-out service (SideSwap)
2. service: is this L-BTC valid? (node validation)
3. service: burn the L-BTC / create peg-out request
4. functionaries: validate request, check PAK authority
5. 11-of-15 signatures  -->  BTC payout on main chain

The critical link in that chain is step two. The system accepts incoming L-BTC as real, meaning backed by a peg-in, on the strength of the node's validation. Confidential Transactions make it impossible to eyeball the amounts; validity of an amount is established cryptographically, by what are called range proofs.

IV. The incident: 6 September 2026

A “customer” sends 4,000 L-BTC to SideSwap's peg-out service.
The federation pays out roughly 3,996 BTC through SideSwap's PAK.
Liquid's official statement: “purported white-hat hackers” withdrew 4,000 BTC; the PAK was not compromised.
Once the bridge nodes are patched, 3,400 BTC returns to the federation wallet.

The federation wallet held 4,200 BTC beforehand. The amount that left is 95% of the reserve, leaving roughly 197 BTC behind. At the price that day, about $320 million.

Every step here is legitimate by the system's own rules. SideSwap processed the request like any normal order, the L-BTC was burned, the functionaries verified PAK authority and signed. Neither the federation keys nor SideSwap's PAK were stolen. Nothing anywhere was “broken”.

V. The real vulnerability: unbacked L-BTC

The problem happened before the peg-out. Liquid's software, Elements, is a fork of Bitcoin Core, and a range-proof / validation cache bug in it allowed L-BTC to be created with no peg-in behind it. Nodes treated that L-BTC as valid, so the peg-out service burned it and the federation paid real BTC in exchange.

According to independent technical readings, the cache key did not adequately separate asset and script context, so the validation result of one proof was reused in a different validation. Roughly, this is the difference:

// buggy logic: key is just the proof digest
key = hash(rangeproof)
if (cache.has(key)) return VALID;   // no context

// expected logic: context is part of the key
key = hash(rangeproof, asset_id, commitment, script)
if (cache.has(key)) return VALID;

A validation cache is normally a perfectly safe optimisation: validating the same proof twice is wasted CPU. But if the cache key does not fully capture what the proof proves, a proof that is valid in one context appears valid in another. On a chain using Confidential Transactions the consequence is a direct loss of supply control, because that proof is the only thing holding the amount honest.

Some analyses suggest the bug appeared shortly before the incident, when an attempt to fix an older issue landed in master; despite not being in a tagged release, the functionary nodes were running that code.

For my own work, the real lesson is in that last sentence. The vulnerability itself is a cryptographic detail, but machines signing off on a $320 million reserve running code from master rather than a tagged release is a process problem. At an exchange, the equivalent rule is that no component holding signing authority should have a deploy path open to an unreviewed commit.

VI. A negotiation conducted on-chain

The withdrawn BTC was consolidated into a single address and an OP_RETURN was written to the chain:

OP_RETURN "we are whitehats. contact us on chain."

Blockstream answered through the same channel: a small satoshi transfer carrying a message signed with its published security key, which is the cryptographic way of telling the other side “this really is us”. Communication then moved to an encrypted channel. The actors' condition was explicit: patch the bug on every node first, then we will send most of the money back.

Meanwhile Liquid halted transactions, shut down the bridge nodes, and asked exchanges to suspend L-BTC deposits and withdrawals. Other assets on the network (USDT, DePix, tokenised RWAs) were not directly affected.

VII. Where it stands

On 7 September, once the bridge nodes were announced as patched, 3,400 BTC (about $268 million) returned to the federation wallet. The actors kept 598.5 BTC, roughly $47 million. That is almost exactly 15% of what left.

There is no public, signed bounty agreement. CertiK Alert, which reported the return, noted that the retained share could be a reward but that nothing confirms the parties agreed to such a payment. Ledger CTO Charles Guillemet was openly sceptical of the claim: if this was never a reward negotiated under a contract signed on-chain, it resembles extortion more than white-hat hacking.

A bug bounty is a contract: a scope, a rate, and a disclosure path agreed before anyone touches production. Here the order was inverted, and the fee was set after the reserve was taken hostage, without the paying side's consent. It is true that the alternative (all $320 million disappearing) would have been worse, but every incident closed this way makes the arithmetic easier for the next actor.

In short: no key was stolen, a software bug produced a peg-out that looked legitimate; the network stopped and L-BTC was effectively uncollateralised for a while; most of the money came back and roughly 600 BTC stayed with the actors. The custody model never broke. For a few blocks, it simply gave the right answer to the wrong question.