Skip to main content
Program Derived Addresses (PDAs) are deterministic addresses derived from a program ID and a set of seeds. PDAs enable programs to sign for accounts without requiring a private key.

What are PDAs?

PDAs are addresses that:
  1. Are derived deterministically from seeds and a program ID
  2. Do not have a corresponding private key
  3. Can only be signed by the program that derived them
  4. Are guaranteed to not lie on the ed25519 curve

Finding PDAs

To find a PDA, use Pubkey::find_program_address:
The bump is a value (0-255) that ensures the address doesn’t lie on the curve.

Using PDAs in Anchor

Anchor simplifies PDA usage with the seeds and bump constraints:

Initializing PDAs

Anchor automatically:
  • Derives the PDA address
  • Finds the bump seed
  • Validates the derived address matches the provided account

Accessing PDAs

For existing PDAs, Anchor validates the address without the init constraint.

Storing the bump

Store the bump seed in your account to avoid recalculating it:
Then use it in future instructions:

Signing with PDAs

Programs can sign CPIs using PDA seeds:

PDA use cases

1. Deterministic account addresses

Create predictable addresses for user-specific accounts:

2. Program authority

Use PDAs as authorities for tokens or other accounts:

3. Account relationships

Enforce relationships between accounts:

Multiple seeds

You can use multiple seeds for more specific PDAs:

Complete example

Best practices

Store the bump seed in your account to avoid recalculating it on every instruction.
Be careful with seed choice - anyone can derive the same PDA with the same seeds, so ensure seeds uniquely identify the resource.
PDAs cannot sign transactions - they can only sign CPIs within a program.

Next steps

Cross-program invocations

Learn how to use PDAs with CPIs

SPL integrations

Use PDAs with token accounts