CryptoLinks update — September 7, 2026
This is a developing security incident. At the latest verified reporting cutoff, no material return of the approximately 3,998.5 BTC controlled by the self-described white-hat party had been publicly confirmed. Liquid had disabled public bridge nodes and halted new transaction submission while federation members worked on remediation. A complete Blockstream technical postmortem and final recovery amount had not yet been published.
Key takeaways
- 3,996.018 BTC is the verified main Bitcoin peg-out. The commonly reported 4,000 figure refers to the approximately 4,000 L-BTC submitted through SideSwap and is also used as a rounded headline figure.
- Liquid says relevant federation keys were not compromised.
- SideSwap says its PAK and systems were not compromised and that the problematic L-BTC originated from an Elements bug.
- The exact rangeproof-cache mechanism remains a preliminary technical theory until Blockstream or Elements publishes a definitive root-cause analysis.
- The party controlling the BTC says it will return “most,” not necessarily all, after remediation.
- Bitcoin itself operated normally. Bitcoin consensus does not verify Liquid’s L-BTC accounting or peg authorization rules.
User safety while Liquid services are restricted
- Do not send BTC to a new Liquid peg-in address without confirming that peg services have been restored.
- Do not use unofficial L-BTC recovery or peg-out services.
- Never enter a seed phrase into a “Liquid recovery,” “peg checker” or “L-BTC migration” website.
- Do not install unofficial Elements or Liquid binaries.
- Verify exchange-specific L-BTC deposit and withdrawal status before transferring funds.
- Preserve transaction IDs for any pending peg-in or peg-out.
Neither Blockstream nor a legitimate recovery process should require your wallet seed phrase.
What happened to Liquid Network on September 6?
According to Liquid and reporting around SideSwap’s incident account, a customer supplied approximately 4,000 L-BTC to SideSwap’s peg-out service at roughly 14:05 UTC on September 6.
Under normal conditions, L-BTC sent through an authorized peg-out is burned, the federation validates that the withdrawal is authorized, and the corresponding BTC is released from the federation’s Bitcoin reserve.
At 14:28:56 UTC, Bitcoin transaction 8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140 confirmed in Bitcoin block 965,783. The principal peg-out amount was 3,996.01834922 BTC.
You can inspect the Bitcoin transaction directly on mempool.space.
Liquid subsequently said that the withdrawal went through SideSwap’s authorized PAK route but that the key “was not compromised, nor were any others.” Reuters independently reported the same core incident details.
This is why the Liquid incident does not fit the easiest “bridge hack” narrative. For a broader introduction to the different places bridge systems can fail, see our CryptoLinks guide to cross-chain compatibility, bridges and interoperability security.
Why reports say 3,996, 3,998 and 4,000 BTC
The first distinction I would make is between the amount entering the peg-out workflow, the amount released by the federation and the amount later consolidated into the actor-controlled wallet.
| Figure | What it means |
|---|---|
| ~4,000 L-BTC | Approximate amount submitted to SideSwap’s peg-out service |
| 3,996.01834922 BTC | Main federation Bitcoin peg-out |
| ~3,998.497 BTC | Later consolidated actor-controlled Bitcoin balance |
| ~4,000 BTC | Rounded headline shorthand |
SideSwap publishes a standard 0.1% peg-out fee. On 4,000 L-BTC, 0.1% is 4 BTC, which explains most of the difference between a 4,000-L-BTC order and a roughly 3,996-BTC payout, with Bitcoin forwarding/network mechanics accounting for smaller differences.
Later, Bitcoin transaction c103de95817b43f2df635ec6f35ff126ca26a7c6d20570c4b01866b2b3e69a19 consolidated approximately 3,995.99999857 BTC with another roughly 2.49749857 BTC. The resulting output was approximately 3,998.49748445 BTC.
That transaction can also be inspected on mempool.space.
The additional ~2.5 BTC should not be described as part of the single 3,996-BTC federation peg-out unless its earlier provenance is separately explained.
No federation keys were stolen—so how did the Bitcoin leave?
This is the most important technical question.
Liquid’s federation wallet uses a threshold-signing model involving 15 peg functionaries, with 11 signatures required to move federation BTC. Those signing keys are protected using specialized HSM infrastructure.
That setup is designed to make it extraordinarily difficult for one compromised organization, one stolen key or a minority group of malicious operators to take the reserve.
But multisig answers a specific cryptographic question:
Did enough authorized signers approve this transaction?
It does not independently answer:
Was the economic state used to generate that transaction legitimate?
If Elements accepted an illegitimate L-BTC balance as valid, SideSwap could see apparently valid L-BTC. The subsequent burn could look valid. The PAK authorization could be legitimate. Federation HSMs could receive a peg-out request that their software considered legitimate.
The resulting 11 or more signatures could therefore all be genuine.
What makes this incident so unusual is that the keys appear to have done exactly what they were designed to do. The apparent failure happened earlier.
How Liquid’s normal 11-of-15 peg-out works
In simplified form, a normal Liquid peg-out looks like this:
- A user holds legitimate L-BTC on Liquid.
- The user accesses an authorized peg-out service.
- A Peg-out Authorization Key permits a valid Bitcoin destination.
- The corresponding L-BTC is burned.
- Federation functionaries validate the Liquid-side peg-out state.
- At least 11 of 15 federation HSMs sign the Bitcoin payment.
- Bitcoin miners confirm the transaction and the BTC leaves the federation reserve.
Apparent September 6 path:
Elements accepts invalid/unbacked asset state → L-BTC looks legitimate → SideSwap authorized peg-out → L-BTC burn → federation validation → genuine 11-of-15 signatures → valid Bitcoin transaction → 3,996 BTC released.
SideSwap is therefore not a bridge smart contract holding the federation’s 4,000 BTC. The Bitcoin reserve itself is controlled by Liquid’s federation.
For more background on how Liquid differs from Lightning, BitVM-style systems and other Bitcoin layers, read our CryptoLinks guide to Bitcoin L2s and scaling systems.
What we know—and do not know—about the Elements bug
SideSwap has attributed the problematic L-BTC to an Elements software bug. That is more concrete than general speculation because Elements is the software foundation used by Liquid.
However, the exact mechanism by which the network apparently recognized L-BTC without corresponding newly locked Bitcoin remains a technical question requiring an official postmortem.
At this stage, I would avoid saying that the actor simply “minted 4,000 L-BTC from thin air.” The eventual postmortem needs to establish precisely whether the failure involved unauthorized issuance, balance conservation, confidential-value validation, asset commitments or another state-validation path.
The safer wording is:
Elements apparently accepted or recognized unbacked L-BTC that should not have constituted a legitimate claim on the federation’s Bitcoin reserve.
The rangeproof-cache theory explained
The leading independent technical theory focuses on verification caching around Liquid’s Confidential Transactions machinery, particularly rangeproof-related validation.
The idea can be explained safely without publishing an exploit recipe.
Cryptographic verification is expensive. Software commonly caches previous successful checks so that it does not need to repeat the same costly work every time.
Conceptually, the cache says:
“I have already verified this proof.”
That is safe only if the cache key uniquely identifies every piece of context that determines whether the proof is valid.
If a verification result valid for one asset or transaction context can accidentally be reused in another context where full validation should happen again, a node could incorrectly accept state that should have failed.
In ordinary software that might sound like a caching bug.
In a financial consensus system it can become an asset-integrity failure.
Independent forensic work has also identified repeated rangeproof-related activity preceding the large peg-out. Temporal proximity alone does not prove those transactions were exploit preparation, so that interpretation should remain provisional.
Importantly, this does not mean “privacy caused the hack.” Confidential Transactions are designed so that a hidden amount is still cryptographically constrained. If the current theory is confirmed, the problem would be an implementation/verification failure around an invariant that the privacy system was supposed to enforce.
Why SideSwap processed the 4,000 L-BTC
SideSwap’s current explanation is straightforward: its service received L-BTC that the Liquid network already regarded as legitimate.
Its PAK was authorized.
The peg-out process recognized the asset.
The relevant L-BTC was burned.
That makes “SideSwap was hacked” an inaccurate description based on the evidence currently available.
A PAK authorizes a peg-out route. It does not independently reproduce the entire Elements consensus engine and prove from first principles that every unit of L-BTC originated from a legitimate Bitcoin peg-in.
This difference echoes a broader point we have covered on CryptoLinks following other cross-chain incidents. Our Hyperbridge exploit analysis explains why wrapped and bridged assets can fail at the accounting or verification layer even when the underlying native blockchain remains healthy.
Why could a withdrawal equal to roughly 95% of reserves proceed?
This may ultimately be the most important operational question after the Elements bug itself.
The PAK whitelist existed and passed.
The federation signing threshold existed and passed.
The L-BTC burn workflow existed and passed.
But approximately 4,000 L-BTC represented an extraordinary percentage of Liquid’s reported Bitcoin reserve.
That raises obvious questions about defense in depth:
- Was there a per-transaction peg-out maximum?
- Was there a reserve-percentage limit?
- Was there a manual review threshold for extremely large withdrawals?
- Was there a velocity or anomaly detector?
- Was there an independent comparison between requested peg-outs and recent legitimate peg-ins?
- Was there a reserve-floor circuit breaker?
Liquid and Blockstream still need to explain which of these controls existed and why none stopped an economically extraordinary withdrawal that was technically valid-looking.
Finding the code bug explains how bad state could reach the system.
It does not automatically explain why that bad state had an uninterrupted path to roughly 95% of the reserve.
What does “Liquid Network is paused” actually mean?
Liquid said it disabled public bridge nodes so that new transactions could not be submitted through normal public infrastructure and asked exchanges to halt or prepare to halt L-BTC deposits and withdrawals.
The network described itself as effectively paused while federation members worked on remediation.
But “paused” should not be treated as one technical state.
There is a difference between:
- federation block signers producing Liquid blocks;
- public bridge nodes accepting transactions;
- peg-ins accepting new Bitcoin;
- peg-outs redeeming L-BTC;
- ordinary wallet transfers being relayed;
- SideSwap settlement infrastructure;
- exchange L-BTC deposits and withdrawals.
A bridge-node shutdown is therefore not the same thing as saying the Liquid blockchain itself permanently stopped.
Likewise, seeing blocks does not by itself mean that normal peg services have been restored.
Is remaining L-BTC fully backed?
This question cannot be answered simply by looking at the federation wallet and saying “95% of the reserve left, therefore every remaining L-BTC is only 5% backed.”
That calculation mixes two different things.
Proof of reserves tells us how much BTC the federation controls.
Solvency requires comparing those BTC assets with the amount of valid outstanding L-BTC liabilities.
If approximately 4,000 illegitimate L-BTC was accepted and subsequently burned through the peg-out, the exploit may have changed issued supply, burned supply and liability accounting in ways that need to be reconstructed.
The correct formula is:
Reserve ratio = federation BTC reserves ÷ valid outstanding L-BTC liabilities
Until Liquid publishes or independent analysts reconstruct both sides reliably, I would not describe all remaining L-BTC as 5% backed—or declare the system solvent or insolvent from the reserve wallet alone.
“We are whitehats”: the Bitcoin-native negotiation
The story became even more unusual several hours after the main withdrawal.
At approximately 18:30 UTC on September 6, the party controlling the withdrawn BTC consolidated the funds and embedded an OP_RETURN message:
“we are whitehats. contact us on chain”
Later communication attributed to the same coin-controlling party said, in substance, that it would return “most” of the Bitcoin after the bug was fixed, adding that nodes across the network should be patched before the money was sent back.
Blockstream responded through on-chain communication associated with PGP-authenticated security messages.
This makes the conversation far more verifiable than random social-media posts. Coin control can authenticate messages originating from the relevant Bitcoin holder, while PGP signatures can authenticate Blockstream’s side.
But authentication is not proof of benevolent intent.
I would not call the actor a white hat simply because the actor called itself one.
There are facts supporting a constructive interpretation: the funds remained highly visible, communication was initiated, technical information was reportedly shared, network-wide remediation was requested and the party said most BTC would be returned.
There is also an obvious skeptical interpretation: nearly an entire sidechain reserve was moved without prior public authorization, control of roughly $320 million was retained, normal responsible-disclosure channels were apparently not used first, and the promise says “most” rather than “all.”
The word matters.
No exact return amount, authorized bounty or final agreement should be assumed until it is publicly authenticated.
Bitcoin itself was not hacked
This point should be explicit.
Bitcoin miners and nodes processed a normal Bitcoin transaction containing valid inputs, signatures and outputs.
Bitcoin does not maintain Liquid’s L-BTC ledger.
Bitcoin does not know whether a Liquid balance originated from a valid peg-in.
Bitcoin does not enforce SideSwap PAK rules.
Bitcoin does not calculate Liquid’s L-BTC supply.
It simply verified that the Bitcoin-side transaction satisfied Bitcoin’s own consensus rules.
Bitcoin validated the payment. Bitcoin had no way to know that the economic state behind the payment was allegedly wrong.
This is also why Liquid cannot simply “roll back Bitcoin” to recover the 3,996 BTC. Once the transaction is confirmed on Bitcoin, reversing Liquid-side history would not undo Bitcoin mainchain settlement.
Recovery requires another Bitcoin transaction, voluntary cooperation from the holder, control over the destination keys or some separate legal/recovery process.
What this incident teaches us about federated Bitcoin sidechains
The easiest conclusion would be that multisig failed.
I think that misses the most important lesson.
An 11-of-15 multisig is designed to protect against stolen keys, malicious minority signers and individual operator failures.
It is not designed to independently detect a shared software-consensus error that all participating systems interpret as valid.
A federation can have:
- geographically distributed organizations;
- independent HSM keys;
- a high signing threshold;
while still relying on:
- one shared Elements implementation;
- one interpretation of Liquid consensus;
- one interpretation of asset validity.
In other words, you can have 15 independent keys but one shared software assumption.
That is correlated software risk.
The broader lesson is that key diversity and software diversity solve different security problems.
This also explains why readers should not assume that all systems described as “Bitcoin Layer 2” carry the same risks. Lightning payment channels do not depend on one federation wallet backing every Lightning bitcoin. Liquid does.
If you want a broader map of those trade-offs, our Bitcoin L2 guide compares the different architectures, while our chain-abstraction guide examines how hidden cross-chain infrastructure can shift risk between wallets, bridges and verification systems.
What must happen before Liquid can call this resolved?
A patched binary alone is not enough.
Before full restoration, I would want to see:
- The exact root cause publicly confirmed.
- Every vulnerable Elements release identified.
- A reviewed fix committed and released.
- All relevant federation functionaries upgraded.
- Bridge-node infrastructure upgraded and restarted safely.
- Any vulnerable verification cache invalidated or rebuilt correctly.
- Historical Liquid state audited for additional invalid asset state.
- L-BTC supply reconciled.
- Bitcoin reserves reconciled against legitimate L-BTC liabilities.
- SideSwap and other PAK operators upgraded where necessary.
- Regression tests added for the identified failure and obvious variants.
- The actor’s claimed vulnerability information independently verified.
- Any returned Bitcoin confirmed on-chain.
- Exchange deposit and withdrawal rails restored in a controlled sequence.
The public Elements repository is also worth watching. At our September 7 check, its release page still identified Elements 23.3.3 as the latest tagged release, originally published in April 2026. Public code history contains earlier proof-related fixes, but that alone does not prove developers understood the security impact of the September incident before it happened.
There is an important difference between:
a code-quality fix existing,
a vulnerability being recognized as critical,
a production release being available, and
every affected production node actually being upgraded.
