Valid signatures can pay an invalid claim
The September 2026 Liquid incident illustrates how real bitcoin can leave a reserve without its keys being stolen. A software flaw let counterfeit L-BTC pass validation on Liquid. An authorized withdrawal service then processed those tokens as if they were genuine claims on the bitcoin reserve.
The failure crossed two boundaries: from invalid transaction data to an accepted Liquid balance, then from that balance to a Bitcoin payout. Secure signatures at the second boundary could not repair faulty accounting at the first.
This article explains the incident described in the supplied September 9–11 reports. Statements about reopening, missing reserves, and redemption restrictions refer to those dated accounts; they are not a claim about the service’s present operational status.
Two ledgers and a reserve
Liquid is a Bitcoin sidechain built with Elements software. Its L-BTC asset is intended to represent bitcoin held in the federation’s reserve. Under normal operation, a BTC deposit supports a corresponding L-BTC claim.
The original bitcoin remains on the Bitcoin network. Liquid maintains a separate ledger recording the asset that users can spend there. A peg-in connects a Bitcoin deposit to a Liquid claim; a peg-out destroys the Liquid claim and releases reserve bitcoin through the authorized withdrawal process.
The technical overview describes the federation roles and access rules. Ordinary users can hold and send L-BTC with their own keys, but generally need an authorized participant or service to convert it back through a federation peg-out. Controlling a Liquid wallet therefore differs from controlling the keys to the backing reserve.
Bitcoin validates the reserve’s Bitcoin transactions under Bitcoin’s rules. It does not run every Liquid transaction or determine whether each L-BTC balance arose legitimately. That responsibility sits in the sidechain’s validation and accounting system.
Confidential amounts still require full validation
Liquid’s confidential transactions hide amounts and asset types behind cryptographic commitments. A commitment lets a value participate in mathematical checks without publishing that value openly. Privacy changes how validation is performed; it does not remove the requirement to validate.
Checking that inputs and outputs balance is insufficient on its own. A deliberately simplified example shows why: ten units in could appear to balance fifteen units out plus negative five. If the fifteen were spendable while the negative output had no useful economic effect, conservation on paper would not protect the money.
Range proofs prevent amounts outside their allowed range from being accepted without exposing the amounts themselves. The example is an explanation of the requirement, not a reconstruction of the exploit’s actual arithmetic.
These proofs require work to verify. Caching successful verification results can reduce repeated computation, provided the saved result corresponds exactly to the inputs being checked next.
The cache confused different verification inputs
The published Elements range-proof cache patch explains the critical encoding problem. Different groups of inputs could generate identical concatenated bytes in the old cache-key construction. The fix added length information to separate the fields and an option to disable this cache.
The ambiguity can be written as AB + C = ABC and A + BC = ABC. The final bytes match even though the boundary between the fields moved. Recording each field’s length preserves that boundary before a cache key is formed. This analogy describes ambiguity before hashing, rather than a break in the cryptographic hash function.
If a successful cached result is reused for different verification inputs, a transaction that should fail can be accepted. A signature cannot compensate for that error. It proves authorization to spend under the relevant key, not that the transaction’s hidden values are valid.
A cache is also local software state. A node freshly checking the same blockchain data can reach a different result from a node that previously reused an inappropriate cache entry. SideSwap’s incident account says an independent node rejects the transaction that created the unbacked coins, while its operating node’s software accepted it during the incident.
The normal payout route turned the claim into bitcoin
According to SideSwap’s September 9 statement, the attacker tested a small withdrawal before submitting an order for 4,000 L-BTC. The service burned the tokens through an authorized peg-out, and the federation released roughly 3,996 BTC. SideSwap automatically forwarded the customer payout in the same Bitcoin block.
The service reported that its keys, wallets, and systems had not been compromised. It instead identified operational weaknesses in keeping a peg-out authorization key online with automated forwarding, alongside inadequate size limits, rate controls, and human review in its order pipeline.
This was the equivalent of an authorized cashier accepting a forged warehouse receipt. The vault’s lock could work as designed while the system paid out goods against a claim that should never have existed. Better key protection alone would not distinguish that counterfeit receipt.
Burning the counterfeit L-BTC after paying the bitcoin did not replenish the reserve. The fake claim disappeared, but genuine backing had already left. Nor could a reversal on Liquid automatically reverse a confirmed Bitcoin transaction: the ledgers operate under different rules.
Patching, reopening, and restoring backing are separate jobs
The Elements 23.3.4 release addressed the proof-cache issue. Fixing validation concerns whether affected nodes accept bad transactions. Resuming transaction processing concerns whether the network can operate. Neither action alone returns missing bitcoin.
The dated reports described about 3,400 BTC returned on September 7, with approximately 598.5 BTC still unreturned in the September 11 account. These rounded incident figures include separate flows and fees; they should not be treated as a precise subtraction from exactly 4,000 BTC.
SideSwap’s September 11 reopening notice said peg-ins had reopened while peg-outs remained disabled and reserves were below circulating L-BTC. It also relayed Blockstream’s commitment to cover the peg one to one. A commitment to restore backing is different from evidence that restoration is complete.
The useful questions are therefore separate: can payments run, does the reserve cover the outstanding asset, and can holders redeem through the intended route? A functioning market answers none of the other questions by itself.
A wallet balance does not measure backing
Self-custody establishes authority over the tokens controlled by a wallet. It does not establish the quality of their backing or guarantee a working exit. A holder might retain an unchanged L-BTC balance while the reserve or redemption system has changed.
Selling to another participant also differs from redemption. A sale needs a willing buyer and sufficient liquidity at the offered price. Redemption relies on the system releasing the backing asset. The intended one-to-one peg is not proof that every market trade occurs at that ratio.
For a wider comparison, custodial and self-custody wallets explain who controls spending authority. This incident adds another question: who and what validates the asset that authority controls?
Follow the incident in order: the sidechain accepted the counterfeit claim, the service requested its withdrawal, and the Bitcoin reserve paid it. Each stage trusted a result from the previous one. The valid payout signatures explain who authorized the Bitcoin transaction; the earlier validation failure explains why an illegitimate claim reached that stage. This particular bug does not establish that all confidential transactions or sidechains share the same flaw.
