A suspected software exploit on the Liquid Network enabled the unauthorized withdrawal of roughly 3,996 bitcoin from its federated custody wallet on Sept. 6, after attackers allegedly created unbacked L-BTC that passed the network’s normal validation and peg-out process. The bitcoin was valued at about $320 million at the time, making it the largest reported crypto-asset theft by value so far in 2026, according to TRM Labs.
The incident did not involve stolen federation keys, compromised hardware security modules, phishing, or a disclosed insider breach. Instead, the attacker appears to have exploited inconsistent transaction validation among federation nodes, allowing a forged transaction to enter a Liquid block and create L-BTC without the corresponding bitcoin being locked in the network’s custody wallet.
Liquid uses L-BTC as a bitcoin-backed asset designed for quicker settlement than Bitcoin’s main chain. Users peg bitcoin into Liquid by depositing BTC into a jointly controlled federation wallet, receiving an equivalent amount of L-BTC. When users peg out, the L-BTC is burned and the federation releases the matching amount of bitcoin.
That structure depends on the federation maintaining a one-to-one relationship between L-BTC and bitcoin held in custody. Once the attacker minted L-BTC that was not backed by deposited BTC, the standard peg-out system treated those tokens as valid and released real bitcoin.
Forged L-BTC passed routine federation checks
At 15:53:10 UTC on Sept. 6, Liquid block 4,050,336 included a transaction that reportedly created 3,996 L-BTC without backing. The attacker then submitted a peg-out request for 4,000 L-BTC, triggering the federation’s regular withdrawal process.
Liquid’s federation consists of 15 known entities that validate blocks and jointly control the bitcoin custody wallet. A withdrawal normally requires 11 of the 15 federation members to sign. Each member operates its signing key through a dedicated hardware security module, or HSM.
In this case, the threshold-signing mechanism operated as designed because the transaction had already been accepted by affected nodes as valid. Federation members reportedly completed routine checks, including confirming the destination address was allowlisted and that the stated L-BTC burn matched the requested bitcoin withdrawal.
About 35 minutes later, the Bitcoin blockchain confirmed the release of 3,996 BTC from the federated wallet. Liquid’s emergency recovery process, which reportedly requires two-thirds of backup keys and a 56-day delay, was not activated because the withdrawal followed the ordinary signing path.
The episode shows how a failure in transaction-validation software can bypass strong custody controls without directly defeating the cryptographic keys that protect a shared wallet. The 11-of-15 threshold guarded access to the bitcoin, but it did not protect against federation members collectively approving a withdrawal based on invalid L-BTC.
Range-proof cache issue is the leading explanation
External researchers traced the suspected exploit to a flaw in the Elements software used by Liquid. Elements supports Confidential Transactions, a feature that hides transaction amounts on-chain while allowing nodes to verify that no invalid value has been created.
Confidential Transactions use cryptographic range proofs. These proofs establish that a hidden amount falls within an allowed range without revealing the amount itself. Nodes must validate those proofs carefully, because a mistaken approval can allow an asset supply to be inflated.
The researcher reconstruction points to a range-proof verification cache that keyed validated proofs using the proof bytes and a value commitment, while allegedly failing to bind that cached result to the asset type or output script. That omission could allow a proof that was valid in one transaction context to be reused in another context where it should have failed verification.
During roughly 14 hours before the withdrawal, the attacker reportedly placed 68 identical range proofs on the Liquid blockchain, apparently preparing caches on affected nodes. When the same proof was later reused in a different transaction context, nodes with the relevant cache state reportedly treated it as already verified.
The result was inconsistent behavior across Liquid infrastructure. Bitcoin Core developer Antoine Poinsot wrote that the critical block was “rejected by mempool” but “accepted by Blockstream.” Mempool.space, which has been identified as a Liquid federation member, reportedly recorded an abnormal extraction of minus 4,019 BTC while Liquid’s dashboard did not reflect the same state at that point.
Blockstream did not formally confirm the range-proof cache issue as the root cause. The explanation remains an external reconstruction based on reported code behavior, network activity and the timing of an earlier patch.
A code change addressing cache binding was submitted on Aug. 3 and merged into Elements’ master branch on Sept. 2, according to the project’s code history. The change described binding the range-proof cache to the asset and output script. Federation nodes were reportedly running Elements 23.3.3, released on April 13, at the time of the incident; that release did not contain the patch. The fix was later merged into the release branch less than three hours after the Sept. 6 event.
Backing fell below 5% before partial return
The theft exposed a practical limitation of Liquid’s Confidential Transactions: outside observers cannot continuously reconcile the visible BTC reserves with the full L-BTC supply in real time because L-BTC amounts are hidden on-chain.
Following additional withdrawals, reported figures showed 4,205 L-BTC in circulation while the federated wallet held 197 bitcoin. That would have left L-BTC backing below 5%, creating a severe shortfall for users seeking to redeem the asset for BTC.
Later on Sept. 6, the address that received the bitcoin posted an OP_RETURN message stating, “we are whitehats. contact us on chain.” The following day, 3,400 BTC — described as about 85% of the extracted amount — was returned. At the quoted value, the returned funds were worth roughly $272 million, while 598.5 BTC worth about $47 million remained outside the federation wallet.
Messages posted on-chain from Sept. 8 to Sept. 9 demanded a further 10% bug bounty as a condition for returning the remainder. The messages warned that rejecting the payment would leave L-BTC holders with a 15% loss.
Charles Guillemet, chief technology officer at Ledger, said a white-hat approach would involve disclosing a vulnerability before removing collateralized funds. Negotiating payment after taking the underlying assets, he said, resembled extortion rather than security research.
Blockstream said it would not pay a ransom and characterized the removal and refusal to return the remaining bitcoin as theft. The company said it would seek recovery through law enforcement, legal channels, service providers and blockchain-forensics specialists.
Network restart leaves peg services paused
Liquid resumed block production at 12:26 UTC on Sept. 10, although it had not yet resumed packaging user transactions. Peg-ins and peg-outs remained paused under a three-stage recovery plan: restarting block production, replaying verified transactions, and reopening the peg after state checks are completed.
After the 3,400 BTC return, reported backing for L-BTC rose to about 86%. Adam Back, Blockstream’s chief executive, said the network would maintain the one-to-one L-BTC peg while the remaining 598.5 BTC moved into an investigation and recovery process.
The recovery now rests on both technical remediation and confidence in operational controls. Jameson Lopp, security lead at Casa, said public records showed the last commit in the federation node repository was in April 2024, more than two years before the incident. Combined with the reported delay in deploying the cache-binding fix, that timeline has focused attention on how federation software is maintained, tested and rolled out across critical signing infrastructure.
For Liquid users, the incident places renewed weight on the distinction between holding BTC on Bitcoin’s base layer and holding an asset whose redeemability depends on a federation wallet, software releases and the continued operation of a peg mechanism.
To strengthen your defenses after this exploit, learn essential crypto safety standards every trader should know and protect your assets.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
