Liquid Network Incident News September 7, 2026: How 4,000 BTC Passed a Valid Peg-Out
Liquid paused after nearly 4,000 BTC left its federation wallet through a valid peg-out. Here is what the incident reveals about LBTC issuance, bridge controls, and unresolved recovery risk.
Liquid paused after nearly 4,000 BTC left its federation wallet
Liquid Network said on September 6, 2026, that parties describing themselves as white-hat hackers withdrew roughly 4,000 BTC from the federation wallet, then worth about $320 million. Federation members disabled bridge nodes, and exchanges suspended or prepared to suspend LBTC deposits and withdrawals.
The transfer did not begin with a reported theft of SideSwap's Peg-out Authorization Key. SideSwap said its service received 4,000 LBTC, burned it with valid authorization, and the Liquid Federation then paid 3,996 BTC to the destination address. SideSwap later said Blockstream had traced the LBTC to a bug in Elements, the software underlying Liquid.
That distinction is the centre of the incident. A control can authenticate a request correctly and still release real collateral when an earlier layer has accepted assets that should not exist. The network pause limits further movement, but it does not by itself return the bitcoin or complete the technical investigation.
1. The peg-out behaved as designed after invalid LBTC entered the flow
Liquid is a federated Bitcoin sidechain. Users peg BTC into the network and receive LBTC, while federation functionaries secure the bitcoin backing the sidechain asset. A peg-out reverses that path: LBTC is burned on Liquid and BTC is released on Bitcoin.
Only approved members can initiate peg-outs through Peg-out Authorization Keys, or PAKs. Those keys are meant to restrict who can request a release from the federation wallet.
Liquid and SideSwap said the SideSwap PAK used in this incident was valid and had not been compromised. According to SideSwap's timeline, 4,000 LBTC reached its peg-out service at 14:05 UTC on September 6. The service processed the request, and the federation paid 3,996 BTC at 14:28 UTC.
| Layer | Reported result | What it does not prove |
|---|---|---|
| SideSwap service | Processed a 4,000 LBTC request | That the LBTC had been created legitimately |
| PAK authorization | Valid authorization was used | That upstream asset issuance was sound |
| Liquid federation | Released 3,996 BTC after the burn | That the peg remained fully backed afterward |
| Bitcoin network | Confirmed the BTC transaction normally | That Liquid's sidechain rules were secure |
The public record therefore points upstream from the authorization key. SideSwap said Blockstream determined that the LBTC used in the request had been created through an Elements software bug. A complete root-cause report, affected-version list, and exploit path had not been published at the time of writing.
2. A valid signature cannot replace asset-supply validation
Authorization answers who may submit an action. Validation must also answer whether the asset being burned was issued under the network's permitted rules and is backed by real collateral.
In ordinary operation, a valid PAK is a meaningful safeguard because it limits peg-outs to approved operators. In this incident, the service reportedly handled an apparently valid balance and an authorized request. If the LBTC itself was created improperly, the downstream checks could succeed while the economic invariant failed.
This is why the description of the event matters. Calling it only a stolen-key incident would point to the wrong control. Calling the parties white hats as an established fact would also go beyond the evidence. Liquid used the narrower phrase "purported white-hat hackers," and the identities and final intentions of those controlling the BTC remained unverified.
3. The Liquid pause does not mean Bitcoin stopped
Federation members disabled Liquid bridge nodes and effectively paused the sidechain while they investigated and patched the issue. Exchanges were asked to stop LBTC deposits and withdrawals. SideSwap also paused swaps, peg-ins, and peg-outs.
The Bitcoin network continued operating. The BTC transfer was confirmed under Bitcoin's normal consensus rules because Bitcoin does not evaluate whether a sidechain's internal LBTC issuance was legitimate.
Other assets issued on Liquid, including stablecoins and tokenized securities, were not reported as directly withdrawn in the incident. Their users can still be affected operationally when the sidechain is paused, wallets cannot complete normal Liquid activity, or market venues suspend deposits and withdrawals.
Anyone waiting on a Liquid transfer should avoid repeating it while services are paused. A second submission can complicate reconciliation even when it cannot settle immediately. Use the relevant wallet, exchange, or peg provider's official status channel and retain the transaction ID for support.
4. Onchain messages suggest cooperation, not completed recovery
The parties controlling the BTC used Bitcoin OP_RETURN messages to contact Blockstream and described themselves as white hats. Reporting on September 7 said they offered to return most of the bitcoin after the vulnerability was fixed across bridge nodes.
Blockstream later sent a signed onchain message stating that the bridge nodes had been patched and that the funds were safe to return. The signature and public blockchain messages make the exchange independently inspectable, but they are not the same as recovered funds.
At the time of the latest reports, the roughly 4,000 BTC remained at the address associated with the parties. "Most" also does not mean all. Recovery is complete only when the promised amount is returned to an address controlled by the federation and the transaction receives sufficient confirmation.
5. Patching bridge nodes is only one recovery gate
A safe restart requires more than distributing a software patch. Federation members need to establish which versions were affected, confirm that every relevant signer and bridge node is running corrected code, and verify the valid supply of LBTC against the bitcoin held by the federation.
Operators also need a plan for transactions that were pending when services stopped. Exchanges, wallets, and peg providers must reconcile their own balances and decide when deposits and withdrawals can reopen. A premature restart could turn an investigation into a second incident.
The network had not published a final incident report or universal restart time when this article was prepared. Claims that the problem is resolved should therefore be checked against current Liquid, Blockstream, SideSwap, wallet, and exchange notices rather than inferred from the existence of a patch.
6. The incident exposes a boundary every wrapped asset depends on
Wrapped and bridged assets rely on two linked records: the token supply on one network and the collateral controlled elsewhere. The peg works only when issuance, burning, and collateral release remain consistent under both normal and adversarial conditions.
Liquid makes its federation and peg design explicit. It uses distributed functionaries instead of a single custodian, and LBTC is intended to represent bitcoin secured by those members. Distribution reduces reliance on one operator, but shared infrastructure still needs software rules that every participant enforces consistently.
For users, the practical lesson is not that every sidechain asset is unsafe. It is that network labels do not remove bridge risk. Before using a wrapped or pegged asset, check who controls the backing, how supply can be issued, how withdrawals are authorized, what happens during a halt, and whether current redemption service is actually available.
Frequently asked questions
Q: Was the SideSwap authorization key stolen?
A: Liquid and SideSwap said the PAK used for the peg-out was valid and had not been compromised. SideSwap said Blockstream traced the improperly created LBTC to a bug in Elements, but a final technical report was not yet available.
Q: Did the incident stop the Bitcoin network?
A: No. Liquid paused its sidechain operations. Bitcoin continued processing blocks and transactions normally, including the federation wallet's BTC transfer.
Q: Have the 4,000 BTC been returned?
A: Not in the latest reports used for this article. The parties offered through onchain messages to return most of the funds after patching, and Blockstream replied that bridge nodes were patched. A promise and a signed message are not proof of completed recovery.
Q: Can users still move LBTC?
A: Liquid bridge activity and key exchange deposit and withdrawal paths were paused after the incident. Availability can change quickly, so users should check the official status of their specific wallet, exchange, or peg provider before initiating a transfer.
Q: Were stablecoins on Liquid stolen?
A: Liquid said other issued assets were not directly affected by the withdrawal. They can still face service interruption while the network and connected providers remain paused.
Sources
- Liquid Network incident statement, published September 6, 2026
- SideSwap incident statement and peg-out timeline, published September 6, 2026
- Liquid documentation: How Liquid Works
- Liquid documentation: Technical Overview
- The Block: Liquid Network attacker says they will return most of 4,000 BTC after bug fix, published September 7, 2026
The decisive checkpoints are now onchain return of the promised BTC, publication of the Elements root cause and affected versions, supply-to-collateral reconciliation, and a coordinated restart notice from the federation and connected services. Until those are visible, the patch should be treated as containment progress rather than full recovery.