A sidechain peg is a custody arrangement wearing a protocol’s clothes. You send bitcoin to an address controlled by a group; the group’s ledger credits you with a token — L-BTC on Liquid, RBTC on Rootstock, and so on — that is supposed to be worth exactly one bitcoin because exactly one bitcoin sits behind it; and when you want out, you burn the token and the group sends the bitcoin back. Every word in that sentence is a place something can go wrong, and on Sunday 6 September one of them did: the Liquid Network, the sidechain Blockstream built and a federation of exchanges and custodians operates, paid out 3,996 BTC — about 95% of what it held — against 4,000 L-BTC that, in the words of the swap service whose key authorised the withdrawal, “was created through a bug in the Elements software.” Today’s news piece has the hour-by-hour account. This guide, the forty-fourth in the Reading Room, is about how to read such an incident: what to ask, where the answers are, and which of them you can check yourself in five minutes with a block explorer. It is the third security guide in the room, after #28, the Coldcard migration decision tree, and #43 on hardware-wallet breach notices, and it belongs with our earlier, unnumbered cross-chain bridge security guide: a federated peg is more than a bridge and less than a hardware wallet, and its failure modes are its own.

Question 1: Who holds the coins, and under what rule can they move?

Start with the custody model, because it determines everything else. Liquid’s bitcoin is held in a multisignature wallet whose keys sit in hardware security modules run by the federation’s members — “functionaries” in Blockstream’s vocabulary — and a peg-out is paid when a threshold of them sign. That is not a smart contract and it is not a single company’s hot wallet; it is a committee with hardware, and it has two properties you should hold in mind at once. It cannot be drained by one compromised member, which is its strength. And it will pay any withdrawal that the sidechain’s own ledger says is valid, which is its weakness: the signers are executing the sidechain’s rules, not auditing them. When you read an incident notice, look for the sentence that tells you whether the signers did something wrong or did exactly what they were built to do. Liquid’s statement, as The Block reported it, says the peg-out authorisation key was “not compromised, nor had any others.” SideSwap’s says the L-BTC “was burned on Liquid with a valid peg-out authorisation.” Samson Mow’s says the problem “is not related to PAKs or HSMs.” Three parties, same answer: the custodians did their job. Score for Liquid: the custody model held. That is worth saying clearly because it is the opposite of what the headline “$320 million hack” implies.

Question 2: How is a withdrawal authorised, and who can authorise one?

Liquid does not let anyone burn L-BTC and receive bitcoin at any address; a peg-out must be signed with a peg-out authorisation key, a PAK, and PAKs are issued to a whitelist of exchanges and services. This exists to keep the federation from paying out to arbitrary, unknown addresses, and in practice it means most users peg out through a service — SideSwap is one — that holds a PAK and whose PAK pays to the user’s chosen Bitcoin address. Read the notice for what the PAK layer did and did not do. In this case it did exactly what it is designed to do: SideSwap received 4,000 L-BTC at 14:05 UTC, treated it “like any other order,” and the federation paid 3,996 BTC at 14:28 to the address the customer gave. The PAK gate is a gate on where money can go, not on whether the money is real. The 4 BTC difference between 4,000 and 3,996 is on SideSwap’s side of the ledger — the peg-out transaction itself paid a miner fee of 143 satoshis — which tells you that the whole withdrawal ran through the ordinary retail path, at ordinary retail cost, in twenty-three minutes. Score: the authorisation layer worked as specified; the specification does not cover counterfeit inputs. When you read future notices for other sidechains, the equivalent question is: what stands between a token and the reserves, and does that thing check anything about the token beyond its being on the ledger?

Question 3: Was the failure in custody or in consensus?

This is the question that separates incidents that look alike. A custody failure — a stolen key, a phished signer, a malicious insider — moves coins that were legitimately backed to someone who should not have them, and the ledger is otherwise honest. A consensus failure creates tokens the ledger should never have credited, and every honest holder is diluted the moment the counterfeit is redeemed. The Liquid incident is the second kind. Elements, the codebase Liquid runs on, credited someone with 4,000 L-BTC that no bitcoin had been deposited against; the sidechain’s own rules said those tokens existed; the federation, following those rules, honoured them. Nobody’s coins were stolen from an address. Everybody’s L-BTC became worth about five cents, because the reserve that backs all of it left. The word to look for in the notice is the one that names the layer: Liquid’s statement did not name the bug, SideSwap’s put it in “the Elements software,” and Mow’s working theory put it in Confidential Transactions, the feature that hides amounts on Liquid and therefore — this is the point — makes it harder for observers to notice that the total supply of L-BTC has quietly risen by 4,000. Hidden amounts are a privacy feature and an audit cost, and a peg that uses them is asking you to trust the software’s arithmetic rather than to check it. Score: the notice identified the layer only indirectly, through a third party, and has not yet published a reconciliation of L-BTC in circulation against bitcoin held. That reconciliation is the single most important document in a consensus incident and its absence is the thing to keep asking about.

Question 4: What does “paused” protect, and what does it leave exposed?

