Liquid Network Exploit: What Failed
On September 6, 2026, attackers exploited Liquid Network’s software to create roughly 4,000 unbacked L-BTC, then exchanged it for real bitcoin from the federation’s reserve. Bitcoin’s base protocol was unaffected, but bitcoin deposited into Liquid was exposed through the system built around it. Chainalysis’s incident analysis explains that distinction.
Most of the bitcoin came back. By September 11, however, about 598.5 BTC remained outstanding, according to Decrypt’s reporting. Blockstream publicly refused to pay a ransom. Adam Back had promised the previous day that the one-to-one peg would be covered, but that promise did not establish that the reserve had already been replenished.
This account covers the evidence available as of September 13, 2026. Recovery remained incomplete in the latest dated updates reviewed.
How unbacked L-BTC became a real bitcoin loss
L-BTC is the bitcoin asset used on Liquid, a separate blockchain built on Elements software. Its intended backing is one BTC held by the Liquid Federation for each L-BTC. A peg-in moves bitcoin into that arrangement; a peg-out releases bitcoin from the reserve. Holding L-BTC therefore adds dependencies beyond holding native BTC. Chainalysis describes the peg model and its failure here.
Liquid’s Confidential Transactions hide amounts. A rangeproof lets nodes check that a hidden amount falls within permitted limits without revealing it. Those checks help prevent someone from creating spendable value through an invalid amount.
Verifying proofs takes computing work, so Elements saves successful results in a cache. According to CertiK’s technical analysis, different validation inputs could produce the same cache identifier because their component fields were combined ambiguously. The attacker arranged for invalid data to reuse a successful result. A check that should have rejected the transaction was skipped.
The resulting L-BTC had no corresponding bitcoin deposit. It nevertheless reached an authorized withdrawal route.
In its September 9 statement, SideSwap said its service processed a 4,000 L-BTC order, burned the L-BTC on Liquid and forwarded approximately 3,996 BTC after the federation paid out. Those figures describe different stages of the main order; they should not be treated as interchangeable exact totals for the whole incident.
Bitcoin did not create those coins. Existing BTC left the reserve through the peg-out process. That distinction protects the technical facts, but offers little comfort to someone relying on that reserve.
September 6–9: the withdrawal, return and software response
Liquid’s September 6 alert on X described the actors as “Purported white-hat hackers” and said Blockstream was trying to contact them through a signed on-chain message. The wording was provisional; it did not establish that their actions were authorized.
On September 7, a Bitcoin transaction returned 3,400 BTC. The explorer records confirmation in Bitcoin block 965950 at 16:09:25 UTC. That transaction proves a substantial return at that time. It cannot establish today’s reserve balance or account for every remaining liability.
On September 8, Blockstream’s official X account said it and the federation had been “working diligently to resolve the ongoing situation and ensure the return of assets.”
The software history needs more care than saying everybody forgot to update. SideSwap said a private security build was shared on August 12 and that it deployed the build on August 13. Its node was running that software when it accepted the inflation transaction. SideSwap also dated a public merge describing the vulnerability to September 1. These are SideSwap’s disclosures, not independently verified deployment records for every federation member.
CertiK’s analysis points to an ambiguous cache encoding introduced by a patch. That complicates early explanations blaming only missing verification context. The publication sequence deserves examination, but does not by itself prove how the attacker discovered the flaw.
On September 9, Liquid’s official account announced Elements v23.3.4, saying functionary nodes were being updated and recommending that all Liquid node runners update too.
SideSwap acknowledged missing withdrawal controls
SideSwap said no key, wallet or system of its own had been compromised. It also accepted responsibility for operational decisions that allowed the payout.
Its September 9 statement said: “Our peg-out key was kept online, and payouts were automatic.” The service lacked order-size limits, rate controls and checks on the depositing wallet’s history. A request representing a large share of Liquid’s supply passed without human review.
SideSwap also said the federation supplied the required signatures and should have had its own checks on the order’s size and plausibility. That is a participant’s account of shared responsibility, not a completed independent investigation.
The admission matters because securing private keys addresses only part of this failure. A valid signing process can still release funds after the system accepts something it should have rejected.
September 10–11: a coverage promise, then a ransom refusal
On September 10, Blockstream CEO Adam Back wrote on X: “obvious question will LBTC:BTC 1:1 peg be covered; answer YES”. His post placed resuming peg-ins and peg-outs in a later step.
That was a public commitment. It did not specify a completed reserve transfer or prove that redemption was available again.
On September 11, @Blockstream’s response became explicit:
Blockstream will not pay a ransom for the return of stolen funds. Taking assets without authorization and withholding their return is a crime, not responsible disclosure. It is not white-hat activity.
The statement rejected the white-hat framing used earlier. These are Blockstream’s words about the conduct, not a court ruling.
Calling the outstanding bitcoin an agreed bounty would misrepresent the record. Chainalysis had reported no publicly confirmed agreement, and Blockstream subsequently refused a ransom outright. Returning most of the money did not establish permission to retain the rest.
Reopening services did not settle the backing problem
Liquid’s September 10 operational update initially described block production resuming without transactions. SideSwap later said transactions resumed that day and announced on September 11 that peg-ins were open again. Peg-outs stayed closed.
That SideSwap update warned that the reserve remained below the L-BTC supply. It cited 4,229 L-BTC in circulation against 3,627 BTC in reserve on September 11. These are dated, attributed figures, not a fresh September 13 reserve audit.
There was also an unresolved status conflict. The Liquid homepage, checked September 13, still said L-BTC transfers and peg-outs remained paused, while SideSwap described reopened markets and transactions. Readers should check their particular service rather than assume every wallet function has returned.
For anyone considering a peg-in, SideSwap’s warning was unusually direct: bitcoin could enter, while L-BTC still could not be redeemed through the federation. Check redemption availability and backing before depositing; an open entrance does not guarantee an available exit.
Bitcoin’s base-layer security held through this incident. Liquid users still needed the reserve, validation software and withdrawal controls to work. Until backing is demonstrated and redemptions resume, a promise of one-to-one coverage remains a promise.
Related reading
Continue with these related Proof of Tech guides: