Message feed: liquid group chat. Evidence: liquid-2026-incident-forensics.
On 6 September 2026, in under an hour, about 4,000 BTC leave the Bitcoin wallet that backs L-BTC on Liquid (~$320M at the time). This is not a Discord rumor: first an inflation of unbacked L-BTC on the sidechain, then a peg-out that turns those tokens into real bitcoins. Soon after, an address publishes in an OP_RETURN: We are whitehats. Contact us on chain. Blockstream and Liquid call them purported white-hat hackers: self-claimed, not a proven label.
What follows is a public negotiation on Bitcoin. Dust of 1,000 sats to flag a message, PGP or Electrum encryption when the content is sensitive, a return of 3,400 BTC (~85%), a :(, then plaintext and an ultimatum over the remaining ~15%. On 9 September, Elements v23.3.4 ships (range-proof cache). On the 10th, a controlled ops restart begins. In parallel: can an Elements node wrongly reuse the result of a crypto check already done, and accept a transaction it would have rejected cold?
Here is that thread, without the thriller. To read the useful OP_RETURNs without the spam, there is a third-party UI, liquid group chat. It is not an official chat room. It is a reader that ignores memecoin ads and money asks glued onto the now-famous address, and keeps only what is authenticated: a spend from the purported whitehat’s bitcoins, or a valid PGP signature against the Blockstream key.
What are we talking about? Liquid, Elements, Blockstream
Three names. Not interchangeable.
Liquid (Liquid Network) is a Bitcoin sidechain: a separate chain, linked to Bitcoin by a two-way peg. You send BTC in to get L-BTC (in principle 1:1, backed by BTC locked on Bitcoin). You can also issue other assets (stablecoins, etc.). Blocks are fast (on the order of a minute). Many amounts and assets can be confidential. Liquid is not mined like Bitcoin: a consortium of firms (exchanges, infrastructure…), the Liquid Federation, runs functionaries that co-sign blocks and manage the peg.
Elements is the open-source software (Bitcoin Core fork / extension) Liquid is built on. It is the node code (elementsd), with confidential transactions, native assets, federated peg, block signing, and so on. When people say Elements v23.3.4, they mean a version of that software, not another blockchain.
Blockstream is the company that develops and ships much of the stack (Elements, tools, etc.) and that, in this incident, publishes updates and signs some on-chain messages with its security@ PGP key. Blockstream is not the whole Liquid Federation by itself. On Liquid, it mostly shows up as the tech vendor and the public voice during the crisis.
In one line: Liquid = the live network. Elements = the node code. Blockstream = the vendor / actor that communicates and patches here.
Why on-chain, and not a plain email?
An email or support ticket would leave metadata (servers, timestamps, sometimes an identity). Speaking on-chain, signing only with control of the coins, lets the purported whitehat negotiate without gluing a web handle, a mailbox, or a Telegram account to that address. The message is public, but the channel stays the UTXOs. It is paradoxical: everyone can read the thread, and yet it is often more comfortable, for operational anonymity, than opening a traceable inbox. Blockstream authenticates some of its replies with its published PGP key, including when the bitcoins leave change addresses different from the first contact address.
How ~4,000 BTC left (with no announced key theft)
The point many analyses stress, and that belongs before the message soap opera: Liquid and SideSwap stated that SideSwap’s PAK and, more broadly, that the peg keys were not compromised. That is not an on-chain negative proof. It is their official story, consistent with a validation bug rather than a key theft. The observed / reconstructed path looks like this.
1. Priming on Liquid. Before the big hit, Liquid “setup” transactions appear (notably 71c9… and 2711… in block 4050335). They are cryptographic candidates: their outputs can produce the same post-fix cache key as an attack output (alias). Their plausible role: present valid range proofs to write a cache entry. Important limit (CertiK, and our missions): connecting block 4050335 consumes the cache entry. The effective primer that would have reloaded the cache just before f24a (mempool / live tx, after 4050335) is not publicly identified.
2. Inflation / mint. Around 13:53 UTC on 6 September (Liquid block 4050336, tx f24a…), a transaction creates on the order of ~4,000 unbacked L-BTC: L-BTC the network accepts, while no extra BTC was deposited on Bitcoin to back them (normal peg-in: lock BTC on Bitcoin, receive L-BTC). In the lab, on the cache mechanism: with no entry already present, secp256k1_rangeproof_verify fails on the alias proof. If priming already recorded the same key, CachingRangeProofChecker can return valid from the cache, without calling the full rangeproof check again. The on-chain construction matches this alias family. Which binary ran on each node on the day, and which live primer was used, remains undemonstrated here.
3. Peg-out via SideSwap. According to SideSwap and public analyses (CertiK, Chainalysis, TRM…), these L-BTC go through SideSwap, a Liquid Federation member that runs an L-BTC → BTC exit service. Around 14:05 UTC, a client request was reportedly handled there: burn of the L-BTC under a valid authorization, with its PAK (Peg-out Authorization Key). SideSwap and Liquid said that PAK was not compromised. The alleged bug is in Elements (proof validation), not in custody of a stolen private key.
4. BTC payout. The functionaries (the federation members’ machines that co-sign) approve the peg-out as usual, via a threshold multi-signature. Around 14:28 UTC, about 3,996 BTC leave the Bitcoin peg wallet (bc1qdlld6…). They first pass through an intermediate address (bc1qgslsy…, often called a hop: a step between the peg and the final destination), then reach bc1ql4mfu…. In about half an hour: mint → BTC. The press often cites that a move of that size was on the order of ~95% of the BTC then held to back L-BTC.
In other words: if the SideSwap account holds, the peg-out service correctly processed a request for L-BTC that consensus had wrongly accepted. The peg-out signatures were authentic. The Bitcoin reserve behind L-BTC no longer matched.
The money is out, the messages begin
Address bc1ql4mfu… then carries the whole story on the purported whitehat side.
To publish text on-chain, you need a Bitcoin transaction with an OP_RETURN output (the text) and, here, often 1,000 sats to the other party to get attention. Those txs are signed with the purported whitehat’s UTXO keys: miner fees, optional change, nothing magical. First public message: we are whitehats. contact us on chain.
That evening (public announcement around 22:25), Liquid / Blockstream confirm the incident on X. ~4,000 BTC (~$320M). Purported white-hat hackers. On-chain contact with a signed message underway. SideSwap PAK not compromised. Exchanges warned to freeze L-BTC deposits / withdrawals. Other Liquid assets (USDT, DePix, RWA, etc.) presented as untouched. Bridge nodes cut: no new txs submitted, sidechain paused. Mempool link to the Bitcoin peg wallet (bc1qdlld6…).
Blockstream also replies on-chain (bc1qn8mgs…, then other UTXOs). First visible reflex: Please contact security@blockstream.com. Then encrypted OP_RETURNs (BIE1 to the key behind bc1ql4mfu…, or PGP to Blockstream). On the tracking UI: you see that an encrypted message exists, and maybe a valid PGP signature. Without the private key, the content stays unreadable.
The purported whitehat does not send the bitcoins back at once. Condition: fix the bug first (« chain under risk at latest commit »), patch all nodes, then most of the amount will be returned, details encrypted. Blockstream signs « Yes, thank you. », then several times: bridge nodes patched, safe to return. Fresh address confirmation. On 7 September around 16:09 UTC, 3,400 BTC return to the peg. About 598.5 BTC stay with the purported whitehat (~15%, ~$47M at valuations then cited). No OP_RETURN in that transfer.
After the 3,400 BTC transfer
Encrypted OP_RETURNs resume. Blockstream even posts a BIE1 / Electrum howto next to a ciphertext. The purported whitehat sends PGP back to security@. Around 21:00: :(.
On 8 September, Blockstream keeps going in BIE1 (often PGP-signed). Around 14:25 UTC, the purported whitehat announces: All messages will be in plaintext. Meaning: later messages will be cleartext, no more PGP / BIE1. Older encrypted messages still do not open.
The next day, a long OP_RETURN anyone can read accuses Blockstream of under-investing in security, demands a 10% bug bounty « with your own money », threatens a 15% loss for L-BTC holders if refused, and announces a later release of a key to decrypt the old OP_RETURNs. On-chain quote, not a budget audit. Asymmetry: the purported whitehat writes in clear. Blockstream still often replies in clearsigned BIE1.
The tracking UI updates with new authenticated OP_RETURNs. This article remains a snapshot at a given date.
Meanwhile, on the Liquid network
From the evening of 6 September: incident acknowledged, PAK presented as uncompromised, L-BTC frozen at exchanges, bridges cut, sidechain paused.
9 September (13:30 UTC): emergency release Elements v23.3.4. Functionaries updated at once. All node operators invited to follow. The text says this version addresses the proof-verification cache vulnerability (range-proof cache keys). Internal / external reviews (Bitcoin Red Team, Alpen Labs, etc.).
Recovery plan (still revisable):
- resume block production while the peg stays suspended
- replay transactions verified as valid
- reopen the peg once state is restored, including a funds return
The first two steps are tested in parallel. Neither moves forward until it is judged safe.
10 September (10:00 UTC): next phase. Blocks without transactions, while things stabilize. Functionaries / bridge up to date per their statement. Peg (including PAK peg-outs) still suspended, BTC / L-BTC reserve restoration underway. Warning about scams / fake update sites.
Two clocks: bring Liquid back up. Negotiate on Bitcoin over the BTC still with the purported whitehat. One does not erase the other.
And the bug, in all this?
On Liquid, confidential outputs come with range proofs (secp256k1-zkp): the proof binds a value Pedersen commitment to an asset generator, and optionally to extra data (scriptPubKey as extra_commit). Checking that is expensive. Elements memorizes some successes in a process cache (CachingRangeProofChecker / ComputeEntryRangeProof).
Two distinct problems around the cache key
It is important to distinguish two conceptually different problems.
The context-binding flaw (pre-hardening) concerned isolation of the validation context. Before the hardening, the range-proof cache key did not bind the proof tightly enough to the full output context. Schematically, it could be represented as:
proof + value commitment
The asset and the scriptPubKey were therefore not sufficiently taken into account in the identity of the cache entry. A valid verification could thus be memorized and then reused in a different context.
The distinct problem concerns the fix’s new key construction. That fix seeks precisely to bind the key to the context by adding, among other things, the asset and the scriptPubKey. But if those fields are simply concatenated without an encoding that delimits their length or makes their representation unambiguous, the resulting byte sequence can itself be ambiguous: different fields can be split in several ways while still producing the same concatenation.
This is therefore not a cryptographic SHA-256 collision. The problem sits upstream, in the serialized construction of the data that is then hashed: it is a representation ambiguity that enables cache-key aliasing.
That distinction matters: the first problem is insufficient binding between the proof and its context; the second is a key construction meant to strengthen that binding, whose concatenation can still remain ambiguous.
In lab: the primer has a proof secp256k1_rangeproof_verify accepts. The alias fails if the cache is empty. If the primer already wrote the entry, the checker can accept the alias without redoing the crypto. This is not “two different preimages, same SHA-256”. It is the same preimage, badly split. Locus: CheckTxInputs → VerifyAmounts → CRangeCheck.
Disclosure point (hypothesis, not fact). Useful public timeline: AuthorDate of the fix around August 2026, commit / PR (c26d719, #1592) visible around 1 September, while no tagged release containing the fix was yet in prod (e.g. 23.3.3 still pre-fix). A relevant master-side merge lands after the attack on the 6th (~17:21 UTC, after the 13:53 mint). Several articles infer an attacker could have read a public diff before deployment. We do not prove that here. What we mainly note is the gap between visible code / deployed release, a classic coordinated-disclosure topic.
Epistemic limit: mechanism confirmed in the laboratory. The on-chain construction is consistent, per several public analyses (including CertiK), with the four-field undelimited key construction, rather than the older two-field key. Laboratory reproductions go further and demonstrate that this four-field construction can produce the required cache-key aliasing byte-for-byte. This confirms the exploit mechanism under controlled conditions, but does not establish which exact binary, runtime state, cache contents, or live primer was present on each functionary during the historical incident, nor does it prove that the reproduced primer was the one used on 6 September.
Detail, fixtures, ConnectBlock limits: repo, especially final/28_red_team_review.md and later missions.
What I tried to document
The liquid-2026-incident-forensics repo is not an OP_RETURN diary. It is a reproduction-and-limits pack: cache-key aliasing, path through Elements, what is still blocked (e.g. hot/cold experiment on a real post-fix elementsd). Filtered BTC chronology and images as snapshots, not as a replacement for the tracking UI.
In short: group-chat for the filtered public thread. Repo for the mechanism and the proof level.
What we still do not know
The content of the messages published via OP_RETURN that remain encrypted (PGP or BIE1). Exact runtime of each node on the day. Live primer after 4050335. Fate of the ~598 BTC still with the purported whitehat. Whether the announced key to decrypt old messages is published. The 9-10 September updates describe v23.3.4 and a staged recovery, with the peg still closed. They do not close the on-chain negotiation. Until it is on-chain or from a verifiable source, better not invent the ending.
Useful sources: liquid group chat, forensics repo, chronology image final/data/btc_3400_opreturn/chronology.jpg (EN: chronology_en.jpg if present), blockstream.com/pgp.txt, Liquid / Blockstream announcements of 6, 9, and 10 September 2026. Converging public analyses on the mint → SideSwap → BTC path and on cache-key encoding: among others CertiK, Chainalysis, TRM Labs, Decrypt.
Mechanism confirmed in lab. Historical incident causality remains unproven.