Liquid Network Exploit Drains Most Reserves via Peg-Out Vulnerability

An estimated 95% of a major Bitcoin sidechain’s holdings exited without any compromise of signing keys, as detailed in CodeAnt's analysis.

On September 6th, a vulnerability in Liquid Network’s caching of confidential transaction range-proof verifications enabled the creation and subsequent withdrawal of unbacked L-BTC, which were wrongly treated as legitimate by the system. (CertiK incident report)

Approximately 4,000 BTC, equivalent to $320 million at the time, were transferred from the Liquid Federation’s reserves through the typical SideSwap peg-out process—identical to routine L-BTC to BTC withdrawals. The exploit did not circumvent the authorization checks. Instead, it authorized L-BTC that the software had already mistakenly validated as genuine.

The party behind the event left an on-chain message: “we are whitehats.contact us onchain”. (Source)

Roughly a day afterward, 3,400 BTC was returned to the federation’s wallet, while about 598 BTC remained unreturned. (Transaction reference)

This raises the question: despite protocol rules being followed and the multisig holding, how did the reserves vanish?

Credit: CodeAnt, CertiK, Liquid Network, Charles Guillemet, Samson Mow, Dr. Calle, orangesurf, Elements, SideSwap, Tayvano, Blockstream, Adam Back, TRM Labs

Liquid Network was among the first to confirm the incident openly. Before any in-depth technical disclosure, the federation’s reserve balance revealed the severity: over 4,200 BTC dropped to about 197 BTC, a change observable via public block explorers.

Within hours after the withdrawal appeared on Bitcoin’s mainnet, Liquid acknowledged a security issue, identified SideSwap’s Peg-out Authorization Key as the channel used, and deactivated bridge nodes. This was announced before the subsequent technical analyses were released.

The actor’s statement was published on-chain the same day, reading: “we are whitehats. contact us on chain.” (OP_RETURN message)

Technical investigations began promptly. By early September 7, Dr. Calle, a physicist and Bitcoin developer, provided a layperson’s explanation of the suspected range-proof caching flaw, noting that details might still be incomplete due to ongoing incident analysis.

This explanation became widely referenced for understanding the exploit’s mechanics.

Researcher orangesurf raised several questions that evening:

• How did the exploit occur before the patch was broadly applied?
• Why did Sideshift process such a large peg-out?
• Why did data from Liquid Network and Blockstream’s explorer differ? (Source)

On September 7, CertiK published a detailed technical breakdown that characterized the flaw as an ambiguous cache-key construction in the range-proof verification cache. This ambiguity allowed distinct validation inputs to be treated as identical, thereby enabling the exploit. (CertiK blog)

Liquid’s own comprehensive incident report was released on September 8, confirming that a caching bug in the range-proof verification allowed about 4,000 unbacked L-BTC to be processed and withdrawn via SideSwap, with these being accepted as valid by both SideSwap and the Liquid nodes. (Official report)

The report described the issue as a rare convergence of multiple unlikely factors, but stopped short of naming a specific code commit or function.

Public technical details were limited until the situation was stabilized, with containment taking hours and technical clarity requiring days.

Cache Vulnerability Over Cryptography

Though the cryptographic math held, the memory cache implementation did not—and the attempted fix was also insufficient. Range proofs are meant to ensure that confidential transactions do not hide invalid values, but due to caching, a past successful verification could be mistakenly reused. (CertiK analysis)

Elements, the software underlying Liquid, caches successful range-proof verifications for efficiency. The relevant function is CachingRangeProofChecker::VerifyRangeProof. (Code reference)

Previously, the cache key was generated from the range-proof and value commitment only, omitting the asset generator and output script. Over seven years ago, this cache approach was introduced. (orangesurf)

CertiK determined that the observed setup and attack outputs did not collide under the old key. However, a later patch (commit c26d719) altered the cache-key construction to include asset and scriptpubkey, but did so without clear delimiters, making it ambiguous. (Patch reference)

Proof and script fields are both variable-length, so shifting the boundary between them could yield the same byte sequence for distinct validation inputs, causing a cache collision. (Technical gist)

CertiK’s analysis showed that both the valid setup and the attack output reduced to the same 4,301-byte sequence. The valid setup used an OP_RETURN script pushing 67 bytes; the invalid output’s range proof ended with these bytes. (CertiK blog)

Thus, two different validation inputs resulted in the same cache key—one legitimate, the other resulting in unauthorized L-BTC creation.

On block 4,050,335, the cache entry was consumed, so the inflation transaction that followed required a new valid transaction to prime the cache before the invalid transaction was verified on block 4,050,336. (CertiK blog)

CertiK traced the setup and attack transactions to 13:52:10 UTC and 13:53:10 UTC, respectively, noting the exact sequence that allowed the unbacked L-BTC to be generated. (CertiK blog)

