Write a PDA explainer that will hold up in six months

Five days of PDAs, one counter program, and at least one transaction the runtime cheerfully refused. That is enough material for a real writeup, and writing it is how you commit to memory what you have learned.

The Scenario

The week is almost over. You have a working Anchor program, a per-wallet counter PDA, a close instruction that returns rent, a config PDA wired up with constraints, and a small graveyard of failed transactions from yesterday’s seed experiments. You also have a fuzzy mental model of why any of it works. It runs, and you can explain it to yourself in the moment, but if you closed your laptop today and opened it again six months from now, half of it would be gone.

Today you fix that. Not by writing more code, but by writing a public explainer of the PDA model as you now understand it, aimed at a developer who is exactly where you were a week ago. The Web2 framing of this arc has been “PDAs are like deterministic database keys derived from your program logic.” Your job is to take that one-line analogy and unpack it into something a junior backend engineer could read on the train and walk away with a working mental model.

The act of writing this is the point. Every time you try to explain why find_program_address needs a program ID, or why the bump is part of the seeds and not separate from them, you will discover a gap. Fill the gap, then keep writing. By the end of the day you will know your own program better than you do right now, and you will have a post on dev.to that future learners (and future you) can point to.

The Challenge

What you’ll need

A dev.to account
Your counter program repo from Days 64 through 68, open in your editor as a reference
A terminal where you can re-run any command you want to cite, so the snippets in your post are real and not remembered
Links to the official Solana PDA documentation and the Anchor PDA guide open in tabs, so you can fact-check yourself as you go

Steps

Start a new dev.to post with the title What I learned about PDAs in a week of building on Solana (or your own variation). Tag it with solana, rust, anchor, and webdev.
Open with the problem PDAs solve, not the mechanics. One short paragraph. Something like: “On Solana, programs are stateless. If your program needs to remember something per user, per game, per config, it needs a deterministic address it can find again later without storing it anywhere. PDAs are that address.”
Add a section called The mental model. Lead with the Web2 analogy and then push past it. PDAs are like a database primary key you can compute from the row’s logical identity, except the database is the entire Solana account model, the key derivation is a hash, and the program ID is baked in so only your program can sign for it. Be honest about where the analogy breaks: PDAs are not stored in a table, they are derived on demand and may or may not have an account at that address yet.
Add a section called Anatomy of a derivation. Show the canonical pattern from your own program, copied verbatim from your lib.rs. Something like:

#[account(
    init,
    payer = user,
    space = 8 + Counter::INIT_SPACE,
    seeds = [b"counter", user.key().as_ref()],
    bump
)]
pub counter: Account<'info, Counter>,

Walk the reader through every piece: the static seed prefix, the dynamic seed, what gets hashed with the program ID, and what the bump is doing. The bump is not magic; it is the byte the runtime tried last that pushed the result off the ed25519 curve. Explain that.

Add a section called Why the seeds matter. Reuse what you learned in yesterday’s experiment day. Show two derivations from your counter program: [b"counter", user.key().as_ref()] versus [b"counter"]. The first gives every wallet its own PDA. The second gives every wallet the same PDA, which is sometimes exactly what you want (a global config) and sometimes a disaster (a shared counter). Be specific about which is which.
Add a section called What the bump buys you. Explain why the canonical bump (the one find_program_address returns) is the only safe one to use. Mention that Anchor stores it for you when you write bump in the constraint, and that you should re-pass the stored bump on subsequent instructions rather than re-deriving every time, because re-derivation is expensive and storing the bump is free.
Add a section called The full lifecycle. Walk through your week as a sequence: derive the address, initialize the account at that address with init, mutate its data on subsequent instructions, and close it to reclaim rent. Mention that close is not “delete from a table” but “zero the data, transfer the lamports, mark it for garbage collection at the end of the transaction.” That distinction matters and almost no Web2 analogy captures it.
Add a short What I would tell past me section. Three or four bullet points, your own opinions, written informally. Things you wish you had known on Day 64. Examples: the program ID is part of the derivation, so the same seeds in a different program produce a different address. PDAs cannot sign transactions on their own; only programs can sign on their behalf using the same seeds. init_if_needed is convenient and also a footgun you should reach for deliberately, not by default.
Close the post with a single paragraph pointing readers at the official docs you used: the Solana PDA page, the Anchor PDA documentation, and the Anchor crate docs. Tell them where your code lives if you pushed it to GitHub.
Re-read the whole post once with the eyes of a developer who has never written a Solana program. Cut anything that assumes too much. Add a sentence anywhere you wrote a term (rent, lamport, signer seeds, account model) that you did not explain. This is the editing pass that turns a brain dump into something useful.
Publish. Add the #100DaysOfSolana tag to the post and to whatever social channel you share it on.

Resources

Submission

Publish your post on DEV and submit the link below.