$320 million worth of Bitcoin was stolen using a fake account. Is Bitcoin really insecure?

By: Xiang Ming

On September 6th, an unusual withdrawal of approximately $320 million thrust Liquid Network into the spotlight.

That day, about 4,000 BTC were transferred out of the Liquid Federation Wallet, equivalent to about 95% of the approximately 4,200 BTC reserves held before the incident. Liquid subsequently suspended network transactions, and several platforms suspended L-BTC deposits and withdrawals.

The situation then took a turn. The attacker, claiming to be a "white hat," communicated with Blockstream through the OP_RETURN field in Bitcoin transactions, stating that the funds would be returned after the vulnerability was patched.

The attack then took a turn.

... As of September 9th, Chainalysis' latest update showed that approximately 85% of the BTC had been returned, and Blockstream had deployed software updates to fix the vulnerability. However, approximately $47 million remained unreturned. From "Stolen Private Key" to "L-BTC Created Out of Thin Air" When the incident first occurred, the most obvious explanation was that the Federation Wallet's private key or the PAK used by SideSwap had been compromised. After all, for most cryptocurrency thefts, if hundreds of millions of dollars were transferred from wallets, "key breach" is often the most straightforward explanation. However, technical analysis largely ruled out this possibility. On September 9th, Chainalysis confirmed that the problem stemmed from a vulnerability in Liquid's transaction verification software. The attackers did not obtain the control key for the Federation Wallet. Instead, they exploited a flaw in the verification process to create L-BTC that shouldn't have existed and wasn't backed by real BTC. They then used the normal peg-out process to exchange these "fake L-BTC" for real BTC in the Federation Wallet. Understanding this requires understanding how Liquid operates. Liquid, developed by Blockstream, is a federated sidechain operating independently of Bitcoin. Users lock 1 BTC in their Federation multisignature wallet on the Bitcoin mainnet and receive 1 L-BTC on Liquid. When they want to exit, the L-BTC is destroyed, and the Federation releases the corresponding BTC to the user. This is the so-called two-way peg. According to Liquid's official design, L-BTC in circulation should always be backed by an equal amount of BTC. Therefore, this system actually has two sets of ledgers that must always correspond: the BTC reserves on the Bitcoin mainnet, and the L-BTC issued internally by the Liquid network. This attack didn't directly modify the first ledger; instead, it first made a mistake in the second. Liquid uses Confidential Transactions to hide transaction amounts, so nodes need to use cryptographic proofs such as range proofs to confirm that a transaction hasn't created assets out of thin air. To reduce the computational burden of repeated verification, Liquid's software caches successfully verified results. However, Chainalysis revealed a flaw in the caching mechanism: new invalid data might be mistakenly identified as previously verified data under certain conditions, thus skipping re-verification. The attacker exploited this vulnerability, causing some nodes to accept invalid transactions, ultimately creating L-BTC without corresponding BTC reserves. CertiK's technical analysis of the incident also points in the same direction: the problem lies in the rangeproof caching mechanism in the Elements codebase that verifies Confidential Transactions. The attacker first constructs a transaction "pre-warming" cache, then submits a malicious transaction, causing the verification software to incorrectly accept unauthorized L-BTC issuance. From this point onward, subsequent peg-outs may actually be completely "normal." For SideSwap and Liquid Federation, what they see is a block of L-BTC that has already passed Liquid consensus verification and can circulate normally. According to the established rules, after the L-BTC is destroyed, the Federation should release the real BTC. Therefore, what actually happened was not an attacker "bypassing the signature to steal BTC," but rather more like a bank's back-end system mistakenly adding 40 million yuan to an account, and then the teller allowing the user to withdraw the 40 million yuan according to normal procedures. Liquid had a problem, so why was BTC actually taken? This has led to two seemingly contradictory assessments surrounding the incident. One view argues that it's unrelated to Bitcoin security. Liquid has its own nodes, consensus mechanism, software code, and Federation; it's essentially an independent sidechain. The Bitcoin mainnet didn't experience a 51% attack, consensus failure, or any artificial issuance of BTC. In this sense, calling the incident a "Bitcoin network hack" is inaccurate. Another concern isn't entirely unfounded: even if the vulnerability isn't in Bitcoin, the ultimate loss is real BTC. Moreover, these BTC were locked in the Federation Wallet precisely because users believed "1 L-BTC = 1 BTC." This actually touches on a common issue shared by all wrapped assets and cross-chain assets: the security of the underlying asset does not equate to the security of its mapped assets on other networks. Liquid's official technical documentation explicitly states that sidechains have different rules, performance requirements, and security mechanisms than Bitcoin, and these additional features also imply new security trade-offs. Liquid does not rely on Bitcoin's PoW miners to generate blocks; instead, it adopts a Strong Federation model, with a group of functionaries responsible for block signing and BTC custody. Peg-out involves the Federation verifying the destruction of L-BTC before releasing the BTC on the Bitcoin mainnet. Therefore, when BTC enters Liquid, users are essentially adding a new layer of security assumptions: in addition to trusting Bitcoin itself, they must also trust Liquid's consensus implementation, transaction verification code, Federation operating mechanism, peg-in/peg-out rules, and software upgrade process. This incident breached the software verification layer. In the past, discussions about cross-chain and encapsulated asset security often focused on whether the reserves actually existed and who controlled the private keys. This Liquid incident reminds the market that a third question is equally important: what rules does the system use to prove that a mapped asset is eligible for minting, circulation, and redemption? As long as this accounting and verification logic can be broken, even if the reserves actually exist and no private keys are leaked, the underlying assets can still be "erroneously paid out" through legitimate processes. So, is the Bitcoin network truly insecure? If the "Bitcoin network" mentioned here refers to the Bitcoin mainnet, the answer is relatively clear: there is currently no evidence that this incident compromised Bitcoin's consensus security. No new BTC was created out of thin air, no Bitcoin blocks were tampered with, and Bitcoin's signature algorithm or PoW mechanism was not breached. Chainalysis also emphasized in its review that the financial layer built on top of Bitcoin could introduce new vulnerabilities, even if Bitcoin itself remains secure; the problem lies in the Liquid's mechanism for minting and redeeming L-BTC, not in the Bitcoin protocol. However, if the question becomes "Are BTC stored on the Bitcoin mainnet absolutely immune to losses due to vulnerabilities in external systems?" the answer is clearly no. Bitcoin can guarantee that its own ledger operates according to established consensus rules, but it cannot guarantee the security of exchanges, custodians, cross-chain bridges, sidechains, or wrapped assets. Once BTC leaves an individual's controlled wallet and is locked in a custodian address or protocol reserve, its ultimate security becomes the result of the combined action of multiple layers of systems. This is the real conclusion the Liquid incident should leave us with. As Bitcoin Fi, RWA, cross-chain assets, and various tokenized assets continue to develop, more and more assets will adopt similar structures: the bottom layer is the real asset, and the top layer is on-chain credentials or mappings. The market used to ask "Is the reserve ratio 100%?"; in the future, it may need to ask: Who decides whether this credential is genuine, and is this judgment process prone to error? From this perspective, the Liquid incident is not a denial of Bitcoin's consensus security, but rather reveals a more realistic problem: the more secure the underlying blockchain is, the more likely the risk is to migrate to the financial infrastructure above it. And once assets are packaged, cross-chained, and tokenized, the so-called "1:1 collateral" is never just a matter of reserves. It's a suite of software, accounting, and verification rules. If any layer fails, a 1:1 balance on the books can become 0:1 within minutes.