Summary
On 6 September 2026 a consensus bug in the Elements software that underpins the Liquid Network allowed a party to create approximately 4,000 L-BTC that was backed by no deposit. That party sent the newly created L-BTC to SideSwap's peg-out service, which processed it as an ordinary customer order: the L-BTC was burned on Liquid, and the Liquid Federation released approximately 3,996 BTC to the Bitcoin address the party had provided. Blockstream has since described the bug publicly, and SideSwap's own independent Liquid node confirms it by rejecting the transaction that created the coins. No SideSwap key, wallet, or system was compromised, as Blockstream has stated.
We want to be direct about our part. The software fault was not ours, but two choices in how we operated our peg-out service turned a fault on Liquid into a real loss on Bitcoin, and we take full responsibility for both. Funds held in SideSwap wallets are unaffected: SideSwap is non custodial, and those assets are controlled by their owners' own keys. The Liquid Network is currently paused while Blockstream and the Federation coordinate a fix and a restart.
What we take responsibility for
Two failures were ours, and we own them without qualification.
Our peg-out key was kept online, and payouts were automatic. SideSwap's peg-out authorisation key was held online on our server, and every Federation payout was forwarded to the customer automatically, in the same Bitcoin block. That design is what turned a reversible event on Liquid into an irreversible payment on Bitcoin. Had the key been kept offline, with the forward to the customer made manually and after a delay, the funds would have remained under SideSwap's control and could have been returned. We should have run it that way, and we did not.
We did not have adequate checks on peg-out orders. Our peg-out pipeline processed this order automatically, with no limit on size, no rate or velocity control, no cap relative to the total supply of L-BTC, and no check on the age or history of the depositing wallet. An order for roughly 4,000 L-BTC, a very large share of all L-BTC in existence, placed from a wallet only hours old, was handled with no human review and nothing to hold it. Straightforward volume, velocity, and origin checks would have caught it. We had none in place.
These were ours to get right as the operator of the service. Below we explain, without offering it as an excuse, why the service worked this way, and how we intend to put it right.
Why our peg service worked this way
We built the peg-in and peg-out service to remove friction for users, not to cut corners. Pegging in without help requires a user to run both a Bitcoin and an Elements node and to manage claim scripts; our service did that for them. We pre-funded pegs as far as we could so that users did not have to wait the 102 Bitcoin confirmations a peg-in normally requires before receiving their L-BTC. We ran the peg-out side automatically, from a funded wallet, so that customers were paid promptly rather than waiting for us to process each request by hand. Those choices served users for five years and across the large majority of Liquid's peg activity. They also removed the human checkpoints that would have held this order. That is the tension we had not resolved, and resolving it is now our priority.
How the attack unfolded
The dates below are a matter of public record on the Elements repository and on the Bitcoin and Liquid blockchains.
3 August 2026. A fix for the underlying Elements bug was written by its developers, so the vulnerability was known within the project from at least that date.
12 August 2026. A security build of the Elements software was shared privately with Liquid members. At the Federation's request we deployed it on 13 August 2026 and ran it in good faith as a security update. It is the software our node was running when the incident occurred, and it accepted the transaction that created the 4,000 L-BTC.
1 September 2026, 09:39 UTC. The fix was merged into the public Elements repository, under a title that described the vulnerability, while no software release yet contained it. From that point the flaw was visible to anyone reading the code.
1 to 5 September 2026. In the days after the fix became public, a small number of wallets made repeated small peg-ins through our service, sold the L-BTC on our market, and made small peg-outs back to Bitcoin. One of them had been funded in April 2025 through regulated exchanges and then left untouched for seventeen months before its first spend on 1 September. We note this activity because of its timing. We cannot prove on the blockchain that these wallets belong to the party that created the coins, and the practice money and the attack money were kept separate. We have passed the details to Blockstream.
5 September 2026, 20:55 UTC. The party made a small peg-in to SideSwap of 0.001 BTC, in Bitcoin transaction 29e12e0a1fcecd88045ed27641c2866fecb97a26b737bf1564d92a88f666a095. Those funds traced back, through a cross-chain bridge, to a withdrawal from the Tornado Cash mixing service on Ethereum. We paid out the corresponding L-BTC as normal at 21:33 UTC, in Liquid transaction 8281f427801d59f76a8d17fa3f3b724724b8f7daa7ee0bbf075bd968a2b03c14. That single 0.001 BTC peg-in was the only funding the wallet behind this attack ever received, from us or from anyone else.
5 September 2026, 21:42 UTC. The party split that L-BTC into twenty outputs, in Liquid transaction d9ba36f61ab8c3e352cc4b80f84d0989af649daf6779529ec79f5467ad360fa6. From 22:01 UTC it began cycling those outputs through a long series of near-identical transactions, each carrying a hidden (blinded) value on an unspendable output, then gathering them back together and splitting again. Seventy of these rehearsal transactions ran through the night, forty-eight before midnight and twenty-two more the next morning, the last of them at 13:52 UTC, one minute before the real one. Each tuned the exact shape of the transaction that would create coins from nothing.
These transactions were unusual on their face. A legitimate Liquid transaction hides its amounts but pays them to ordinary, spendable addresses. The attacker's instead placed a hidden amount on an OP_RETURN output, a type of output that is provably unspendable and is normally used only to record small pieces of data, never to hold value. Each rehearsal was the same shape, one input and three outputs and roughly 8.8 kilobytes in size, far larger than an ordinary payment because of the cryptographic range proofs it carried. The transaction that created the coins was about 13 kilobytes. It is this shape that let a hidden, impossible amount slip past the nodes that had been primed to skip the verification.
We can call these rehearsals with confidence. The seventy transactions that ran from 22:01 UTC all balanced correctly and created no coins, which is precisely why standard nodes, including our own, accept them. Only the single transaction that followed at 13:53 the next day failed to balance and minted value from nothing. The party was refining the construction until it worked, then used it once. We have since scanned every Liquid block from 1 September to the pause, on our own node up to the block before the mint and on the public record after it. This transaction shape appears exactly seventy-one times: the seventy rehearsals, then the mint. It appears nowhere else, from no other wallet, before or after, and every other transaction of a similar outward form in that period is ordinary peg-out traffic. The origin of the money points the same way: as above, the coins that seeded the whole exercise reached us through a cross-chain bridge from the Tornado Cash mixing service, whose purpose is to sever the link to the source of funds. This was a deliberate and prepared attack.
6 September 2026, 13:53 UTC (Liquid block 4,050,336). The party created approximately 4,000 L-BTC from nothing, in Liquid transaction f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f, the transaction the Federation's incident report describes. Standard Liquid nodes, including our own independent node, reject this transaction as unbalanced.
6 September 2026, 14:00 UTC. The party first tested the exit with a smaller order, a peg-out of 2.5 L-BTC (deposit c6ea588ac26f5838b6acbb2a444a33b325bbfeb39bf16dfe27b47215ffd72267), which our service paid out as 2.49749857 BTC about a minute later from its own inventory. The 2.5 L-BTC came from the same minted coins, not from a second event: it and the 4,000 that followed both descend from the single transaction above. The real order came four minutes after that.
6 September 2026, 14:05 UTC. The party sent 4,000 L-BTC to SideSwap's peg-out service (deposit 32892440646b3309a71ea5b0f6c87daebcb481f2d2f5434deaea515ef2933814). We burned it at 14:06 UTC with a valid authorisation (Liquid transaction ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2). An order of this size was larger than our own peg-out wallet could fund, and the payout failed twice for want of funds before the Federation's signers released 3,996.02 BTC at 14:28 UTC (Bitcoin transaction 8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140) and our service forwarded 3,995.99999857 BTC to the party's address in the same block (Bitcoin transaction 85d2ca15bea33a592e73ed40c6a5da887feecf1e77f58ec7f580e00841645043).
6 September 2026, around 20:25 UTC. Blockstream disabled the bridge nodes and paused the Liquid Network.
SideSwap charged its standard 0.1% peg-out fee on this order, approximately 4 BTC. We have returned it in full to the Liquid Federation, in Bitcoin transaction 0334e46381b57503da634ee09aaf966c07e81bf0aa821339e1eb0d26f26c8a1f. We took no benefit from this and want none.
What the record also shows
We take responsibility for our two failures above. For completeness, and because much has been said about SideSwap's role, the following are also true and on the record:
The Federation was aware that our peg-out authorisation key operated online. This has been visible in every SideSwap peg-out for years.
When the vulnerability was identified, we were not told its details, nor asked to change how we operated our peg-out key, nor asked to pause peg-outs. The security build we were asked to run did not prevent the attack.
The peg-out required the Federation's own signatures, eleven of fifteen. They were given to a single order of roughly 4,000 BTC, a very large share of all L-BTC in existence, without any check on its size or plausibility. The network-level controls that could have caught this sit with the Federation as much as with any member.
We do not set these out to shift blame. We set them out because a single member cannot be responsible for the integrity of the whole network, and the lessons here are shared ones.
What is not affected
SideSwap is a non custodial wallet. The L-BTC and other assets held in SideSwap wallets are controlled by their owners' own keys. They were not involved in this incident and have not been touched, and there is nothing users need to do with their existing wallets.
Instant swaps and SideSwap's other functions are paused only because the Liquid Network itself is paused and no Liquid transaction can currently confirm. They will resume when Liquid does.
On the recovery, and why we are speaking now
Efforts to recover the affected bitcoin are underway, led by others. We have deliberately stayed out of that process so as not to interfere with it, and we will not comment on its details. We have also held back from saying much publicly for the same reason. But our users and partners deserve to hear directly from us, and enough time has passed that staying silent would serve no one. That is why we are speaking now.
What happens next
Blockstream and the Liquid Federation are leading the network-level response, including the fix, the restart, and the status of L-BTC backing. The Federation has said it will carry out a full security review of the network and the peg process. We welcome that, and we will adopt the policy framework that comes out of it rather than making piecemeal changes on our own.
We are reviewing our own peg-out design in the same light, including how our authorisation key is held and what limits and checks sit in front of any payout. We will not resume peg-in or peg-out until we and the Federation are confident the process is safe, and we will say plainly what has changed before we do.
SideSwap itself will be available again as soon as the Liquid Network is back online. Our markets will run as normal and will help establish transparent, open market prices for L-BTC and for every other asset on Liquid. Peg-in and peg-out will remain offline until the Federation's new security architecture is in place.
We will address L-BTC backing and the reopening of our markets in a separate statement. We have no insight into the recovery under way, and we will not speculate on it here.
Our confidence in Liquid
We have full confidence in the Liquid Network and in the Federation, and we intend to help make both stronger. Since 2021 SideSwap has handled more than 111,000 peg-ins and 205,000 peg-outs for its customers. That is 95 percent of all peg-in transactions ever made on the Liquid Network, and the rebalancing of our own wallet accounts for 72 percent of all Federation peg-outs. We are as committed to Liquid's future today as we have ever been. We believe Liquid, and SideSwap, will come out of this stronger.
About SideSwap
SideSwap is a non custodial exchange and wallet built on the Liquid Network, focused on atomic swaps, self custody, and open blockchain based capital markets rooted in Bitcoin.
Inquiries:
[email protected]