Liquid Says No Keys Were Stolen – How Did 4,000 BTC Leave?

Key Takeaways

• SideSwap processed an apparently authorized peg-out.
• The disputed L-BTC may have been bug-created.
• Valid authorization did not prove legitimate issuance.
• Bitcoin’s base network was not compromised.
• Recovery remains publicly unconfirmed.

Liquid pauses its network after the withdrawal

The Liquid Network disclosed the incident after approximately 4,000 BTC, then valued at about $320 million, left a wallet controlled by its federation.

Liquid said the withdrawal used SideSwap’s Peg-Out Authorization Key, or PAK, but maintained that neither this key nor its other authorization keys had been compromised. It described the recipients as purported white-hat hackers and said Blockstream was attempting to contact them through signed messages recorded on Bitcoin.

The network disabled its bridge nodes, preventing new transactions from being submitted. Exchanges were also asked to suspend L-BTC deposits and withdrawals while federation members investigated the incident.

SideSwap links the L-BTC to an Elements bug

A subsequent statement from SideSwap described how its peg-out service received the L-BTC and released the corresponding Bitcoin.

Preliminary incident sequence

14:05 UTCA customer submits 4,000 L-BTC to SideSwap’s peg-out service.AuthorizationSideSwap says the request carries valid peg-out authorization.RedemptionThe submitted L-BTC is burned as part of the peg-out process.14:28 UTCThe Liquid Federation releases approximately 3,996 BTC.Preliminary explanationSideSwap says Blockstream traced the deposited L-BTC to an Elements software bug.

Blockstream has not yet published a complete technical postmortem identifying the vulnerability and confirming every stage of this account. SideSwap’s explanation should therefore 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 should 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.

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 prevent 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 not have existed.

What each security control checks

Elements validationWhether the L-BTC and its transaction comply with the sidechain’s rules.SideSwap PAKWhether the proposed Bitcoin destination is authorized for the peg-out.Federation signaturesWhether the required functionary threshold approves the Bitcoin payment.

If SideSwap’s account is confirmed, 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. It does not indicate that Bitcoin’s consensus rules were broken or that an attacker bypassed the security of the Bitcoin network.

Bitcoin 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 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 that the Bitcoin would be returned once the vulnerability had been fixed.

Mempool.space transaction details highlighting a major Bitcoin transfer and associated outputs.

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 also different from 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 said other issued assets, including USDT, DePix and tokenized real-world assets, were unaffected by the security incident. In this context, “unaffected” means that Liquid had not identified those assets as having been improperly created or withdrawn.

The operational disruption 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.

This distinction matters for users assessing the effect of the incident: 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.

READ MORE:HYPE ETFs Appear in Major Financial Firms’ Portfolios

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 points:

• A technical postmortem identifying the Elements vulnerability.
• The affected software versions and 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.

The post Liquid Says No Keys Were Stolen – How Did 4,000 BTC Leave? appeared first on Coindoo.