“Effectively, the Liquid sidechain is paused until this issue is resolved,” Liquid said, and the specifics were that bridge nodes were disabled so that no new transactions could be submitted, and exchanges were asked to halt L-BTC deposits and withdrawals. Read a pause as a freeze on the ledger, not as a recovery of the money. It does three things. It stops the bug being used again while it is unpatched, which matters more than it sounds: the whitehats’ own message on Monday warned that “the chain is under risk at latest commit right now.” It stops a run, because with roughly 200 BTC left behind roughly 4,200 L-BTC, any peg-out queue would be first-come-first-served on a five-percent reserve. And it stops honest users trading L-BTC at whatever discount the market would set for a token that may or may not be made whole. What it does not do is touch the 3,998 BTC on the Bitcoin blockchain, which no federation vote can move, and it does not protect the other things on the sidechain from being stuck: Liquid said USDT, DePix and tokenised assets were unaffected in the sense that their backing is separate, but a wallet that cannot submit transactions cannot move them either, and JAN3’s Aqua wallet said as much. If you hold L-BTC, the practical reading is: your token is a claim on a federation that is currently owed most of its reserve by a third party; you cannot exercise the claim; and the claim’s value depends on Question 6. If you hold USDT on Liquid, your backing is intact and your ability to move it is not. Score: the pause was fast — Liquid’s statement, which Bitcoin.com times at 4:25 pm EDT (20:25 UTC), came under two hours after the whitehats’ 18:30 message — and correctly scoped; the notice could have said more plainly that L-BTC is not currently fully backed.

Question 5: What does an on-chain message prove, and how do you check one?

Since Sunday evening the parties have been talking in OP_RETURN outputs — small text fields in Bitcoin transactions — and the weekend’s commentary quoted those messages freely without asking the only question that matters about a message: who sent it? A Bitcoin transaction proves that whoever controlled the inputs authorised the outputs, and nothing else. So a message is attributable to the party with the coins if, and only if, its inputs came from the address holding the coins. Applying that rule to the record the desk pulled at 06:13 UTC on Monday: “we are whitehats. contact us on chain” (18:30 Sunday), “sending most back to bc1qdlld6…, is that ok” (02:20 Monday) and “Please fix the bug first…” (03:30 Monday) were all spent from bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte, the address that received the 3,996 BTC. They are the whitehats’ words. “Please contact us on Signal @m671aw.70” (20:38 Sunday) was not; it came from an unrelated address that paid a few hundred satoshis to write into the conversation, as did some twenty advertisers, one lawyer and a memecoin. It may be the whitehats using a second wallet; nothing on the chain says so, and a reader should treat it the way Ledger’s Charles Guillemet did not quite — as unattributed. On the other side, Blockstream’s messages from bc1qn8mg… carry PGP signatures that name security@blockstream.com and a fingerprint, and the company’s public key is published at blockstream.com/pgp.txt. Verifying one takes four commands: fetch the key, import it, save the signed text exactly as it appears in the transaction, and run gpg --verify. The desk did that for both signed messages; both are good, made at 01:14:19 and 03:16:04 UTC by the key whose user ID is “Blockstream Security Reporting.” That is the standard: a message is verified when the chain ties it to the coins or a signature ties it to a published key, and reported otherwise.

Question 6: What would the return look like, and what would “most” cost?

The whitehats have said they will send “most” back, after “every node is patched,” to an address they named. Read each of those three clauses as a term. “Most” is not all: whitehat conventions in this industry often include a bounty of ten percent, sometimes negotiated down, and 10% of 3,996 BTC is about $32 million at Sunday’s close; whether that is what “most” means is not in the public text, and Blockstream’s signed reply — “Yes, thank you.” — does not say either. “After every node is patched” puts the clock in the whitehats’ hands and makes the return conditional on a software release and its deployment across a federation of independent companies, which is a matter of days at best. And the named address, bc1qdlld6…suhwxxr, is a witness-script-hash address holding 197.47 BTC over 568 transactions at our pull, which is consistent with a federation wallet and is not confirmed as one by anything Blockstream has published; the whitehats tagged it with 1,000 satoshis in their very first message, before Blockstream had said a word, which suggests they knew where the money came from. The return, when it happens, will be a transaction from bc1ql4m… to that address or another Blockstream names, visible to anyone, and the size of the gap between 3,996 and what arrives is the bounty. Score: the terms are public and specific enough to grade, which is more than most incidents offer; what is missing is a Blockstream statement of what it has agreed.

What this incident is not

It is not a Bitcoin failure. The base layer processed a valid peg-out, then six messages between the parties, at 1 sat/vB, and did what it is supposed to do, which is nothing in particular. It is not a hardware-wallet failure of the kind the Coldcard guide or the Trezor guide addresses; no user did anything, and no user could have prevented it. And it is not the same as the Kelp DAO bridge exploit of earlier this year, where the failure was in a message-passing contract between two chains; here there is no contract, only a federation and a rulebook, and the rulebook was wrong. What it is, is a clear argument for the position the self-custody guide has always taken: a token that says “bitcoin” on another ledger is a liability of whoever runs that ledger, and the only bitcoin that cannot be counterfeited is the kind whose supply everyone can count.

The marker

As standing practice we mark one falsifiable claim on the subject of this guide. V1: by 23:59 UTC on Wednesday 30 September 2026, Liquid’s bridge nodes have been re-enabled and at least one peg-out has been paid by the federation on the Bitcoin blockchain, as evidenced by a dated Liquid or Blockstream announcement that the network has resumed and by a federation-signed transaction after that date. The reasoning for: the whitehats have committed in writing to a return after a patch, Blockstream has acknowledged the terms with a verified signature, the fix is to software the company controls, and every day paused costs the federation’s members and Tether’s Liquid users. The reasoning against: a restart before the coins are back would reopen a five-percent reserve, so V1 in practice requires T1 first; a consensus bug in Confidential Transactions is not a one-line patch; and the federation’s members must each deploy it. The companion marker T1, in today’s news piece, asks whether at least 3,500 BTC has been returned by 14 September. The Reading Room’s hub indexes all forty-four guides.

Disclaimer: This article is for informational purposes only and does not constitute investment advice. Cryptocurrencies are volatile and you can lose money. Nothing here is a recommendation to buy or sell any security, digital asset or exchange-traded fund, including MSTR, PURR or HYPE. Do your own research and consult a licensed financial advisor before making investment decisions.