Transaction Timeline and Flows

Key transactions identified:

• Setup Transaction (13:52:10 UTC): 271147100a94f6337b6c3db39b30c92d5b97ed91597307b6f721f73a15187ec5
• Inflation Transaction (13:53:10 UTC): f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f

Further hops occurred within the hour:

• First Hop (13:54:10 UTC): 3875a6d6ed4af708e6fd90d1c5504dc014e52c7093a566987252006d6cf1146b
• Second Hop (14:00:10 UTC): c6ea588ac26f5838b6acbb2a444a33b325bbfeb39bf16dfe27b47215ffd72267

This was followed by peg-outs:

• Smaller Peg-Out (14:01:10 UTC): 46f117c990580501a5156937a8c8affda551a38b3c0b99d29eb8469ee6beb3d2
• Major Peg-Out (3,996.01834922 L-BTC at 14:06:10 UTC): ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2

The federation paid out the peg-out on Bitcoin at 14:28 UTC: 8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140, which SideSwap then forwarded (3,995.99999857 BTC) to the actor’s address in the same block: 85d2ca15bea33a592e73ed40c6a5da887feecf1e77f58ec7f580e00841645043. (SideSwap statement)

• The initial recipient was SideSwap’s whitelisted address; the subsequent transfer was made to the actors’ consolidation and on-chain messaging address: Bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte. (CertiK labeling)

That same day, the actors used an OP_RETURN message to reiterate: “we are whitehats. contact us on chain.” (Transaction)

Roughly 24 hours later, in Bitcoin block 965,950, a transaction returned 3,400 BTC to the federation’s peg wallet: a6d697a25266ce3c78774fd1d75f896b7af522ada209b0f6228ea497bc49a46d.

The remainder, about 598.5 BTC, was sent as change back to the actor-controlled address. (Chainalysis report)

While the actors identified themselves as white hats, some disagreed with this classification: “They’re not a whitehat.”

Patch History and Aftermath

The original cache-key flaw was longstanding, but the exploitable construction analyzed by CertiK was more recent. Previously, the cache key consisted of only the proof and value commitment, but the new (commit c26d719) undelimited four-part key allowed for ambiguity. (CertiK analysis)

After the incident, Elements v23.3.4 was released (Release notes), with Liquid stating the update strengthened cache keys and underwent multiple reviews, including by external security teams. (Announcement)

However, some technical commentary suggested the revised fix might still allow a related vulnerability.

Liquid resumed normal operations, excluding peg-outs, on September 10 after extensive internal testing, AI code scans, and ongoing monitoring. (Update)

Debate continued over the retained funds. Blockstream called the withholding of assets “a crime, not responsible disclosure,” declined ransom discussions, and stated legal action would be pursued if assets were not returned. (Blockstream statement)

However, Blockstream added that a full return would allow the actors to “revert to the standard of white-hat principles.”

Discussion also turned to past warnings. Adam Back claimed the exploit resulted from an incorrect fix for a non-critical AI-identified issue, combined with another minor vulnerability. (Adam Back statement) Dr. Calle asserted that a prior warning had not been acted upon. (Dr. Calle statements, follow-up)

Dr. Calle stated: “We will give Blockstream time to restore orderly operations and publish a postmortem on the Liquid hack before we share our own complete account of the disclosure process.”

The public record does not yet resolve this dispute. The code base changed openly, and the exploit occurred days later.

Liquid clarified that federation functionaries were not compromised, no private keys were accessed, and the peg-out system worked as intended. (Incident report)

A flaw in the Elements range-proof cache allowed the same cached result to be reused for different validation inputs, enabling the unauthorized creation of L-BTC, which was then redeemed for BTC on Bitcoin’s mainnet. (CertiK incident analysis)

Liquid reported that about 4,000 L-BTC were created without Bitcoin reserve backing, and converted through the usual peg-out process. (Incident report) The federation’s reserves dropped from over 4,200 BTC to under 200 BTC following the event, before operations halted.

This was not a consensus failure in Bitcoin itself, but rather a breakdown in a system adjacent to Bitcoin that misrecognized unbacked value as valid.

Six weeks prior, a separate issue highlighted similar risks: TRM Labs reported that a 2021 Coldcard firmware error led some devices to use weak software RNG, reducing key strength drastically, enabling theft of an estimated 1,816 BTC (about $116 million) from over 5,200 addresses. (TRM Labs report)

Although the technical failures were distinct, the lesson is consistent: Bitcoin’s consensus security does not automatically extend to sidechains, wallets, or federations handling reserves.

Bitcoin’s core has remained robust for years. The systems built around it, however, may still be subject to major flaws until they undergo equally rigorous scrutiny.