Liquid Network - Rekt

Ninety-five percent of a Bitcoin sidechain's reserves walked out the door, and no signing key was compromised to do it.

On September 6th, a flaw in how Liquid Network cached confidential-transaction range-proof verifications let unbacked L-BTC pass as legitimate.

Roughly 4,000 BTC, worth $320 million, then left the Liquid Federation wallet through SideSwap’s PAK-mediated peg-out route, the same ordinary withdrawal machinery used to redeem L-BTC for Bitcoin.

The authorization path was not reportedly bypassed. It authorized L-BTC that vulnerable validation software had already accepted as real.

The actor's exit note read simply: "we are whitehats.contact us onchain"

About a day later, 3,400 BTC came back. Roughly 598 BTC did not.

If the signers followed every rule and the multisig held, where did the money actually go missing?

Liquid appears to have been among the first to say so, out loud, in public.

The federation's reserve balance made the scale visible before any formal incident report did: Roughly 4,205 BTC fell to about 197 BTC, observable through the same public mempool explorer Liquid itself pointed people toward.

Within hours of the withdrawal landing on Bitcoin's mainnet, Liquid's official account confirmed a security incident, identified SideSwap's Peg-out Authorization Key service as the route involved, and said bridge nodes had been disabled.

The notice preceded the detailed technical coverage that followed.

The actor didn't wait to be asked either. An OP_RETURN message went up on the same address, the same day: "we are whitehats. contact us on chain."

Read the message here:
C103de95817b43f2df635ec6f35ff126ca26a7c6d20570c4b01866b2b3e69a19At that stage there was no public monetary demand attached, just a claim and a request for contact.

Independent technical analysis followed within hours, not days.

By the early hours of September 7, Bitcoin developer and physicist Dr. Calle had posted a plain-language account of the emerging range-proof caching theory.

He was explicit that he had simplified the mechanics and that some specifics could prove incomplete, as the incident was still being reconstructed.

It became one of the most widely circulated technical explainers of the incident.

Researcher orangesurf raised three open questions that same evening: How did the exploit happen before the fix was widely deployed? Why did Sideshift allow the huge peg-out? Why did Liquid Network and Blockstream’s explorer diverge?

They were questions, not conclusions.

CertiK's own technical write-up, published September 7th, gave the mechanism a name more precise than anyone had managed on day one: An ambiguous cache-key encoding in the rangeproof verification cache, allowing two different validation inputs to produce the same cached entry.

Liquid’s formal incident report did not land until September 8, two days after the withdrawal. It said a range-proof-verification caching vulnerability created roughly 4,000 unbacked L-BTC that SideSwap and Liquid’s functionary nodes accepted as valid before processing the peg-out as authorized.

The report called the failure a convergence of “several individually low-probability factors,” without identifying a specific commit, function, or line.

That gap doesn't establish what the federation knew at the time. It does establish that its public technical account stayed limited while the network remained paused.

Containment took hours, public technical specificity took days.

What was the federation prepared to say then, and what did it leave for outsiders to reconstruct?

Memory Over Math

The math held, the memory didn't, and neither did the fix.

The transaction still appeared to balance. The range proof was the check meant to prevent an invalid hidden value from being accepted.

CertiK’s reconstruction says a cache hit returned success before the manipulated proof underwent cryptographic verification.

Liquid is a Bitcoin sidechain built on Elements, the open-source software that adds features such as Confidential Transactions and Confidential Assets.

Bitcoin held in the Liquid Federation’s wallet backs L-BTC issued on the sidechain; under the intended peg model, one L-BTC represents one BTC in reserve.

Liquid uses Confidential Transactions, which can hide transferred amounts while still allowing nodes to verify that a transaction’s inputs and outputs balance.

A confidential output carries a range proof, a cryptographic proof that its concealed value falls within an allowed non-negative range.

That matters because the commitment equation can otherwise balance a large positive output against a hidden negative value; the range proof prevents that negative value from being accepted as legitimate.

Range-proof verification is computationally expensive, so Elements caches successful verification results instead of repeating the cryptographic check for the same verification input.

That check runs through a function called CachingRangeProofChecker::VerifyRangeProof.

The cache lookup occurs before commitment parsing and secp256k1_rangeproof_verify. A hit returns true immediately, so the invalid proof is never cryptographically checked on a primed node.

Before the change, the cache key was built from the range-proof bytes and the value commitment, not the asset commitment or output script.

Orangesurf traced the caching approach back roughly seven years.

But CertiK found that the observed setup and attack outputs do not collide under the earlier P || C key: their old-key inputs differ in both length and content.

Commit c26d719, titled “fix: range proof cache bind to asset and scriptpubkey,” attempted to bind the cache entry to the full verification context by adding the asset generator and output script to the hash input.

The patched cache-key construction was ambiguous: Two different validation inputs could produce the same cached entry.

