Solana PDAs: deterministic addresses and program authority

Find application state without storing another keypair

A program often needs a predictable address for a user's settings, an order or a vault authority. A PDA lets a client and program derive that address from agreed inputs instead of looking up an independently generated keypair.

Choose a teaching notes program. Its design uses the seed bytes for the label user-note and Alice's public-key bytes under that program's ID. The client can derive the expected note address whenever it needs to read Alice's state.

The address belongs to the derivation, not to the English label's meaning. A different program ID or different seed bytes produces a different derivation. Specify encoding and order as part of the application interface.

Do not put secrets in seeds. Clients often need to reproduce them, and the resulting relationship can be public. A PDA is an addressing and authority mechanism, not encryption.

Seeds and a bump select an off-curve address

The derivation uses seed bytes and the program ID, then checks that the result is off the Ed25519 curve. A bump supplies an extra byte used to find a valid off-curve result.

The canonical bump comes from the standard search order. Use the supported SDK derivation function and validate the expected seeds and bump onchain. Accepting arbitrary accounts because they look plausible weakens the intended relationship.

Seed boundaries and encoding need care. Concatenated byte content can be ambiguous if an application treats variable-length pieces as self-describing when they are not. Use a defined schema, bounded fields or appropriate domain-separated encoding.

Deriving the same address repeatedly costs no network transaction on the client. It is a deterministic computation. That does not tell you whether an account currently exists there.

Derivation and account creation are separate steps

A fresh derivation can point to an address with no account. Creating state there requires an instruction path which allocates space, supplies required lamports, assigns the appropriate program owner and initializes valid data.

In the notes example, initialization must validate the intended user and derive the expected note address. The program can use the runtime's PDA signer mechanism when invoking account-creation operations.

The payer funding that creation is another role. Alice might pay, or an application might sponsor account setup. Paying for space does not automatically make that payer the application's ongoing authority.

Read the resulting account's owner, data and authority fields. Existence alone does not establish correct initialization, and a predictable address alone does not enforce every business permission.

A token vault separates derivation and data ownership

Program signing is a runtime privilege

Because a PDA is off-curve, there is no normal Ed25519 private key for it. You cannot export a seed phrase for it or ask a wallet to produce its ordinary cryptographic signature.

During invoke_signed, the runtime derives addresses from the supplied seeds using the calling program's ID. Matching PDAs can receive signer privilege for that invocation. The callee then checks the authority required by its operation.

The program still needs correct authorization logic before making that call. If it lets an untrusted user choose any recipient or bypass ownership checks, the PDA's lack of a private key does not protect the intended assets.

Distinguish deriving program from base account owner. The runtime's derivation rule concerns the caller and seeds. An account's data owner controls data modifications under account rules. These are related in many designs but are not interchangeable definitions.

Follow a token vault’s three separate roles

Suppose a vault token account holds a particular mint. Its base owner is the Token Program managing that token account. Its stored token authority can be a PDA derived by an application program.

To make an authorized token transfer, the application invokes the token program and supplies the PDA's matching signer seeds. The token program checks that authority and the other transfer conditions.

The application did not gain permission to edit token data directly. It requested a token operation from the program that owns that data. The PDA is an authority address in this arrangement.

Associated token addresses provide another useful comparison: they are derived under the Associated Token Program, while the created holding account's base owner is the selected token program. Their derivation and management roles differ.

Validate the relationship at the program boundary

For each PDA, define the deriving program, exact seeds, canonical bump policy and expected account state. Then define the user or administrator allowed to trigger each operation.

For a token vault, check the mint, token program, holder authority and intended destination. For user state, check that the supplied user and stored relationship match. A signer constraint alone does not validate all of those facts.

Test a wrong user, wrong program ID, swapped seed order, absent account and attacker-selected destination. Review closing and reinitialization paths as well as first creation.

The CPI guide follows how these checks interact with nested program calls.

Common questions