How Liquid’s Reported $320M Peg-Out Happened—and What It Means for LBTC

Liquid Network paused bridge activity after approximately 4,000 BTC—reported as about $320 million at the time—left the federation wallet backing L-BTC. The withdrawal represented roughly 95% of the reported reserve. Available reporting points to an alleged Elements software inflation flaw rather than stolen federation or SideSwap authorization keys, but public technical details remain incomplete. 413

What reportedly happened

The reported sequence is straightforward, even if the underlying bug is not yet fully disclosed:

1. An actor allegedly created L-BTC that was not backed by locked Bitcoin because of an Elements software flaw.
2. That L-BTC was submitted through SideSwap’s normal customer peg-out service.
3. The peg-out used SideSwap’s Peg-out Authorization Key (PAK), which Liquid and SideSwap said was not compromised.
4. Liquid federation infrastructure authorized a Bitcoin withdrawal, with reports putting the payout at roughly 3,996 BTC and the overall event at about 4,000 BTC. 26

In other words, the reported failure was not that someone stole the keys controlling the reserve. It was that a withdrawal apparently satisfied the system’s authorization checks despite the L-BTC allegedly having invalid economic backing.

Why the HSMs could sign without a key compromise

Liquid uses a Strong Federation model: federation members collectively operate the sidechain and control the Bitcoin-side reserve through threshold signing. Liquid’s own technical documentation describes its consensus model as Strong Federations.

Hardware security modules, or HSMs, protect signing keys and enforce configured policies. They are not a general-purpose, independent judge of every historical fact relevant to an asset’s backing. If a peg-out request presents inputs that the system recognizes as valid—including a valid authorization path—the HSMs can sign without any private key being stolen.

That is the core reported distinction in this incident:

• Authorization: the peg-out was reportedly processed with SideSwap’s legitimate PAK.
• Provenance/backing: the L-BTC submitted for redemption was allegedly created through an Elements bug rather than through a normal Bitcoin-backed issuance process. 2

SideSwap said the roughly 4,000 BTC peg-out came through its service as a customer order, that its PAK was not compromised, and that the L-BTC originated from an Elements bug rather than SideSwap’s own systems.

The implication is not that threshold signatures or HSM cryptography failed. Rather, a shared validation or issuance defect can cause correctly functioning automated signers to approve a withdrawal that should never have been eligible. A valid signature proves that the signing policy was met; it does not, by itself, prove that the redeemed asset was properly backed.

Are the actors really “white hats”?

The actors attached an on-chain message stating: “we are whitehats. contact us on chain.” 16

Reporting also indicates that Blockstream/Liquid contacted the actors through signed on-chain messages and that the actors offered to return “most” of the funds after the vulnerability is patched across the network. 418

Those facts establish that the actors asserted a security-researcher rationale and left a communication channel. They do not independently establish white-hat status. At the time of the reporting, the funds had not been confirmed returned, and no public patch or network reopening had been confirmed. 13

“Purported white hats” is therefore the most accurate description. The label should not be treated as a conclusion until the funds, exploit details, and remediation are independently verified.

How Liquid, SideSwap, and exchanges responded

Liquid disabled bridge nodes and paused operations, preventing normal movement between Bitcoin and Liquid. Exchanges were notified to pause, or prepare to pause, L-BTC deposits and withdrawals. 48

SideSwap said it paused peg-ins and peg-outs while Liquid remained paused.

These measures are containment steps: they limit additional bridge movement while operators investigate the reported vulnerability, assess the reserve position, and determine the conditions for a safe restart. The reported recovery plan depended on fixing the flaw, updating affected nodes, and resolving the status of the withdrawn BTC. 1318

What the incident means for LBTC holders

L-BTC is intended to be Bitcoin on Liquid, but its practical equivalence to readily redeemable BTC depends on the bridge being available and credibly backed.

With about 4,000 BTC reported withdrawn from a reserve of roughly 4,200 BTC—and bridge activity paused—ordinary L-BTC redemption was disrupted and the reported reserve shortfall became the immediate issue for holders. 313

That does not establish a final recovery outcome. It does mean that, during the incident, holding L-BTC was not operationally the same as holding BTC that could be freely withdrawn on Bitcoin’s base layer. The eventual outcome depends on recovery of funds, remediation of the alleged bug, federation decisions, and service-provider policies.

Other Liquid-issued assets

Other assets on Liquid are not automatically removed from their issuers’ reserves merely because BTC left the federation wallet. Liquid stated that assets including USDT, DePix, and RWAs were unaffected by the incident itself.

Still, “unaffected” should not be read as “risk-free.” A network pause can affect wallet access, exchange support, liquidity, transaction availability, and the ability to use L-BTC as the network’s fee and bridge asset. Each asset’s direct backing remains dependent on its own issuer and custody arrangement, while its operational usability depends on Liquid infrastructure returning to normal.

The architectural lesson: federation security versus a BitVM-style bridge

Liquid’s current design relies on a known, permissioned federation and threshold-controlled reserve. That is different from Bitcoin consensus directly verifying that every redemption is backed.

Current federated peg	Proposed BitVM-style 1-of-n direction
A fixed federation controls the Bitcoin reserve through threshold signing.	Blockstream describes this as a longer-term research initiative, not a deployed Liquid replacement.
Security depends on key protection, signer operations, and the correctness of shared validation and policy software.	The goal is lower trust assumptions than conventional threshold-signature designs.
A common software defect can potentially cause all automated signers to accept the same invalid interpretation.	BitVM-style systems use optimistic verification and challenge mechanisms; security depends on correct protocol design and an active honest challenger.

A BitVM-style model does not eliminate bridge risk. It moves risk into different assumptions: challengers must be able and willing to act, the fraud-proof process must be correct, and withdrawals can involve more complexity or delay. Research on BitVM-based bridges characterizes the target security model as requiring at least one honest participant, while BitVM2 aims to let anyone challenge an invalid assertion during runtime.

The Liquid incident, if the reported mechanism is confirmed, illustrates why that distinction matters. A threshold federation can be secure against stolen keys and still be exposed when every signer relies on the same flawed software interpretation of whether an asset is valid for redemption.

Bottom line

The reported $320 million Liquid event was a bridge-validation crisis, not a conventional private-key theft. An allegedly unbacked batch of L-BTC appears to have passed an authorized peg-out path, leading the federation to release real BTC. 24

The outstanding questions are consequential: the precise Elements vulnerability, the final reserve and L-BTC backing position, whether funds are returned, and what controls must change before the bridge can safely resume. Until those answers are publicly verified, users should treat the event as unresolved rather than as a completed white-hat disclosure or a routine service interruption.