Program Derived Address (PDA)

Overview

A Program Derived Address, or PDA, is generated from a Solana program ID, application-defined seeds, and a bump value so the result lies off the Ed25519 curve. No private key can sign for it.

The owning program can authorize actions for the PDA during cross-program invocation by supplying the same seeds and bump. PDAs therefore provide predictable addresses for program-controlled accounts, authorities, escrow state, and user-specific records. Developers must define seeds unambiguously, enforce expected account ownership, and validate all supplied accounts inside the program. Seed collisions at the application level or weak authorization logic can cause security failures even though derivation is cryptographically sound. A PDA is not automatically an initialized account; creation, funding, ownership, and data layout remain separate steps.

Program Derived Address (PDA) must be interpreted with its network, address or account type, encoding rules, and any required routing fields. A string that passes a format check can still belong to the wrong chain, unsupported asset, contract type, or destination that requires a memo or tag. Authorization depends on keys, scripts, contracts, or protocol rules, while custodial systems may expose an identifier without giving the user direct control of the underlying account. Program Derived Address (PDA) is an identifier or spendable object, not proof of legal ownership and not a secret credential. Systems storing Program Derived Address (PDA) should preserve the exact value together with chain identifiers and type metadata. Normalization, case conversion, truncation, and alias resolution need protocol-aware rules, because a visually similar value can represent a different destination or fail checksum validation.