Proof and script are both variable-length. Shift the boundary between them, and two completely different verification inputs can produce the identical stream of bytes.

CertiK found that the observed setup and attack outputs did exactly that: Both reduce to the same 4,301-byte stream.

The valid setup output used an OP_RETURN script that pushed 67 bytes: A second value commitment, the L-BTC asset generator, and a final OP_RETURN byte.

The invalid output’s range proof ends with the bytes carried in the valid setup output’s OP_RETURN script.

Concatenate the setup output’s four fields, then concatenate the invalid output’s four fields, and both reduce to the identical 4,301-byte stream.

Same hash, same cache entry, with two different verification inputs: One valid, the other capable of creating L-BTC with no corresponding Bitcoin backing.

Connecting block 4,050,335 consumed the existing cache entry and did not store a new one on a miss. The inflation transaction therefore required a fresh valid primer to reach each accepting node after that block connected and before the invalid output was checked in block 4,050,336.

CertiK’s transaction trace places the two visible setup transactions at 13:52:10 UTC and the Liquid-side inflation transaction at 13:53:10 UTC, 60 seconds later.

The fresh valid transaction that primed the live cache remains publicly unknown; CertiK says its transaction ID and raw bytes have not been identified.

The earlier two-part key was not the collision CertiK reconstructed.

The observed setup and attack outputs do not collide under P || C; their old-key inputs differ in both length and content.

CertiK’s reconstruction specifically matches the four-part, undelimited key introduced by commit c26d719, a change that attempted to bind the cache entry to the full verification context.

CertiK says the acceptance points to a c26d719-like implementation combined with a primed cache, though the exact binaries deployed by individual functionaries have not been published.

If patching a bug is what handed someone the exploit, what exactly counts as “fixed”?

Same Block

The receipts tell their own story.

Setup Transaction (13:52:10 UTC): 271147100a94f6337b6c3db39b30c92d5b97ed91597307b6f721f73a15187ec5

Liquid-side Inflation Transaction (13:53:10 UTC, Liquid block 4,050,336): f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f

Sixty seconds separate those two. CertiK's forensic reconstruction ties the second transaction directly to the colliding cache key, the exact moment the unbacked L-BTC came into existence.

CertiK's trace also identifies two more hops within the hour:

First Hop (13:54:10 UTC): 3875a6d6ed4af708e6fd90d1c5504dc014e52c7093a566987252006d6cf1146b

Second Hop (14:00:10 UTC): c6ea588ac26f5838b6acbb2a444a33b325bbfeb39bf16dfe27b47215ffd72267

Then came the peg-outs. A smaller 2.65138358-L-BTC peg-out appeared at 14:01:10 UTC.

Smaller peg-out, 14:01:10 UTC: 46f117c990580501a5156937a8c8affda551a38b3c0b99d29eb8469ee6beb3d2

Five minutes later, the real one.

Large Peg-Out, 3,996.01834922 L-BTC (14:06:10 UTC): ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2

The Bitcoin side moved just as fast, and SideSwap's own statement confirms the sequence directly: Its service received the 4,000 L-BTC order, burned it on Liquid, and the federation paid out at 14:28 UTC.

Federation Payout: 8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140

The Federation released 3,996.02 BTC in transaction 8db751…b140; SideSwap then forwarded 3,995.99999857 BTC to the party’s address in transaction 85d2ca…5043, in the same Bitcoin block.

SideSwap forwarded 3,995.99999857 BTC to the party’s address in the same Bitcoin block as the Federation’s 3,996.02-BTC release.

Same-Block Forward: 85d2ca15bea33a592e73ed40c6a5da887feecf1e77f58ec7f580e00841645043

Two addresses, with two different roles.

The first was SideSwap’s whitelisted Bitcoin address, through which the Federation released the peg-out payout. Liquid’s September 8th incident report says the Federation released approximately 4,000 BTC through that whitelisted SideSwap address.

The second was the exploiters’ specified destination that received SideSwap’s same-block forward. SideSwap says its service forwarded 3,995.99999857 BTC to the party’s address in transaction 85d2ca…5043.

That destination was an actor-controlled consolidation and on-chain-messaging address:
Bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte

CertiK labels that address as the consolidation and on-chain-messaging address.

Later that day, the actors used an OP_RETURN message to declare: “we are whitehats. contact us on chain.”

Whitehat Message: c103de95817b43f2df635ec6f35ff126ca26a7c6d20570c4b01866b2b3e69a19

Roughly a day later, in Bitcoin block 965,950, one more transaction returned most, but not all, of the funds.

Partial-return Transaction: a6d697a25266ce3c78774fd1d75f896b7af522ada209b0f6228ea497bc49a46d

It sent 3,400 BTC to the Liquid Federation peg wallet: bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr

The same partial-return transaction sent the remaining 598.49955894 BTC back to bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte as change, an address Chainalysis identifies as actor-controlled.

