Researchers investigating the roughly $320 million Liquid Network incident have identified an alleged failure in a transaction-validation cache as a possible explanation for how unbacked L-BTC was redeemed for real Bitcoin. Liquid is a Bitcoin sidechain whose L-BTC tokens are intended to be backed one-for-one by BTC held by its federation. The technical account centers on range proofs, which allow nodes to verify that concealed transaction amounts remain within permitted limits. Because those checks are computationally expensive, nodes cache successful results. Calle said an attacker could create an invalid output and proof matching the cache key of a previously valid verification, causing a node to skip the check that should have rejected newly created tokens. Charles Guillemet endorsed that explanation while noting it involved a crafted cache-key collision. Calle cautioned that his description was simplified and could contain errors. A separate reconstruction by Stu identified setup transactions followed by an allegedly invalid transaction at Liquid block 4,050,336, which created approximately 3,996.0183 L-BTC before a withdrawal through SideSwap. CryptoSlate previously reported that 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. Mononaut said the exploited bug had entered Elements’ master development branch the previous week but had not appeared in a tagged release, and that Liquid’s federation functionaries apparently ran the code while other nodes rejected the invalid transactions. Blockstream had not confirmed that deployment account in the available statements. Mononaut also said federation functionaries accepted the exploit transactions, approved withdrawals and continued building blocks, while other nodes, including those powering mempool’s Liquid explorer, rejected the affected block. That divergence could explain why some explorers omitted transactions visible elsewhere and makes the affected software versions central to the postmortem. The review would need to establish which code functions ran, why the software was deployed and how its validation behavior differed from rejecting nodes. The actors controlling the withdrawn Bitcoin have described themselves as whitehats and conditioned the return of most funds on fixing the bug across affected nodes. Available reporting does not establish that the Bitcoin has been returned or that a patch rollout is complete. Recovering the Bitcoin would address the reserve shortfall, while showing that corrected software rejects the transactions would address the validation failure that allowed the reserves to leave.