The Liquid Network was brought to a standstill after approximately $320 million in Bitcoin was withdrawn from its federation reserve via an anomalous peg-out transaction.
The incident commenced on September 6 when a customer initiated a redemption of 4,000 L-BTC through SideSwap’s peg-out service, which facilitates the conversion of Liquid Bitcoin back to mainnet BTC.
SideSwap reported that the request underwent the standard authorization process, leading the Liquid Federation to release approximately 3,996 BTC. Subsequently, the Bitcoin was transferred to an address holding roughly 3,998.5 BTC as of the most recent check.
Following the withdrawal, Liquid deactivated its bridge nodes, and SideSwap suspended all swaps, peg-ins, and peg-outs. Concurrently, exchanges paused or readied themselves to pause L-BTC deposits and withdrawals pending investigation.
The entities controlling the Bitcoin later identified themselves as white-hat hackers via on-chain messages, stating their intent to return the majority of the funds once the underlying bug was remediated across the network.
While the white-hats’ return of the funds could mitigate financial losses, it does not address the critical question of how nearly 4,000 BTC exited the federation without an apparent key compromise.
The Withdrawal Appeared to Follow Standard Procedures
Liquid and SideSwap assert that the incident did not involve compromised signing credentials.
The withdrawal was executed using SideSwap’s valid Peg-out Authorization Key (PAK), and Liquid confirmed that neither this key nor other federation keys were compromised.
Instead, SideSwap indicated that Blockstream traced the 4,000 L-BTC presented for redemption to a flaw in Elements, the software that underpins Liquid.
If verified, the vulnerability would have existed prior to the Bitcoin transaction being signed.
Liquid is designed to maintain a one-to-one reserve of BTC for every L-BTC in circulation. In a standard peg-out, L-BTC is burned and an equivalent amount of Bitcoin is released.
In this instance, SideSwap says a software bug generated L-BTC without corresponding Bitcoin backing. Despite this, the tokens entered a valid peg-out process, and federation functionaries treated the withdrawal as legitimate, releasing real BTC.
Blockchain security firm Bitslab reported that at least 11 of Liquid’s 15 functionaries ultimately signed the transaction.
This indicates a different type of failure compared to a conventional bridge exploit. Secure keys offer limited protection if every signer is presented with the same invalid state and accepts it as legitimate.
No independent technical postmortem or detailed patch description was publicly available at the latest check, leaving the precise cause attributed to Liquid and SideSwap.
White-Hat Hackers Demand Bug Fix Before Returning Bitcoin
Meanwhile, the actors holding the funds have been communicating with Blockstream via Bitcoin transactions containing OP_RETURN messages.
Galaxy Digital research head Alex Thorn stated that Blockstream initially sent a message requesting the holder to contact its security team. The holder later responded that it intended to return “most” of the Bitcoin to the federation.
A subsequent message added the condition that Blockstream must fix the bug and ensure every node is patched before the funds are returned.
This places Liquid’s next steps beyond simply recovering the Bitcoin.
The federation must identify and remediate the Elements flaw, distribute the fix across affected nodes, and establish that another batch of invalid L-BTC cannot pass through the same authorization process.
It must also reconcile the reserve.
The allegedly bug-created L-BTC was burned during the peg-out, but approximately 3,996 real BTC still left Liquid’s federation wallet. Until those funds are returned or the accounting is otherwise restored, the network must demonstrate that legitimate outstanding L-BTC remains backed one-for-one.
Liquid’s bridge nodes remain disabled while this work continues.
While the incident may ultimately end with most of the Bitcoin recovered, the more challenging task is proving that the system that authorized its release cannot repeat the same mistake.
