The timeline of the Liquid Network theft incident: how an abnormal minting process withdrew nearly 4,000 BTC
Author: Gu Yu, ChainCatcher
On September 6, a security incident occurred on the Bitcoin sidechain Liquid Network, involving approximately $320 million, with around 4,000 BTC being transferred out of the Liquid Federation's reserve wallet. Unlike common private key leaks or multi-signature breaches, Liquid stated that the related Peg-out Authorization Key (PAK) itself was not compromised; the attacker exploited a vulnerability in the underlying Elements software to generate LBTC abnormally and completed a normal cross-chain exit process.
After the incident, Liquid suspended network-related activities, and several trading platforms halted LBTC deposits and withdrawals. Subsequently, the attacker, claiming to be a "white hat hacker," communicated with Blockstream through on-chain messages and returned 3,400 BTC after Blockstream confirmed the completion of node repairs. However, approximately 598.5 BTC remained under the attacker's control, valued at about $47 million.
As of September 8, when the Liquid network will fully recover, how the remaining funds will be handled, and the complete technical details of the vulnerability are still pending further disclosure.
A seemingly normal Peg-out, 4,000 BTC suddenly leaves the reserve wallet
Liquid Network is a Bitcoin sidechain supported by Blockstream, primarily used for fast and confidential BTC settlements, while also supporting the issuance of stablecoins, tokenized securities, and other assets. One of its core mechanisms is the 1:1 peg between BTC and LBTC: users deposit BTC into a Bitcoin wallet controlled by the Liquid Federation and receive the corresponding amount of LBTC; during the reverse operation, LBTC is destroyed, and the Federation releases BTC to the user.
To prevent any user from casually exchanging LBTC for mainnet BTC, Liquid's Peg-out process also introduced the PAK mechanism. Official documentation indicates that users must prove that their Bitcoin address belongs to an authorized PAK entry, which is then processed by watchmen in the network to release BTC.
On September 6, this mechanism suddenly malfunctioned.
According to information disclosed by SideSwap, a user sent approximately 4,000 LBTC to its Peg-out service. SideSwap destroyed these LBTC according to the normal process and initiated a Peg-out to the specified Bitcoin address. Ultimately, the Liquid Federation paid approximately 3,996 BTC to that address.
The issue was that these 4,000 LBTC did not correspond to the 4,000 BTC that were previously locked in the Federation wallet.
Liquid later determined that this batch of LBTC originated from a vulnerability in the Elements software. In other words, the attacker did not first obtain the private key of the Federation wallet and then directly transfer BTC; instead, they exploited a software vulnerability to create or obtain LBTC that should not have existed, and then exchanged it for real BTC through Liquid's normal Peg-out mechanism.
This also explains why the PAK was not compromised in this incident. SideSwap stated that the affected Peg-out used a valid authorization process, and its own system and PAK were not breached; the problem lay in the upstream LBTC generation logic.
From the outcome, the attacker effectively exploited a software vulnerability in the fundamental assumption of Liquid that "LBTC must be backed by an equal amount of BTC": the system accepted LBTC that should not exist, and the subsequent Peg-out process treated it as a normal asset, ultimately allowing LBTC that did not exist to be exchanged for real BTC.
Liquid's official documentation clearly states that LBTC and BTC maintain a 1:1 peg, and the circulating amount of LBTC should not exceed the amount of BTC locked by the Federation. This incident precisely undermined this core constraint.
Approximately 95% of BTC reserves withdrawn, Liquid urgently suspends services
The scale of this attack has garnered significant attention, not only because the amount reached approximately $320 million but also because the BTC transferred out accounted for a large portion of Liquid's reserves at the time.
Before the incident, there were approximately 4,200 BTC in the Liquid Federation wallet. The transfer of about 4,000 BTC means that approximately 95% of the reserves were affected. Liquid subsequently shut down bridge nodes and suspended new network transactions; some trading platforms also halted LBTC deposits and withdrawals.
In its initial announcement, Liquid stated that the incident involved "suspected white hat hackers" and indicated that Blockstream was in contact with the fund controllers through on-chain messages. The network also reminded users that their wallets and related services would be affected during the suspension.
It is worth noting that Liquid stated that this incident primarily affected BTC reserves and claimed that other Liquid assets, including USDT, DePix, and some real-world assets, were not similarly affected. However, due to the suspension of the Liquid network itself, the normal transfer and use of related assets may still be impacted at the service level.
This also differentiates this incident from the traditional notion of "hot wallet theft." The attacker did not simply breach a wallet signing system but exploited the connection vulnerability between sidechain software and cross-chain redemption mechanisms.
"White hat" identity raises controversy, 3,400 BTC returned
The subsequent developments of the incident took a notable turn.
After transferring out the funds, the attacker left a message in the OP_RETURN field of the Bitcoin transaction, claiming to be "white hats," and requested Liquid to contact them through on-chain means. Blockstream subsequently communicated with them using on-chain messages.
In the follow-up communication, the attacker demanded that Blockstream first fix the vulnerability and ensure that all related nodes completed updates before considering returning the funds.
On September 7, Blockstream confirmed through a signed on-chain message: "Bridge nodes are patched, safe to return the funds." Subsequently, the attacker returned 3,400 BTC to the Liquid Federation address.
This means that as of now, approximately 85% of the transferred BTC has returned to the wallets controlled by Liquid, while approximately 598.5 BTC remains held by the original fund controllers, valued at about $47 million at current prices.
However, whether the attacker can truly be defined as a "white hat" remains controversial. On one hand, they proactively returned the vast majority of the funds after the vulnerability was fixed and requested Blockstream to prioritize the vulnerability repair, which bears some similarity to certain white hat vulnerability disclosure behaviors; on the other hand, the attacker transferred approximately 4,000 BTC without authorization before establishing communication with the project team.
Therefore, Liquid currently uses the expression "self-proclaimed white hat hacker" with caution. Industry security experts have also pointed out that traditional responsible vulnerability disclosure usually requires researchers to report vulnerabilities to the project team first after discovery, rather than directly controlling protocol assets. Ledger CTO Charles Guillemet publicly questioned the "white hat" claim in this incident and believed that the approach of first transferring large amounts of assets and then requesting the project team to fix the vulnerability is clearly controversial.
The incident truly exposes the reliance of cross-chain systems on software assumptions
The incident is still under investigation, and the complete technical details of the specific vulnerability in Elements have not yet been disclosed by Blockstream. Therefore, it is not appropriate to draw conclusions about the specific code reasons for the vulnerability and how the attacker discovered and exploited it.
However, from the disclosed information, the incident at least exposes a key risk in the Liquid architecture: the multi-signature security of the Federation wallet itself does not mean that the entire cross-chain system is free from the possibility of funds being released abnormally.
Liquid uses a Federation model to manage BTC locked on the Bitcoin mainnet and determines when to allow Peg-outs through software rules. Official technical documentation indicates that the Federation's multi-signature mechanism requires more than two-thirds of the watchmen to participate in order to access funds, and an emergency recovery mechanism is also designed.
However, this incident bypassed the traditional "stealing private keys" path. The attacker exploited the logical relationships between asset issuance, LBTC verification, and Peg-outs, causing the system to treat the abnormally generated LBTC as legitimate assets, ultimately triggering the release of real BTC.
Therefore, from a technical perspective, this was not an attack on the Bitcoin mainnet itself. The consensus mechanism of Bitcoin, mainnet blocks, and BTC ownership verification were not affected by this incident; the affected party was Liquid, the sidechain built on Bitcoin, and its asset anchoring mechanism.
At the same time, the incident also highlights the importance of software vulnerability lifecycle management. Elements is the open-source software on which Liquid operates, and Liquid has confirmed that the problem originates from Elements. As for how long this vulnerability has existed, why it was not discovered earlier, whether it has affected other Elements-related deployments, and whether there are other potential exploitation paths, further audits and official disclosures are needed to answer these questions.
For users, the most immediate question remains when Liquid services will resume and whether the remaining approximately 598.5 BTC can ultimately return to the Federation wallet. For Blockstream and Liquid, further explanations are needed regarding the specific causes of the vulnerability, the affected software versions, the scope of repairs, and subsequent security measures.
The return of 3,400 BTC alleviated Liquid's financial pressure, but the incident itself has not yet fully concluded. Until the details of the vulnerability, remaining funds, and network recovery plans are further confirmed, the complete answer to this incident remains to be filled in.













