Liquid Network Incident Traced to Cache Validation Flaw in Sidechain Software

Researchers examining the roughly $320 million Liquid Network incident have identified an alleged failure in the software’s transaction-validation cache, offering a more specific explanation for how unbacked tokens could be redeemed for real Bitcoin.

Accounts also raise a deployment question. Mononaut said the exploited bug had entered Elements’ master development branch the previous week but had never appeared in a tagged release. Liquid’s federation functionaries apparently ran that code, he said, while other nodes rejected the invalid transactions.

That deployment account remains unconfirmed by Blockstream in the available statements. If established, it would put the software rollout at the center of an incident in which valid signing credentials authorized the release of Bitcoin against allegedly bug-created L-BTC.

Liquid is a Bitcoin sidechain whose L-BTC tokens are intended to be backed one-for-one by BTC held by its federation. As CryptoSlate previously reported, SideSwap said a customer submitted 4,000 L-BTC through its peg-out service on Sept. 6, prompting the release of approximately 3,996 BTC.

Liquid said neither SideSwap’s peg-out authorization key nor other federation keys had been compromised.

The emerging technical accounts focus on how the tokens reached that withdrawal process.

Calle described a flaw involving range proofs, which let nodes check that hidden transaction amounts fall within an allowed range without revealing those amounts.

Liquid’s confidential transactions require more than a check that inputs and outputs balance. A hidden negative output could otherwise offset a larger positive output, making newly created tokens appear to balance mathematically.

Range proofs are intended to prevent that outcome. Because checking them is computationally expensive, nodes cache successful verification results for reuse.

According to Calle’s account, the attacker could construct an invalid output and proof that matched the cache key associated with a previously valid check. A node finding that cached result would skip the verification that should have rejected the inflationary output.

Charles Guillemet endorsed the explanation, describing a crafted cache-key collision that allowed an invalid confidential transaction to bypass a range check. Calle cautioned that his account simplified the mechanism and could contain errors.

A separate transaction reconstruction by Stu identified setup transactions followed by an allegedly invalid transaction at Liquid block 4,050,336. Stu said the transaction created approximately 3,996.0183 L-BTC before the subsequent withdrawal through SideSwap.

Mononaut’s account adds a distinction between the nodes that accepted the transaction and those that did not.

He said federation functionaries accepted the exploit transactions, approved withdrawals, and continued building blocks. Other nodes, including those powering mempool’s Liquid explorer, rejected the affected block. That would explain why an explorer following the rejecting nodes could omit transactions visible elsewhere.

The reported divergence makes the affected software versions material to understanding the failure. A postmortem would need to establish which code functions ran, why it was deployed, and how its validation behavior differed from the nodes that rejected the block.

Meanwhile, the actors controlling the withdrawn Bitcoin have described themselves as whitehats and conditioned the return of most funds on the bug being fixed across affected nodes. The available reporting does not establish a completed return or patch rollout.

Recovering the Bitcoin would address the reserve shortfall. Explaining why federation nodes accepted the transactions and demonstrating that the corrected software rejects them would address the failure that allowed those reserves to leave.