Why
The correction is the point. I first read this as an access-control gap — a check that should have refused a withdrawal and didn't. That was wrong, and the way it was wrong is the lesson. Authorization worked. The peg-out logic asked the right question — 'is this a valid LBTC?' — and got a truthful 'yes.' The problem was upstream: an issuance bug in the Elements software minted LBTC that should never have existed, and every downstream check faithfully honored it, because by the rules those checks enforce it was real.
So the failure axis is not 'who was allowed to do what.' It is 'was the thing being counted minted under the invariant.' Those are different questions, usually answered by different code, and a system can pass the first perfectly while the second is already broken. A peg is exactly where this hurts most: the whole product is a promise that on-chain supply equals off-chain reserve, and a mint bug breaks that equality silently — the tokens look valid because they are valid; they are just not backed.
This reframes what an authority audit can and cannot catch. The authority matrix — who may mint, pause, upgrade — is necessary but not sufficient: it proves the right actors hold the right permissions, not that the code those actors run preserves the supply invariant. A correct permission executing buggy issuance produces valid-looking, unbacked units, and no access-control review flags it, because no access control was violated.
How it works
Two questions, two different pieces of code
| Question | Who answers it | Liquid's outcome |
|---|---|---|
| Authorization — is this actor allowed to peg out? | the peg-out gate | worked correctly |
| Supply integrity — was this LBTC minted 1:1 under the peg invariant? | the Elements issuance path | broken — produced invalid units that looked valid |
The drain rode entirely on the second row. The peg-out was never tricked; it was handed technically-valid tokens and did its job.
Why 'valid token' is a weaker claim than it sounds
Liquid is a federated Bitcoin sidechain: LBTC is meant to be 1:1 with BTC held by the federation — minted on peg-in, burned on peg-out. 'A valid LBTC' means it satisfies the chain's rules. 'A correctly-issued LBTC' means it was minted against a real peg-in. An issuance bug lets those two diverge: units that pass every validity check but were never backed. Downstream nothing tells them apart, so the peg-out honors them like any other.
The negotiation was the unusual part
Instead of vanishing, the attacker negotiated on-chain — an OP_RETURN plus a PGP-signed message with a condition: fix the bug first and patch every node. Blockstream replied, also PGP-signed — bridge nodes patched, safe to return — and the attacker signaled they would return most of the funds. As of this writing the return is not complete. The shape is worth noting: the chain's own data field carried the diplomacy, and PGP signatures stood in for identity because on a bridge there is no other trusted channel between the two sides.
The negotiation points at a second, bigger problem — proving who sent a message
The on-chain diplomacy is a crypto story, but its implication is general: how do you prove a message really came from a given organization? The OP_RETURN carried the words; the PGP signatures carried the identity, because on a bridge there is no other trusted channel. This catalogue's 2026-08-01 note on a hijacked executive account used to promote an RWA token was the same axis seen from the attacker's side — here it returns as the defender's need. The observation recorded then is confirmed in practice now: there is real demand for verified-identity official-announcement channels — signed notices, on-chain attestations — and as AI-generated content grows, that demand grows with it. A PGP-signed OP_RETURN is a crude version of exactly that channel.
Where this lands in Jayverse
- The token bridge (jayverse-token-bridge) is a 1:1 lock/mint vault — its entire safety claim is the supply invariant this incident broke. An invariant test ('minted on dest == locked on source, always') is the direct defense, and it belongs with the mint path, not the withdraw gate.
- The Authority Auditor (#8) proves permissions, not issuance correctness — a concrete case of why the authority matrix is necessary but not sufficient, and it should say so.
- Security-hole research (#10 Dark Horse) — reproduce this class on a local fork: a mint bug that yields valid-but-unbacked units and a redeem path that honors them. The invariant that catches it is conservation, not access control.
The one-line takeaway
Checking the actor is not the same as checking the object. When the object was minted wrong, a correct check faithfully approves a poisoned unit — the gate was fine; the count was contaminated.
Review clarification
From incident to invariant, made operational
The section above is the failure (supply integrity, not authorization). This is the defense as a running layer — because 'add an invariant test' is easy to say and easy to build wrong.
A good invariant has three properties, and the third is the one people skip. It must be (1) independently computable — derivable without trusting the system's own bookkeeping, or it just re-reads the same lie the peg-out believed; (2) violation-is-meaningless — if reserves = issuance is false, every downstream number is void, so there is no 'degraded mode' to keep limping in; and (3) wired to an automatic halt — an alert is a request for a human to notice, and the whole failure mode is that the human did not. Reserves = issuance had (1) and (2) for free and was checked by nothing — (3) missing.
Put the checker where the thing it watches cannot reach it. If the invariant monitor shares infrastructure and trust boundary with the mint/settle path, the compromise that breaks one breaks both — the watcher dies with the watched. Tune it to a narrow halt scope, not a loose threshold: a monitor that fires often gets muted, and a muted monitor is worse than none because it was believed.
Simulate before, check after — one discipline. The invariant asks did the equation just break; pre-execution simulation asks would this transaction break it, replaying the tx against current state and reading the state diff before signing. Tooling like Tenderly (or a Foundry fork in CI) makes that a check on the mint transaction itself — a single alert on 'total issuance changed unexpectedly' is the shape that catches this before the peg-out ever sees the token.
The scoping exercise for our own systems
List every equation that must always hold, is computable independently, and name its automatic stop:
| Invariant (must always hold) | Independently computable from | Halts on violation |
|---|---|---|
| minted on dest = locked on source | source vault + dest supply | new mints / withdrawals |
| settlement sum = per-market sum | market ledgers, summed | settlement writes |
| escrow balance >= open claims | escrow account + claim registry | new claims |
Cross-refs: foundry-invariant-reachability (the same idea at test time — an invariant test only catches what its actions reach), simulate-before-sign (the pre-execution half), who-holds-the-mint (the mint is exactly the privileged write an invariant should bound), receipt-is-not-settlement (a success flag is not proof the state is sound).