On September 6, a security incident occurred in the Bitcoin sidechain Liquid Network, involving an amount of approximately $320 million, with about 4,000 BTC being transferred out of the Liquid Federation's reserve wallet. Unlike common occurrences of private key leakage or multi-signature compromises, Liquid reported that the related Peg-out Authorization Key (PAK) itself was not breached. Instead, the attacker exploited a vulnerability in the underlying Elements software, completing a normal cross-chain exit process using abnormally generated LBTC.

After the incident, Liquid suspended network-related activities, and multiple trading platforms halted LBTC deposits and withdrawals. Subsequently, the attacker, who claimed to be a "white hat hacker," communicated with Blockstream through information on the Bitcoin chain and returned 3,400 BTC after Blockstream confirmed the completion of node repairs. However, approximately 598.5 BTC remained under the attacker's control, worth about $47 million.

As of September 8, the timeline for the full recovery of the Liquid network, 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

The Liquid Network, supported by Blockstream, is a Bitcoin sidechain 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 can 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 freely converting LBTC into mainnet BTC, Liquid's Peg-out process also introduced the PAK mechanism. Official documentation indicates that users must prove 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 revealed by SideSwap, a user sent approximately 4,000 LBTC to its Peg-out service. SideSwap destroyed these LBTC according to standard procedures and initiated a Peg-out to a 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 previously locked in the Federation wallet.

Liquid subsequently 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 to directly steal the BTC; instead, they exploited software vulnerabilities to create or acquire LBTC that should not exist, and then exchanged it for actual BTC through the normal Peg-out mechanism of Liquid.

This also explains why the PAK was not compromised in this incident. SideSwap stated that the affected Peg-out followed a valid authorization process, and neither their system nor the PAK had been breached; the problem lay in the upstream LBTC generation logic.

From the outcome, the attacker effectively exploited a software vulnerability rooted in the basic assumption that “LBTC must be backed by an equivalent amount of BTC” in Liquid: the system accepted LBTC that should not exist, and the subsequent Peg-out process treated it as a normal asset, ultimately allowing the non-existent LBTC to be exchanged for real BTC.

Liquid's official documentation explicitly states that LBTC and BTC maintain a 1:1 peg, and the number of LBTC in circulation should not exceed the amount of BTC locked by the Federation. This incident precisely violated that core constraint.

About 95% of BTC reserves withdrawn, Liquid 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 accounted for most of Liquid's reserves at the time.

Before the incident, there were about 4,200 BTC in the Liquid Federation wallet. The transfer of approximately 4,000 BTC meant that about 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 via on-chain messages. The network also reminded users that wallet and related services would be affected during the suspension.

It is noteworthy that Liquid stated that the incident primarily impacted BTC reserves and that other Liquid assets, including USDT, DePix, and some real-world assets, were not similarly affected. However, since the Liquid network itself was suspended, the normal transfer and use of related assets could still be impacted at the service level.

This also distinguishes this incident from the traditional notion of "hot wallet theft." The attacker did not simply bypass a wallet signature system but exploited a connection vulnerability between the sidechain software and cross-chain redemption mechanism.

"White hat" identity controversy, 3,400 BTC already returned

The subsequent developments of the incident saw a notable twist.

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 all relevant nodes were updated 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 withdrawn BTC has returned to wallets controlled by Liquid, while about 598.5 BTC remains held by the original fund controllers, calculating to approximately $47 million at current prices.

However, there is still controversy over whether the attacker can be defined as a "white hat." On one hand, they proactively returned the majority of the funds after the vulnerability was fixed and requested Blockstream to prioritize the patching of the vulnerability, bearing some resemblance to traditional white hat vulnerability disclosure behavior; on the other hand, the attacker transferred approximately 4,000 BTC without authorization before establishing communication with the project party.

Therefore, Liquid currently uses the expression "self-identified white hat hacker" cautiously. Industry security experts have also pointed out that traditional responsible vulnerability disclosure typically requires researchers to first report the vulnerability to the project party after discovery rather than directly controlling protocol assets. Ledger CTO Charles Guillemet has publicly questioned the "white hat" claim in this incident, arguing that the approach of transferring large sums first and then demanding the project to fix the vulnerability is clearly controversial.

The incident truly exposes the dependency of cross-chain systems on software assumptions

This incident is still under investigation, and the complete technical details of the specific vulnerability in Elements have not yet been made public by Blockstream. Therefore, it is premature to draw definitive conclusions about the exact code reasons for the vulnerability and how the attacker discovered and exploited it.

However, from the disclosed information, the incident at least reveals a key risk in the Liquid architecture: the multi-signature security of the Federation wallet does not imply that the entire cross-chain system is free from the possibility of abnormal fund releases.

Liquid employs a Federation model to manage BTC locked on the Bitcoin mainnet and determines when to allow Peg-outs through software rules. The official technical documentation indicates that the multi-signature mechanism of the Federation requires over two-thirds of watchmen to participate in order to access funds, and an emergency recovery mechanism is also designed.

However, this incident bypassed the traditional "theft of private keys" pathway. The attacker exploited the logical relationships between asset issuance, LBTC verification, and Peg-out, leading the system to treat the abnormally generated LBTC as legitimate assets, ultimately triggering the release of real BTC.

Thus, from a technical perspective, this was not an attack on the Bitcoin mainnet itself. Bitcoin’s consensus mechanism, mainnet blocks, and BTC ownership verification were not affected; the impact was on the Liquid sidechain built on Bitcoin and its asset anchoring mechanism.

At the same time, the incident highlights the importance of software vulnerability lifecycle management. Elements, the open-source software relied upon by Liquid, has been confirmed by Liquid to be the source of the issue. Questions remain regarding how long this vulnerability existed, why it was not discovered earlier, whether it has affected other Elements-related deployments, and whether there are other potential exploitation pathways, all of which still need further audits and official disclosures to answer.

For users, the most immediate issue 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, there is a need for further explanation of 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 is not yet completely resolved. Until details of the vulnerability, remaining funds, and network recovery plans are confirmed further, a complete answer to this incident remains to be filled in.