Every Solana program eventually hits the same question: where do I put my data, and how do I find it again later?

Programs are stateless, so a program's data lives in separate accounts, each at an address. The moment you store something, you owe an answer to a problem databases tend to hide from you: what address does this live at, and how does the program find it again tomorrow? Program Derived Addresses are Solana's answer. The name scares people off, but the idea is mostly "an address you compute instead of remember, that only your program can control."

The problem, in code

Say each user gets a counter account. The normal way to make an account is to generate a fresh keypair and store data at its public key:

import { Keypair } from "@solana/web3.js";

const counter = Keypair.generate();
// counter.publicKey is something random, e.g. 7Hx4...9fT
// create the account at that address, write count = 0

It works. But the address is random, so nothing connects this user to that address. Tomorrow, when the user comes back to increment, how does your program find their counter? You're forced to keep a lookup table somewhere:

// the mapping you now have to store and never lose
const counters = {
  "9fYL...user1": "7Hx4...9fT",
  "B2k9...user2": "Qz1p...4dR",
  // ...times ten thousand users
};

Lose that table, lose the data, even though the accounts are right there on chain. You're storing files in a warehouse and writing the shelf number on a sticky note.

The fix: compute the address from what you already know

What if the address were a function of the user instead of random? Give a function the word "counter" and the user's public key, and it hands back a fixed address. Same inputs, same address, every time. No table.

That's a PDA. PDAs are 32-byte addresses derived deterministically from a program ID and a set of seeds. The seeds are the meaningful inputs you pick (here, "counter" + the user's key). With @solana/web3.js, the library Anchor's client uses:

import { PublicKey } from "@solana/web3.js";

const [counterPda, bump] = PublicKey.findProgramAddressSync(
  [
    Buffer.from("counter"),      // a label
    userPublicKey.toBuffer(),    // the user's pubkey
  ],
  MY_PROGRAM_ID,
);
// counterPda is the SAME every time for this user. No mapping needed.

The mapping table is gone: any time you need a user's counter, you re-derive it, and the address itself encodes who it belongs to. With Anchor you'll often skip the explicit call entirely and let the client derive PDAs from the IDL, but under the hood this is what runs.

The twist: it has no private key

Normal addresses are public keys sitting on the Ed25519 elliptic curve, and every point on that curve has a matching private key. That private key is what signs transactions. But we just hashed a counter address into existence without making a keypair, so who holds its private key?

If the hash happened to land on the curve, some stranger might, which would let outsiders sign for your program's accounts. So Solana guarantees a PDA sits off the curve, meaning no private key exists for it. That is the title: an address with no private key. It is the whole point, because it means only the program that derived it can control it.

The bump, in one example

A given set of seeds plus the program ID produces a valid off-curve address only about half the time, so the derivation includes one more input: a single byte called the bump. The search starts at 255 and counts down, hashing the seeds, the program ID, and the current bump together on each attempt until the result lands off the curve:

hash(seeds + program_id + 255) -> on curve?  try 254
hash(seeds + program_id + 254) -> on curve?  try 253
hash(seeds + program_id + 253) -> off curve! use this.  bump = 253

The bump is part of the hash from the very first attempt at 255, not something added only after a bump-less hash fails. The first value that lands off-curve, the highest one that works, is the canonical bump. findProgramAddressSync returns it as the second value, the bump above. You'll want to use the canonical bump rather than any other valid one, because the same seeds can produce different valid addresses under different bumps, and accepting any of them would let an attacker slip a counterfeit account past your checks.

In Anchor: derivation becomes a constraint

On the program side, Anchor does the derivation and the check for you. Creating the counter (storing the bump for later):

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
        seeds = [b"counter", authority.key().as_ref()],
        bump,                                  // Anchor finds the canonical bump
    )]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

Then later, validating it on every other instruction:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(
        mut,
        seeds = [b"counter", authority.key().as_ref()],
        bump = counter.bump,                   // reuse the stored bump
    )]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

Read the seeds line as a rule: this account's address must derive from "counter" and this authority's key. When the instruction runs, Anchor re-derives the address and checks that the passed-in account matches. Pass a different account and it's rejected before your code runs. The address is the proof, so there's no mapping left to tamper with. (Store the bump in your Counter struct at init: pub bump: u8.)

The difference between the two structs is the whole lifecycle: init creates the account at the derived address the first time and lets Anchor search for the canonical bump, while the plain seeds + bump = counter.bump form validates an account that already exists, reusing the stored bump so it doesn't pay to re-search.

Four things that trip people up

• Seed mismatch between client and program. The seeds, their order, and their byte encoding need to match on both sides. Buffer.from("counter") in the client has to line up with b"counter" in the program, in the same position. One reordered or mistyped seed derives a different address, and the constraint rejects it. A lot of "my PDA doesn't match" bugs come down to this.
• Not storing the bump. If you don't save the canonical bump at init, every later instruction has to re-derive it by searching, which burns compute for no reason. Store it once in the account and reuse it with bump = counter.bump.
• Treating the rejection as a bug. When you pass the wrong account and the seeds constraint throws, that's the security model working, not a failure. The point is that only the correctly derived address gets accepted.
• Deriving without the canonical bump. Other bump values can produce valid but different addresses from the same seeds. Sticking with the canonical one, which is what Anchor's bare bump and findProgramAddressSync give you by default, keeps client and program in agreement.

The payoff: a program that signs for itself

No private key means no human can sign for a PDA, so how does a program move tokens out of an escrow it owns? The runtime gives the owning program a special power: the program whose ID derived the PDA can sign for it, through invoke_signed during a cross-program invocation. The program's code becomes the authority, with no key anywhere.

That's the foundation under most escrows, vaults, and lending pools on Solana: a program holding assets no human can drain, releasing them only by its own logic. We'll go deep on invoke_signed and CPIs in the next post. For now, hold the shape: the missing private key isn't a weakness, it's what lets a program act as a trustless custodian.

TL;DR

• Stateless programs store data in accounts at addresses; remembering random addresses doesn't scale.
• A PDA derives the address from seeds + program ID, so you recompute it instead of storing it.
• It's forced off the Ed25519 curve, so no private key exists and no outsider can sign for it.
• The canonical bump (counting down from 255) is the reproducible address you'll normally use.
• In Anchor, seeds + bump constraints derive and validate the account for you.
• The deriving program can sign for its own PDA (invoke_signed), which is what powers escrows and vaults.

Going further

The Solana PDA docs cover derivation, the canonical bump, and the off-curve guarantee, with runnable examples on the derivation page (the "Legacy" tab is the @solana/web3.js version Anchor's client uses). The Anchor PDA guide walks through the seeds and bump constraints you'll actually write, and the full account constraints reference lists every constraint in one place.

If you're doing 100 Days of Solana, the next arc puts all of this to work, and the challenges should now read like something you already understand. Not joined yet? It's not too late: mlh.link/solana-100.