Program Derived Address

Solana addresses normally come from ed25519 keypairs. PDAs are deliberately off the curve. The derivation function takes a list of seed byte arrays and a program ID, hashes them, and bumps the result with a small integer until the output is off curve. Both the address and the bump are returned. The program later reuses the same seeds and bump to "sign" for the PDA via invoke_signed.

PDAs are how Solana programs store anything. A Whirlpool account is a PDA derived from the WhirlpoolsConfig, the two mints, and the tick spacing. A Pump.fun bonding curve is a PDA derived from the token mint. An associated token account is a PDA derived from the wallet, the mint, and the SPL Token program ID. Once you start looking, almost every account in a transaction is a PDA.

The two most common derivation helpers are findProgramAddressSync on the client and Pubkey::find_program_address on chain. Both return the address and the canonical bump. Storing the bump in the account state and reusing it on subsequent calls is faster than re-deriving every time.

One opinion: a lot of "this transaction failed mysteriously" bugs trace back to mismatched PDA seeds between the client and the on-chain derivation. Print both addresses on failure and compare; you will fix the bug in five minutes instead of fifty.

Every Solana program uses PDAs. Examples in production: the associated-token-account program ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL derives ATAs as PDAs; Anchor programs declare PDA seeds in the #[derive(Accounts)] macro; the System Program creates PDAs via create_account_with_seed.

Decoding any account on our Enhanced Streams starts with knowing the PDA seeds. Our pipeline carries the owning program ID and the account discriminator on every event so you can re-derive PDAs downstream without reading the IDL. Need raw access? Pull from our gRPC nodes and derive PDAs in your own client.