The actors called themselves white hats in their on-chain message.

Taylor Monahan disagreed: “They’re not a whitehat.”

One transaction. Two destinations. One was a return. The other went back to an actor-controlled address.

Was it really a whitehat?

Before and After the Patch

The earlier cache-key flaw was old. The construction CertiK reconstructed as exploitable was new.

The earlier construction keyed the range-proof cache on the proof and value commitment while omitting the asset generator and output script.

But CertiK found that the observed setup and attack outputs do not collide under that earlier P || C key; their old-key inputs differ in both length and content.

Its reconstruction instead specifically matches the four-part, undelimited construction introduced by commit c26d719.

In other words, the long-lived omission was not the byte-level collision CertiK reconstructed from the September 6 transactions.

CertiK’s reconstruction identifies the practical failure: Distinct verification tuples could reduce to the same byte stream when variable-length components were not unambiguously delimited.

After the exploit, Blockstream released Elements v23.3.4.

Liquid said the emergency release hardened range-proof cache keys and underwent multiple rounds of internal and external review, including by Bitcoin Red Team and Alpen Labs.

One post-incident technical write-up argues that the replacement still permits a related ambiguity.

Liquid resumed block production and transactions on September 10, while keeping peg-outs disabled as a precaution. Its update said the recovery process included rigorous testing, AI-assisted code scanning, and continuous monitoring.

The dispute over the remaining BTC continued. Blockstream called taking assets without authorization and withholding their return “a crime, not responsible disclosure,” rejected paying a ransom, and said it would pursue lawful recovery if the funds were not returned.

It nevertheless said a full return could allow the actors to “revert to the standard of white-hat principles.”

The argument then turned to prior warnings.

Adam Back said the exploit involved an incorrect fix for an AI-found issue assessed as non-critical, interacting with a separate issue also judged non-critical.

Dr. Calle suggested a warning had been ignored.

Dr. Calle said: “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 still does not settle that dispute. The code changed in public. The money left days later.

Where was the review built to ask whether four byte strings still meant four separate things?

Bitcoin’s base layer never had to answer for any of this. The systems at issue did.

Liquid said its federation functionaries were not hacked, no private keys were compromised, and the peg-out mechanism operated as designed.

A vulnerability in Elements’ range-proof-verification cache allowed distinct validation inputs to map to the same cached entry; CertiK’s reconstruction says the attacker reused a cached successful result to create unauthorized L-BTC.

The resulting peg-out was then paid in BTC on Bitcoin’s mainchain.

Liquid said the exploit created roughly 4,000 L-BTC not backed by Bitcoin held in reserve; the exploiters then used SideSwap to convert the unbacked L-BTC to BTC through Liquid’s standard peg-out mechanism.

Its reserve fell from about 4,205 BTC to 197 BTC following that peg-out and additional peg-outs processed before operations were halted.

That was not a break in Bitcoin consensus. It was a failure in a Bitcoin-adjacent system that treated unbacked value as valid.

Six weeks earlier, a different failure exposed the same boundary.

TRM Labs says a March 2021 Coldcard firmware build-configuration error caused some devices to fall back to a weak software random-number generator rather than the hardware entropy source, reducing effective key strength from 128 bits to as little as 40 bits.

TRM says exploitation began on July 30, 2026, and cites Galaxy Research’s preliminary tally of roughly 1,816 BTC, about $116 million, from more than 5,200 addresses.

The technical failures differed. The lesson did not. Bitcoin’s long record without a catastrophic consensus break does not automatically extend to a wallet generating a secret, software validating a confidential transaction, or a federation holding and releasing a reserve.

Those systems may inherit Bitcoin’s utility, but they do not inherit Bitcoin’s security guarantees.

Bitcoin has survived years of people trying to break it directly.

How many more failures will the systems built around it suffer before somebody starts checking them with the same rigor?

REKT представляет собой общественную площадку для анонимных авторов. Мы не несём ответственность за выражаемые точки зрения или контент на этом веб-сайте.

Пожертвование (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

Дисклеймер:

REKT не несет никакой ответственности за любое содержание, размещенное на нашем Веб-сайте или имеющее какое-либо отношение к оказываемым нами Услугам, независимо от того, было ли оно опубликовано или создано Анонимным Автором нашего Веб-сайта или REKT. Не смотря на то, что мы устанавливаем правила поведения и нормы публикаций для Анонимных Авторов, мы не контролируем и не несем ответственность за содержание публикаций Анонимных Авторов, а также за то, чем делятся и что передают Авторы с помощью нашего Сайта и наших Сервисов, и не несем ответственность за любое оскорбительное, неуместное, непристойное, незаконное или спорное содержание, с которым вы можете столкнуться на нашем Веб-сайте и на наших Сервисах. REKT не несет ответственность за поведение, будь то онлайн или офлайн, любого пользователя нашего Веб-сайта или наших Сервисов.