Write the CPI explainer you wish you had on day 71

Five days ago, CPI was three letters you had started to recognise in the docs. Now you have watched programs call the System Program, Token-2022, and even your own code, and you can explain what the runtime checks during that hand-off. You can explain why PDA signer seeds stand in for a private key, and why an AccountNotSigner error is not noise but a diagnosis. That working knowledge will fade unless you pin it down. So today you pin it down in public.

The scenario

A reader who has been in the ecosystem for three years has forgotten which parts were confusing. You have not. You still remember the first time you stared at a CpiContext and wondered which argument was which, and you still remember the moment invoke_signed finally clicked when you matched the seeds in your handler to the seeds in your #[account(seeds = ..., bump)] constraint.

That memory is the thing you publish today. A short, opinionated dev.to post about the CPI pattern, written for the version of you who started this arc on Day 71. Not a tutorial that repeats the official docs. A field guide. The shape of the mental model, the three or four things you wish someone had told you first, and one runnable example pulled directly from code you have already written this week.

The challenge

What you’ll need

A free DEV account.
The Anchor program from earlier this week, especially the program-to-program call from Day 74 and the PDA-signed transfer from Day 73.
A text editor for drafting. Dev.to also accepts Markdown directly in its editor, documented in the DEV editor guide.
The Anchor documentation and Token-2022 documentation open in tabs, so you can link directly to the primitives you reference.

Steps

Pick the one idea you wish you had understood on Day 71. A good post has one thesis, not five. Yours might be “a CPI is a function call with a guest list,” or “signer seeds are how a program proves it is the PDA,” or “the same CpiContext pattern works whether you are calling the System Program, Token-2022, or your own code.” Write that sentence at the top of a scratch document. Every paragraph in the post has to earn its place by supporting that one sentence.
Outline before you draft. A useful structure for a technical post in this format is: a one-paragraph hook that names the confusion, a short “mental model” section, one minimal code example, a “what tripped me up” section that names a specific error you actually saw this week, and a closing paragraph that points the reader at the official docs. Five sections, roughly 600 to 900 words total. Resist the urge to make it longer.
Pull one real code snippet from your own Anchor program. Choose the smallest version of a CPI you have working. The cleanest candidate is usually the System Program transfer from Day 73 or the program-to-program call from Day 74. Trim it down to the handler function plus its Accounts struct. Do not paste an entire lib.rs file. Readers cannot learn from a wall of code; they can learn from twenty lines that are doing exactly one thing.
Write the mental model section first, code second. Code without a model is a copy-paste hazard. Explain, in your own words, what these three pieces are and how they relate to each other:
- The program being called, identified by its program ID.
- The accounts that program needs, which your calling program has to pass through.
- The signer authority, which is either a real user keypair already signing the transaction, or a PDA your program signs for using invoke_signed and a matching seeds array.
If you can describe those three pieces clearly, the code snippet that follows reads as an illustration rather than a puzzle.
Add the “what tripped me up” section. Reach back to Day 75’s deliberate failures. Pick one error you actually saw on your terminal this week, paste the exact error string, and explain in two sentences what it meant and what fixed it. AccountNotSigner, ConstraintSeeds, and InvalidProgramId are all strong candidates.
Add front matter and tags in dev.to. When you paste your draft into the dev.to editor, add a clear title, a short subtitle, and four tags. solana, rust, anchor, and web3 are good starting tags; the tag directory shows which tags have active readers. Add a cover image if you have one, but do not block the publish on it.
Read it once out loud, then publish. Reading aloud catches the sentences where you bluffed past something you do not fully understand. If a sentence makes you stumble, rewrite it. When the read-through is clean, click Publish.
Cross-link your post to the week. Add a short closing line that says which days of #100DaysOfSolana this post draws from, so future readers can find the surrounding context. This is also how you build a small body of work that links together rather than scattering single posts.

What just happened

You took five days of hands-on work and turned it into a single artifact a stranger can read in four minutes. That act of compression is itself a learning step. The places where your draft felt vague are the places where your understanding is still soft, and the places where the prose flowed are the places where the model has actually settled. Writing the post is a test of comprehension that no unit test can run for you.

And for your own future self: when you sit down in six months to build a more ambitious program, your first stop will be your own post. You will trust it more than any other source, because you will know exactly what assumptions it makes and exactly what it leaves out. Documentation written for past-you is documentation written for the most reliable reader you will ever have.

Resources

DEV editor guide, including Markdown syntax and front matter options.
Solana docs: Cross-Program Invocations, the canonical reference to link from your post.
Anchor docs: CPI, covering CpiContext, CpiContext::new_with_signer, and PDA signer seeds.
anchor_lang::system_program, the Anchor helpers for calling the System Program, useful as a “see also” link.

Submission

Publish your post on DEV and submit it below.