A Program Derived Address (PDA) is a special type of account address on Solana that is deterministically derived from a set of seeds and a program's ID. Unlike regular Solana addresses, PDAs are guaranteed to not lie on the Ed25519 elliptic curve, which means no private key exists for them. This property allows programs to "sign" for these addresses during Cross-Program Invocations (CPIs) using invoke_signed.

How PDAs are derived

PDA derivation uses the Pubkey::find_program_address function, which takes an array of seed bytes and a program ID:

1let (pda, bump) = Pubkey::find_program_address(
2    &[b"user_profile", user_key.as_ref()],
3    &program_id,
4);

The function internally appends a "bump seed" (starting from 255 and decrementing) to the seeds until it finds a combination that produces an address off the Ed25519 curve. The first valid bump found is the canonical bump.

Security: bump seed canonicalization

The most critical PDA-related vulnerability is failing to enforce bump seed canonicalization. If a program accepts any valid bump (not just the canonical one), an attacker can derive multiple valid PDAs for the same seed combination, potentially creating duplicate accounts or bypassing access control checks.

The Anchor framework mitigates this by default through the seeds and bump constraints, which automatically verify the canonical bump during account validation.

Common PDA use cases

State accounts: PDAs store program state (e.g., user profiles, vault configurations) at deterministic addresses that can be computed by both on-chain programs and off-chain clients.

Authority accounts: PDAs act as signing authorities for token accounts, allowing programs to transfer tokens without human intervention.

Mapping patterns: Seeds act as keys in a key-value mapping. For example, [b"order", user.key(), order_id] creates a unique PDA for each user's order.

Audit considerations

When auditing Solana programs, security researchers should verify:

• The canonical bump is stored and validated on subsequent accesses
• Seed combinations produce unique addresses (no seed collisions between different account types)
• PDA ownership is validated before trusting deserialized data
• Programs using create_program_address instead of find_program_address properly validate the bump

PDAs are the backbone of Solana's account architecture, replacing the role that mapping storage plays in Solidity contracts on the EVM.