The Liquid Network, a federated Bitcoin sidechain developed and maintained by Blockstream since its 2018 launch and used by exchanges and trading firms for faster settlement between Bitcoin venues, went public with a security incident after roughly 4,000 BTC — about $320 million at the time — left a wallet controlled by its federation. According to Liquid, the withdrawal was executed using SideSwap's Peg-Out Authorization Key (PAK), yet the network insists that neither this key nor any of its other authorization keys were compromised. Liquid characterized the recipients as purported white-hat hackers, and Blockstream has been trying to reach them through signed messages recorded on Bitcoin.

In response, the network disabled its bridge nodes, which prevents new transactions from being submitted. Exchanges were also asked to suspend L-BTC deposits and withdrawals while federation members investigate. The stakes of that pause are significant for the sidechain's user base: because L-BTC moves between participating exchanges far faster and cheaper than onchain Bitcoin, prolonged suspension of peg-outs and exchange support directly affects the settlement workflow those firms rely on.

SideSwap links the L-BTC to an Elements bug

A follow-up statement from SideSwap described how its peg-out service received the L-BTC and released the corresponding Bitcoin. Blockstream, however, has not yet published a complete technical postmortem identifying the vulnerability or confirming every stage of this account, so SideSwap's explanation should be treated as preliminary.

How secure keys could still release the Bitcoin

Liquid's design separates the validity of an asset from the authorization of its destination. Under Blockstream's documentation for L-BTC, each unit is supposed to be backed by an equivalent amount of Bitcoin held by the federation. A normal peg-out burns the L-BTC before releasing the corresponding BTC.

A PAK performs a narrower job: it authorizes the Bitcoin address that may receive a peg-out. It is not the mechanism that determines whether the redeemed L-BTC was properly issued in the first place.

The federation's multisignature arrangement requires 11 of 15 functionaries to authorize spending from the Bitcoin wallet. If SideSwap's account is confirmed, those signatures could have been cryptographically valid even though an earlier validation failure allowed improperly created L-BTC to reach the peg-out process. A secure PAK would therefore not have prevented a withdrawal if the network had already accepted the disputed L-BTC as valid — the authorization could approve the intended destination while the asset-validation process failed to identify L-BTC that should never have existed.

If SideSwap's account holds, the supply controls failed to reject L-BTC created without a corresponding Bitcoin deposit. That would explain how secure authorization keys and valid federation signatures could still produce a loss of real reserves.

Bitcoin itself was not compromised

The incident concerns Liquid, a federated sidechain built with Elements, the open-source sidechain codebase that also underpins other Liquid-based deployments. It does not indicate that Bitcoin's consensus rules were broken or that an attacker bypassed the security of the Bitcoin network itself. Bitcoin simply processed a transaction carrying the signatures needed to spend from the federation wallet. The apparent failure occurred earlier, within the system responsible for issuing, validating and redeeming L-BTC.

Calling the event a "Bitcoin hack" would therefore obscure where the problem actually occurred. The transferred BTC was real, but SideSwap's preliminary explanation points to Liquid's sidechain software and peg controls.

Onchain messages show contact, not recovery

Messages attached to Bitcoin transactions show an exchange between Blockstream and the address controlling the withdrawn funds. Blockstream supplied a return address, and the recipient later indicated the Bitcoin would be returned once the vulnerability had been fixed. Readers can follow transactions involving the stated return address on Mempool.

The communication is consistent with the recipient's white-hat claim, but it does not verify the person's identity or intentions. A promise to return the Bitcoin is not the same as a completed recovery — confirmation requires an identifiable return transaction and acknowledgment from Liquid or Blockstream that the expected funds have been received.

Liquid says other assets were unaffected, but access was disrupted

Liquid stated that other issued assets, including USDT, DePix and tokenized real-world assets, were unaffected by the security incident. In this context, "unaffected" means Liquid had not identified those assets as having been improperly created or withdrawn.

The operational disruption, however, was broader. Disabling the bridge nodes effectively paused the sidechain, while exchanges suspended or prepared to suspend L-BTC transfers. An asset can remain intact on the ledger while its owner temporarily loses the ability to move or redeem it — asset integrity and asset availability are separate risks.

The Coldcard case exposed a different Bitcoin security layer

The event follows a separate Bitcoin security incident involving affected Coldcard devices. The cases are unrelated, but they illustrate failures at different layers: Coldcard's problem concerned wallet transaction handling, while Liquid's preliminary account concerns the validation and redemption of a Bitcoin-backed sidechain asset.

What Liquid must establish before restarting

Restoring transaction processing would not resolve every question raised by the withdrawal. Before users can independently assess a restart, Liquid should provide enough information to verify the following:

• A technical postmortem identifying the Elements vulnerability.
• The affected software versions and the exact corrective update.
• Confirmation that the corrected software was deployed across the functionary infrastructure.
• A reconciliation of legitimate outstanding L-BTC against federation-held Bitcoin.
• Confirmation of whether the approximately 3,996 BTC was returned.
• An explanation of why the peg-out process accepted the disputed L-BTC.
• Notice that bridge nodes and normal transaction processing have resumed.
• Confirmation from exchanges restoring L-BTC deposits and withdrawals.

A software patch would address the vulnerability, but it would not alone prove that Liquid's accounting had been restored. Users also need evidence that the remaining Bitcoin reserves cover all legitimate L-BTC still in circulation.

What Liquid still needs to explain

The remaining question is why the disputed L-BTC passed the checks that preceded the federation's signatures. Until Blockstream identifies the vulnerability, reconciles legitimate outstanding L-BTC with the remaining reserves, and confirms whether the approximately 3,996 BTC was returned, the incident's technical and financial outcome cannot be independently assessed.

This article is for informational purposes and does not constitute financial, legal or investment advice.