This week's report covers the largest single incident in crypto so far this year by funds moved: about 3,996 BTC leaving the Liquid Network federation reserve on 6 September 2026.
We chose it not only for its size but because it fails in an unfamiliar direction. There was no broken contract, no compromised key and no defeated multisig. The tokens were created upstream, and every system that later handled them behaved correctly.
1 1. In brief
On 6 September 2026, about 3,996 BTC left the Liquid Network federation wallet — roughly $320m at prevailing prices, and close to 95% of the reserve backing every L-BTC in circulation. No key was stolen. No multisig was defeated. The attacker minted tokens that should not have existed and then walked them through the official exit.
That sequence is the reason this report exists. Everything downstream of the mint behaved correctly: SideSwap processed a normal redemption, the federation validated a valid authorisation, and 11 of 15 members signed a legitimate withdrawal. The failure was a caching optimisation in the platform's core software, and it sat in a tagged release while a merged fix waited to ship.
2 2. Background: what Liquid is, and what the reserve is for
Liquid launched in 2018 as a federated Bitcoin sidechain built by Blockstream. A user locks BTC in a wallet controlled by the federation and receives L-BTC on the sidechain. Burning L-BTC redeems an equivalent amount of mainnet Bitcoin from that same wallet. The arrangement buys confidential transaction amounts and fast settlement at the cost of a custody assumption: the peg is only as good as the federation's willingness and ability to honour it.
Two details matter for what follows. First, L-BTC is fungible and its amounts are hidden, so no observer can tell from the chain how much of it is properly backed. Second, other assets issued on Liquid — stablecoins, real-world-asset tokens — do not draw on the federation's Bitcoin. Only L-BTC holders were exposed to the reserve.
| Property | Liquid Network | Bitcoin mainnet |
|---|---|---|
| Consensus | Federated functionary set | Proof of work, permissionless |
| Who can validate | Federation members only | Anyone |
| Reserve control | Multisig across functionaries | None — self-custody |
| Amount visibility | Confidential transactions | Amounts public |
| Exit mechanism | Peg-out authorised by federation | No exit needed |
None of this made the incident inevitable. It did mean that a software bug could reach the reserve in a way that a bug on mainnet cannot: the chain does not independently verify that its own money supply corresponds to what the federation holds.
3 3. Mechanism: five steps, none of them exotic
Reconstructing the sequence from Blockstream's statement, SideSwap's account and independent technical analysis gives a path with no step that required breaking anything.
| # | Step | What happened | Why it passed |
|---|---|---|---|
| 1 | Mint | More than 4,000 L-BTC created on Liquid with no BTC locked behind them | Confidential amounts hid the inflation |
| 2 | Transfer | The tokens moved to a SideSwap redemption address | Indistinguishable from legitimately issued L-BTC |
| 3 | Burn | 4,000 L-BTC destroyed at 14:05 UTC to request a peg-out | The burn was valid; the tokens existed |
| 4 | Authorise | A peg-out authorisation was issued and 11 of 15 members signed | The process checked the process, not the origin |
| 5 | Pay | About 3,996 BTC released at 14:28 UTC, less roughly 0.1% in fees | Federation keys were used correctly |
The step that fails safely on a well-designed bridge is step 4. A peg-out authority can check that tokens were burned; it rarely checks that the tokens were ever correctly minted, because until this week that seemed to be guaranteed upstream.
4 4. Root cause: a cache key that forgot what it was caching
Confidential transactions hide amounts while still proving validity. Liquid implements them through range proofs: cryptographic evidence that a hidden value is non-negative and within bounds. Verifying range proofs is expensive, so Elements caches verification results.
The reported defect is in how that cache was keyed. A cache key must bind every input that affects the answer. This one appears to have omitted the asset commitment and the output script, meaning a proof already accepted for one asset and destination could satisfy a different asset and a different destination.
In plain terms, the system remembered that a proof was valid and stopped asking what it was valid for. Reusing that answer let the attacker create L-BTC that passed verification without any Bitcoin behind it.
5 5. Three failures that all had to line up
It is tempting to file this under 'a bug was exploited'. That understates it. Three separate controls were available and none of them stopped the payout.
| Layer | Control that existed | Why it did not fire | Cost of preventing it |
|---|---|---|---|
| Code | Range-proof verification | Cache returned a stale verdict for a new context | Correct cache key would have cost nothing at scale |
| Process | Federation multisig review | Every signature was legitimate; no member was asked about provenance | Supply reconciliation check before release |
| Release | Fix existed and was merged | Not included in the tagged build running at the time | Backporting the merge into the release |
The third row deserves separate attention. Reporting indicates the fix was written over the summer and merged early this month, but was absent from the release running during the incident. A patch that exists is not a patch that protects anyone.
6 6. Data: the numbers, and what each one measures
This incident produced several quantities at once. They are different measurements, not competing estimates, and quoting any of them as 'the loss' without saying which is how reporting on it goes wrong.
| Quantity | Value | What it measures | Source |
|---|---|---|---|
| L-BTC sent to redemption | 4,000 L-BTC | Tokens burned to request the peg-out | SideSwap |
| BTC actually paid out | ~3,996 BTC | Paid after roughly 0.1% in fees | SideSwap |
| Value at request time | ~$320m | Quoted at prevailing BTC price | Multiple |
| Reserve before | ~4,200 BTC | Federation wallet balance before transfer | Blockstream |
| Reserve after | ~197-207 BTC | Sources differ slightly on the exact remainder | CoinPost, others |
| Share of reserve taken | ~95% | Withdrawal relative to prior balance | Derived |
| Weekly total crypto drains | ~$322m | 1-7 September across all reported protocol incidents | CoinPost Terminal |
| Liquid share of that total | >99% | One incident dominating the period | Derived |
The derived items are worth stating plainly. If about 3,996 BTC left a reserve of about 4,200 BTC, roughly 95% of the backing went with it, and every remaining L-BTC is backed by about five cents of Bitcoin if no recovery occurs.
That ratio, not the dollar figure, is the operational exposure for anyone holding L-BTC.
7 7. The same shape, twice more in six days
Liquid was the largest instance of a pattern that appeared three times in this reporting window. In each case value was created upstream and accepted downstream by systems behaving as designed.
| Date | Venue | How value was created | Realised loss | Contained by |
|---|---|---|---|---|
| 31 Aug | ankrFLOW / Flow | About 8.6m unbacked ankrFLOW minted and used as collateral | ~$410k | Flow Foundation reimbursement |
| 5 Sep | Rocket | Self-trades at inflated prices generated artificial profit | ~$287k | Platform pause, then socialisation |
| 6 Sep | Liquid Network | Unbacked L-BTC minted through a cache flaw and redeemed for BTC | ~$320m | Bridge nodes off, trading paused |
Scale apart, the resembly is in the failure to ask provenance questions. Collateral checks verified that tokens existed and were transferable; redemption flows verified that tokens were burned. None asked whether they were legitimately created.
8 8. Impact assessment: four layers, different speeds
| Layer | Who is affected | Immediate effect | Resolution depends on |
|---|---|---|---|
| L-BTC holders | Anyone holding the pegged asset | Backing collapsed to about 5% | Whether the attacker returns funds |
| Liquid users generally | Stablecoin and RWA token holders on the chain | Unaffected at the ledger level | Nothing — these do not draw on the reserve |
| Exchanges and members | Federation participants and their customers | Deposits and withdrawals halted | Patch deployment and network restart |
| Sidechain category | Other federated and committee-run bridges | Reputational re-pricing | Post-mortem quality across the category |
The clean separation between layers is the most useful thing here. Assets that never relied on the federation's Bitcoin were not impaired by its emptiness, which is a reminder that 'exposure to a chain' is not one risk but several, depending on which asset you hold on it.
9 9. The claim of white-hat status
The attacker left an on-chain message reading 'we are whitehats. contact us on chain', and subsequent exchanges included a request that the bug be fixed and nodes patched, and a question about whether returning most of the funds would be acceptable. Some reports describe a 20% bounty request; that figure has not been confirmed by either party.
Blockstream's language has stayed at 'purported white-hat'. That caution is justified. Responsible disclosure is a process agreed in advance, not a label applied after funds have left. Roughly 95% of a reserve was moved without authorisation, regardless of intent, and the only commitments offered so far are messages.
10 10. Risk matrix
| Risk | Likelihood now | Severity | What would reduce it |
|---|---|---|---|
| Permanent loss of the reserve | Unresolved | Severe | Verifiable return before network restart |
| L-BTC trading far below peg | High while unresolved | Severe for holders | Reserve restoration or a stated compensation plan |
| Restart before all nodes patch | Medium | Severe | Attested patch deployment by federation members |
| Same flaw in Elements forks | Unverified | High | Independent audit of the fix across downstream projects |
| Contagion to L-BTC integrations | Medium | Moderate | Integrations disabling deposits until backing is restored |
11 11. What this changes for due diligence
- For bridged and pegged assets: ask what verifies that supply was legitimately minted, not just that it exists and transfers.
- For committee-run systems: ask who can pause a withdrawal and whether any participant is required to reconcile total supply against total reserves before release.
- For any dependant product: check whether your asset's backing is the same pool someone else's redemption draws from.
- For performance-critical code paths: treat caching layers as security boundaries and review what the cache key binds.
- For release processes: ask whether merged fixes are in the running tagged build, not whether they are in the repository.
12 12. What would change our read
Our assessment rests on the account available at publication. It would change materially if Blockstream's post-mortem attributes the incident to a different cause than a cache-key defect, if the fix proves to have been present in the running release, or if the funds are returned under verifiable terms. Any of those would move specific sections above. Until the post-mortem is published, every figure quoted here should be treated as provisional.
The broader conclusion does not depend on those details. Three incidents in seven days turned on inputs that were never checked for provenance, and the largest of them nearly exhausted a reserve because every downstream control verified procedure rather than substance.
Sources & Methodology
- Blockstream — statement on the 6 September incident, key compromise findings and Elements flaw attribution.
- SideSwap — peg-out timeline, including the 14:05 UTC request and 14:28 UTC settlement.
- CoinPost Terminal — weekly protocol-drain totals for 1-7 September and confirmations of the smaller incidents.
- SlowMist — classification of the Rocket perpetual-market manipulation.
- Flow — the ankrFLOW minting incident and reimbursement commitment.
- crypto.news — reporting on the Rocket perpetual-market manipulation and the platform's response.
- CN-SEC weekly review (issue 25) — incident inventory for 31 August to 6 September 2026.
- DefiLlama — chain-level data used for the same-week context.
Headlines and figures on this page are drawn from the outlets listed above; commentary is clearly labelled opinion and is not investment advice. Last reviewed 2026-09-07.