On 6 September 2026, Liquid Network suffered an unusual “unbacked mint to authorised peg-out” incident. Public evidence indicates that the responsible party exploited a range-proof verification cache flaw in Elements, the software underlying Liquid, to create about 4,000 L-BTC without corresponding bitcoin reserves. Those tokens then passed through SideSwap’s authorised peg-out service and were exchanged for real BTC held by the Liquid Federation.
This was not the familiar pattern of stolen reserve keys. Liquid said federation and peg-out authorisation keys were not compromised; the failure occurred earlier, when invalid coins were accepted as valid. Once accepted, the downstream peg-out machinery operated as designed and released about 3,996 BTC.
What is confirmed
SideSwap’s 9 September statement provides transaction hashes and a detailed sequence. It says the actor tested a small withdrawal, created the unbacked L-BTC at around 13:53 UTC, then submitted a roughly 4,000 L-BTC peg-out at 14:05 UTC. SideSwap burned the tokens with a valid authorisation, the federation released about 3,996.02 BTC, and SideSwap forwarded nearly 3,996 BTC to the requested address in the same Bitcoin block.
Liquid was subsequently paused and bridge nodes were disabled. On 7 September, 3,400 BTC was returned. As of the latest status reporting on 11 September, about 598.5 BTC remained outstanding. Blockstream rejected treating the retained amount as a bounty unilaterally set by the actor and said it would work with law enforcement, exchanges and blockchain investigators. The return is visible on-chain; identity, legal responsibility and the final treatment of the balance remain unresolved.
Two control layers failed
The first layer was transaction validation. Chainalysis, summarising the public incident material, says ambiguous cache handling allowed an invalid range-proof result to inherit a previously validated state. That undermined the core promise that each L-BTC is supported by bitcoin in reserve.
The second layer was operational peg-out control. SideSwap acknowledged that its authorisation key was online, payouts were automated, and its pipeline lacked sufficient size, velocity, wallet-age and supply-share checks. An order approaching the network’s entire reserve therefore received no manual hold. The software flaw created unbacked tokens; the operating model converted a problem inside Liquid into a hard-to-reverse payment on Bitcoin mainnet.
The lesson extends beyond one bridge. Code review does not replace withdrawal limits, behavioural monitoring, delayed settlement, offline approval and human review for exceptional orders. No single automated path should be able to release nearly all reserves at once.
Recovery is not the same as closure
By 11 September, independent reporting said block production and ordinary transactions had resumed after deployment of Elements v23.3.4, but peg-outs remained disabled while reserve restoration continued. “Network resumed” therefore did not mean every service and 1:1 redemption had fully reopened. Users should separately verify chain activity, exchange deposit and withdrawal support, official peg status and the plan for any reserve gap.
Blockstream also warned that impersonators were exploiting the incident with fake security updates, reimbursement portals and migration requests. Users do not need to enter seed phrases or PINs, install software from unsolicited links, or send funds to obtain recovery. Every urgent message should be verified through official domains and the user’s own exchange.
Impact on traders and intermediaries
For L-BTC holders, the immediate question concerns the wrapper’s backing and redemption route, not Bitcoin mainnet itself. Market value and redeemability can diverge during a suspension. Users should retain balance records, transaction hashes, platform notices and support correspondence, and avoid acting on unverified secondary-market prices.
Exchanges, brokers and custodians should treat L-BTC and native BTC as distinct risk assets. Reserve evidence, bridge status, exit routes, counterparty exposure and suspension policies require separate review. Product pages that display only “BTC” without explaining that settlement uses L-BTC or another wrapped asset may also need clearer disclosure.
TraderVote view
The incident is not just a software bug. It is a coupling failure across validation, automated exits and reserve governance. Returning roughly 85% of the BTC materially reduced the immediate shortfall, but did not close the case. The remaining 598.5 BTC, peg-out reopening conditions, reserve restoration, independent review and legal recovery all remain material.
The careful conclusion is that exploitation of the validation flaw, creation of roughly 4,000 unbacked L-BTC, release of about 3,996 BTC and return of 3,400 BTC are supported by public evidence. The actor’s identity, entitlement to the remaining funds and final loss are not established.
Sources
SideSwap, “Statement on the Liquid Network incident of 6 September 2026,” published 9 September 2026, accessed 13 September 2026: https://testnet.sideswap.io/news/statement-on-the-liquid-network-incident-of-6-september-2026/
Blockstream, “Phishing Alert: Do Not Act on Unsolicited Liquid or Blockstream Messages,” published 9 September 2026, accessed 13 September 2026: https://blog.blockstream.com/phishing-alert-do-not-act-on-unsolicited-liquid-or-blockstream-messages/
Chainalysis, “How The $320M Exploit of Liquid Network Went Down,” published 9 September 2026, accessed 13 September 2026: https://www.chainalysis.com/blog/320m-exploit-liquid-network/
The Block, latest recovery and fund-status reporting, published 11 September 2026, accessed 13 September 2026: https://www.theblock.co/news/ecosystems/2026-09-11-return-the-bitcoin-blockstream-refuses-ransom-demand-for-remaining-600-btc-from-liquid-exploit-414247
Written independently by Hengyuan from public information verifiable as of 13 September 2026. Investigation, fund recovery and service restoration remain ongoing. This article is not investment, legal or cybersecurity advice.
Discussion
Comments (0)
Sign in to join the discussion.
Sign inNo published comments yet. Start the discussion.