DEV Community: Mubarak Yakubu

From Token Watcher to Program Builder: 100 Days of Solana

Mubarak Yakubu — Tue, 13 Oct 2026 15:36:29 +0000

I came into this program as a Web2 developer who moderates Web3 communities.

I knew Solana as "the blockchain people build products and solutions on, and launch tokens on." That's it. I'd watched projects build on it, seen the ecosystem from the outside as a community moderator and ambassador. But I'd never written a line of Solana code.

Ninety-nine days later, I have a program deployed to devnet with an agent that reads its state and a Token-2022 badge minted to my wallet.

Here's what actually changed.

What I expected

I expected blockchain development to feel like backend development with a crypto coating on top. Servers become programs. Databases become accounts. Same shape, different words.

That was wrong in a specific way.

There is no server. There's no database you can quietly edit. Everything is a transaction, and every transaction is permanent.

When I started, I assumed the authority owner could just change things after the fact. Redeploy, fix a bug, update a record. And in one sense, that's true. Programs are upgradeable by default. The upgrade authority can push new code to the same program ID.

But here's what I got wrong: you can change the code, but you can't change what the code already did.

If a wallet called your program yesterday and wrote a record, that record is on-chain. You can write a new transaction that changes its current state, but the history stays. You can't reach back and pretend it didn't happen.

That's the shift Web2 doesn't prepare you for. There's no UPDATE that erases the old value. There's no rollback. The code you deploy is the code that runs, and what it wrote is written.

The moment it clicked

The vault program.

I built a program that holds SOL, lets you deposit, lets you withdraw, and enforces that only the authority can withdraw. Small. Basic.

But when it worked, I saw something bigger. The pieces I'd been learning one at a time (accounts, PDAs, constraints, error codes, tests) stopped being separate exercises. They became a system.

I've worked in Web2 long enough to recognize that feeling. It's the moment you stop seeing a framework and start seeing the shape of something you can build. The vault was small, but it was the first time I could picture building real products this way.

What I understand now

The toolchain is what makes Solana manageable.

That's a distinction I didn't have words for until recently. The protocol is what Solana is: accounts, transactions, programs, the runtime. You could write a Solana program in raw Rust with no framework at all. It would just be painful.

The toolchain is what makes the protocol usable.

Anchor gives you structure. The #[program] macro, #[derive(Accounts)], the require! macro. Everything has a place. Without it, you're writing instruction dispatch and account validation by hand.

PDAs are a protocol feature, but knowing when and how to use them is toolchain-level knowledge. Anchor gives you a clean way to declare them: seeds = [...]. Once I understood that a PDA isn't a wallet, that it's a deterministic address only your program can sign for, half of Solana's design made sense.

The capstone's seeds are [b"ship", builder.key()]. That's it. The address itself enforces "one record per wallet." No runtime check, no guard clause. The seed is the constraint.

IDLs are the bridge between the on-chain program and everything else. The protocol doesn't know or care about IDLs. But without them, every client that wants to call your program has to hand-encode instruction bytes. With them, you get autocomplete, typed clients, and agents that know what to call.

You can learn the protocol and still not be able to build anything real. The toolchain is the difference.

What I built for the capstone

proof-of-ship. One instruction: ship(project_name, message). Any wallet can call it once to permanently record on-chain that it shipped a capstone.

Program: 6xKXthNFn8YdaPVqdrAJWDfaAxeNeBX5MZuUSaVxd7mL
Explorer: https://explorer.solana.com/address/6xKXthNFn8YdaPVqdrAJWDfaAxeNeBX5MZuUSaVxd7mL?cluster=devnet
Repo: github.com/Mubaraqq/mlh_100daysofsolana/tree/main/day-99

The capstone pulls from everything:

An Anchor program with a PDA whose seeds encode the rule
Custom errors and a runtime constraint
Happy-path and failure-path tests
A TypeScript script that calls ship on devnet
A read-only agent tool that fetches any wallet's ShipRecord
A 1-of-1 Token-2022 badge with metadata embedded in the mint

Small. Complete. Deployed.

What I'd tell another developer

Three things.

The toolchain is not the same as the protocol. You can learn Solana primitives and still not know how to build on Solana. Anchor, PDAs, and IDLs are what make the primitives usable. Don't skip them.

Account design is the hard part. Anyone can write an instruction. The interesting decisions are in the accounts: what state you store, how you derive the PDAs, what the seeds encode. A good PDA design can replace a dozen runtime checks.

Web2 instincts help, then they get in the way. The instinct to check state before writing is fine. The instinct to assume you can fix a mistake after it's made is not. On Solana, the code and the state are the contract.

What comes next

I want to build systems, not demos.

The vault program showed me I could. The capstone showed me the pieces fit together. The agent work showed me there's a whole layer of tooling being built right now that most developers haven't touched yet.

Concretely:

Go deeper on agent tooling, since the harness layer is where the interesting engineering is right now
Contribute to open source, starting with the tools I used
Help other developers starting behind me, since I moderated communities before I wrote code and I still want to be useful there

One hundred days ago, Solana was unfamiliar territory. Today I have a program live on devnet that anyone can look up, call, and verify.

More importantly, I can explain why it works.

This is Day 100 of #100DaysOfSolana.

From Prompt to Policy: How I Made a Solana Agent Safe Enough to Run Unattended

Mubarak Yakubu — Sat, 10 Oct 2026 16:04:31 +0000

Over five days I built an autonomous agent that manages Solana devnet wallets. It reads balances, moves SOL, and chases a plain-English goal without me telling it the steps.

The interesting part isn't that it works. It's that I trust it enough to let it run.

And the reason I trust it has almost nothing to do with the model.

This is the manual for that system.

What it does

You give it a goal:

Make sure the savings wallet holds at least 0.2 SOL. Check balances before moving anything, move only what is needed from the operating wallet, and verify the final balances before you finish.

No recipient. No amount. No steps.

The agent reads both balances, does the math, decides if a transfer is needed, runs it through a policy layer, verifies, and reports back.

The inventory

Five moving parts.

1. Agent loop

File: agent-workflow.mjs
Day: 96 (evolved from Days 93 and 95)
Job: Calls the model, reads its tool requests, runs them, feeds results back, repeats until the model stops or hits the turn limit.

2. Balance tool — get_balance

File: inside agent-workflow.mjs
Day: 92 (originally), folded into Day 96
Job: Reads the lamport balance of any devnet account.

3. Transfer tool — transfer_sol

File: inside agent-workflow.mjs
Day: 93 (as send_sol), renamed for Day 96
Job: Moves SOL from the operating wallet to a recipient, but only after the policy approves.

4. MCP server

File: day-94/solana-mcp-server/server.ts
Day: 94
Job: Exposes a vault program's tools to any MCP client over stdio.

5. Policy engine

File: day-95/solana-policy-agent/policy.mjs and inline in day-96/agent-workflow.mjs
Day: 95 (as a module), 96 (inlined)
Job: Deny-by-default check on every transfer. Allowlist, per-transfer cap, per-run cap.

The flow

your goal, in plain English
        |
        v
+---------------------------+
|  agent loop (LLM)         |  decides which tool to call next
|  agent-workflow.mjs       |  runs until the model stops or MAX_TURNS
+---------------------------+
        |
        v  tool call, e.g. transfer_sol
+---------------------------+
|  tool dispatcher          |  routes the call to the right handler
|  runTool()                |  get_balance or transfer_sol
+---------------------------+
        |
        v
+---------------------------+
|  policy engine            |  deny by default; every spend checked
|  checkPolicy()            |  allowlist, per-transfer cap, per-run cap
+---------------------------+
        |  allowed
        v
+---------------------------+
|  Solana devnet            |  transaction submitted and confirmed
+---------------------------+
        |
        v
   every event logged to run-log.json

The MCP server from Day 94 is a sibling stack. It exposes the vault program to external clients. It does not sit on this flow.

The tools

Tool: `get_balance`

Inputs: address (string) — Base58 account address
Returns: { address, lamports }
Side effects: none (read-only)
Guarded by policy: no

Tool: `transfer_sol`

Inputs: to (string), lamports (number)
Returns: one of three statuses:
- { status: "confirmed", signature } — it landed
- { status: "denied", reason } — policy refused it, nothing signed
- { status: "failed", reason } — policy allowed it, but the send failed on chain
Side effects: spends lamports from the operating wallet
Guarded by policy: yes

That three-way return is on purpose. A denial is not an error. It's a normal result the agent should reason about. The tool description says it outright:

"A denial is not an error: adjust your plan or stop."

That line is the contract.

The policy layer

This is the heart of it. The part that makes the agent safe. The one piece that never varies between runs.

Deny by default. checkPolicy() returns { allowed, reason }. Every rule is a reason to say no. The function only returns allowed: true when it runs out of objections.

Three rules, checked in order:

1. Allowlist. Only addresses in POLICY.allowedRecipients can receive funds.

2. Per-transfer cap. No single transfer over POLICY.maxLamportsPerTransfer.

3. Per-run cap. Total spend across the run cannot exceed POLICY.maxLamportsPerRun. Tracked in spentThisRun, which adds up after each confirmed send.

The default when no rule matches: deny. There's no allow branch unless all three pass.

A denial looks like this to the model:

{ "status": "denied", "reason": "200000000 lamports exceeds the per-transfer cap of 50000000" }

The model sees a normal tool result. Nothing crashes. Nothing signs.

The core invariant:

The prompt can change. The model can change. The tool-call sequence can change.
No transaction moves funds without passing this layer.

The signing function is only called after checkPolicy() returns allowed: true. There is no code path where a denied transfer touches the keypair.

Two things worth knowing:

The per-transfer cap is a rate limit, not a spend limit. I proved that in Trial 2 below.

The policy module is portable. Day 95 built it as a standalone policy.mjs. Day 96 inlined it. Same logic. It knows nothing about AI, prompts, or models.

Annotated run — Trial 1, goal met

Goal:

Make sure the savings wallet holds at least 0.2 SOL.

[turn 1] tool_call      {"tool":"get_balance","input":{"address":"Ddfz...c6cN"}}
# Reads the savings wallet first. Doesn't know the balance yet.

[turn 1] tool_result    {"lamports":0}
# Empty. Shortfall is the full 0.2 SOL.

[turn 2] tool_call      {"tool":"get_balance","input":{"address":"9Sxx...dTf1"}}
# Reads the operating wallet, to confirm it can cover the transfer.

[turn 2] tool_result    {"lamports":4441970000}
# 4.44 SOL. Enough. Plan is valid.

[turn 3] tool_call      {"tool":"transfer_sol","input":{"lamports":200000000,"to":"Ddfz...c6cN"}}
# Computes the exact shortfall: 0.2 SOL. No more.

[turn 3] policy_check   {"allowed":true,"reason":"within policy"}
# All three rules pass. Allowlist: yes. Per-transfer: 0.2 ≤ 0.25. Per-run: 0.2 ≤ 0.5.

[turn 3] tool_result    {"status":"confirmed","signature":"2mGQ...wisv"}
# Signed and confirmed on devnet. Real signature.

[turn 4] tool_call      {"tool":"get_balance","input":{"address":"Ddfz...c6cN"}}
# Verifies the savings wallet, as the goal instructed.

[turn 4] tool_result    {"lamports":200000000}
# Exactly 0.2 SOL. Goal met.

[turn 5] tool_call      {"tool":"get_balance","input":{"address":"9Sxx...dTf1"}}
# Verifies the operating wallet too.

[turn 5] tool_result    {"lamports":4241965000}
# Dropped by exactly 0.2. Nothing extra moved.

[turn 6] final_report   "The savings wallet now holds 200,000,000 lamports (0.2 SOL)..."
# Honest report. Matches what actually happened on chain.

6 turns. 5 tool calls. 1 confirmed transfer. 0 denials. Goal met exactly.

Annotated run — Trial 2, policy denial

Goal changed to 0.4 SOL. Per-transfer cap tightened to 0.05 SOL.

[turn 3] tool_call      {"tool":"transfer_sol","input":{"lamports":200000000,"to":"Ddfz...c6cN"}}
# Tries to move the full 0.2 SOL in one transfer.

[turn 3] policy_check   {"allowed":false,"reason":"200000000 lamports exceeds the per-transfer cap of 50000000"}
# Refused. 0.2 > 0.05. Nothing signed.

[turn 3] tool_result    {"status":"denied","reason":"..."}
# Model gets the denial as a normal tool result.

[turn 4] tool_call      {"tool":"transfer_sol","input":{"lamports":50000000,"to":"Ddfz...c6cN"}}
# Adjusts. Drops to the cap: 0.05 SOL.

[turn 4] tool_result    {"status":"confirmed","signature":"..."}
# Allowed. Signed.

[turn 5, 6, 7] ...three more 0.05 transfers, all confirmed
# Split the work into pieces.

[turn 12] ...hit MAX_TURNS before writing a final report

12 turns. Hit the limit. Overshot to 0.45 SOL instead of 0.4.

The finding: the per-transfer cap did not stop the agent. It slowed it down. The agent found a path around it — four small transfers instead of one big one. Only the per-run cap bounds total spend.

Lessons learned

1. The policy layer is the heart of the system, not the model.

Everything else is replaceable. The model can change. I went from a local 3B to a 120B on Groq. The prompt can change. The tool-call sequence can change, and it does, run to run. The policy module doesn't care about any of that. It takes a recipient and an amount and returns a decision. Same rules every time. That's the piece you actually trust.

2. MAX_TURNS doesn't care about your goal.

In Trial 2, the agent hit the turn limit mid-plan. It had no way to know it was about to be cut off. It just stopped. No final report, no summary, no "here's where I got to." A turn limit is a hard stop, not a graceful one. In production, you'd want the last turn reserved for a forced report.

3. A per-transfer cap is a rate limit, not a spend limit.

I thought capping transfers at 0.05 SOL would stop the agent from moving 0.2. It didn't. It split the work into four transfers and moved the same amount. The cap changed how the agent spent, not whether it spent. Only the per-run cap bounds total spend. Without it, the per-transfer cap just slows the drain down.

4. Confirmation lag is real.

The model read the savings balance while one transfer was still confirming. Saw less than expected. Sent another. Overshot by 0.05. The model has no built-in sense that a recent write might not have settled yet. Unless you tell it, it treats every read as final.

5. Non-determinism isn't a bug, it's the environment.

I ran the same goal twice in Trial 1. First run: 6 turns, 1 transfer. Second run: 3 turns, 0 transfers — because the goal was already met. Same code, same model, different behavior, both correct. That's not something you fix. It's something you design around. The policy holds regardless of which path the model takes. That's the whole argument.

Open questions

Should the policy layer persist spentThisRun across runs, instead of resetting each time?
Should transfer_sol wait for finalization rather than confirmation before returning?
What happens when the agent needs to move funds to a recipient that isn't the savings wallet? The allowlist is one address today.

These are the edges. They're where the next version starts.

Part of #100DaysOfSolana. Days 92–96 built this stack. Day 97 documented it.

My Solana Program Launch Checklist

Mubarak Yakubu — Mon, 28 Sep 2026 13:03:10 +0000

Just shipped my first Solana program to mainnet. Took notes the whole way.

But I know how this goes. Three weeks from now, I'll stare at a terminal and forget half of it.

Here's the checklist I wish I had.

Phase 1: Pre-flight, on devnet

Catch problems while they're cheap.

Every test passes against your final build.
You've run the program end-to-end on devnet exactly as it will run on mainnet.
You produced a verifiable build with anchor build --verifiable.
Your deploy wallet holds enough SOL for the rent-exempt minimum plus fees.

Watch out: Once you have a verifiable build, don't overwrite it with a plain anchor build or cargo build-sbf. Those produce a different hash and break verification later.

Phase 2: The deploy itself

This is the irreversible phase. Slow down here.

Switch your CLI to mainnet-beta with solana config set --url mainnet-beta.
Confirm with solana config get that you're pointing at the right cluster.
Run your deploy command.
If the last attempt struggled to land, add a priority fee with --with-compute-unit-price and route through a reliable RPC with --use-rpc.

Watch out: A deploy is not atomic. If it's interrupted, you may be left with a buffer account holding your SOL. Check for stranded buffers and recover:

solana program show --buffers     # list stranded buffers
solana program deploy <SO_PATH> --buffer <BUFFER_KEYPAIR> #resume a stalled deploy
solana program close <BUFFER_ADDRESS  #close and reclaim the rent

Phase 3: Authority and verification

Right after deploy. Confirm what landed and decide who controls it.

Run solana program show <PROGRAM_ID> and read back the upgrade authority. Is it what you intended?
Decide who holds the upgrade authority: a single keypair you control, a Squads multisig, or --final for permanent immutability. Write down which one and why.
Publish your IDL on-chain with anchor idl init.
Regenerate your Codama client from the published IDL.

Watch out: Skipping the IDL publish causes build verification to fail. Do it in the same session as the deploy.

Phase 4: Frontend and going live

The last mile. Make sure a real human can use it.

Point your React frontend at the mainnet program ID.
Confirm the Wallet Standard connection surfaces real wallets against mainnet.
Confirm every error your frontend can throw still produces a calm, legible message now that the stakes are real: rejected approval, insufficient funds, expired blockhash.
Announce the launch.
Write down where users report problems.

What surprised me

One thing surprised me most. The deploy itself was the easy part. The hard part was deciding who holds the upgrade authority and what to do with it.

A single key on your laptop can replace your program. That's the biggest risk in the whole launch.

A multisig distributes the key. But the real protection is a timelock plus a verifiable build. The timelock gives users time to see an upgrade coming and exit if they don't like it. The verifiable build lets anyone confirm the on-chain bytecode matches your source.

Signer count is secondary. Transparency and delay are what actually protect users.

Resources

Deploying Programs — the official guide to deployment, buffer accounts, and recovery
Anchor Verifiable Builds — how to produce a build whose on-chain bytecode matches your source
Managing Program Upgrades with Multisig — Squads on why and how to secure upgrade authority
Solana Production Readiness — RPC reliability and production considerations

My Solana Program Security Checklist

Mubarak Yakubu — Wed, 16 Sep 2026 17:09:15 +0000

A pre-deploy checklist I run top to bottom before any Anchor program goes to mainnet. Built from the bugs I reproduced myself.

This checklist is for Anchor developers about to deploy to mainnet. Run it top to bottom before every deploy. It's built from the bugs I reproduced myself over the last few days: forged accounts, arithmetic overflows, and CPI trust failures. Each item is a yes-or-no check. If you can't answer yes, stop and fix it.

1. Account Validation

Every deserialized account has its owner verified. Typed Account<'info, T> does this automatically. Raw AccountInfo or UncheckedAccount does not.
Account types are distinguished by their 8-byte discriminator, so one account type cannot be passed where another is expected.
Any remaining_accounts passed in are validated before use.
Any PDA is verified with seeds and bump, not just accepted by address.

Why this matters: In February 2022, $326M left the Wormhole bridge because the program trusted a forged account without verifying it was the real one. The fix was to check the owner before reading the data.

2. Authority and Signer Checks

Every privileged instruction confirms the expected signer with Signer<'info> or has_one / constraint checks.
No instruction trusts a pubkey without also checking its signer flag. Comparing a public key only proves someone knew a public key. Public keys are public.
UncheckedAccount for an authority is a red flag. If you see it, you have no signer check.
Admin-only instructions check the admin against stored state AND require the signer.
The vault's owner is set on first deposit and never silently overwritten.

Why this matters: Comparing a public key without checking the signer flag lets an attacker pass any public key. The instruction must require a signature.

3. Arithmetic Safety

Every balance or supply change uses checked_add, checked_sub, or checked_mul, never raw +, -, or * on untrusted values.
No silent cast that could truncate (e.g., u64 to u32).
Overflow and underflow return a named error, not a panic.
Property tests prove that a deposit never shrinks a balance and a withdrawal never increases it.

Why this matters: A u64 that overflows wraps silently to a tiny number. Without checked math, a deposit of 2 lamports into a balance one lamport below u64::MAX wraps the balance back to 1. The attacker destroys the vault with a tiny deposit.

4. CPI Safety

Every CPI verifies the target program ID is the one expected, not whatever account the caller supplied.
Program<'info, T> is used where possible, so Anchor checks the program ID.
Accounts are reloaded after a CPI if their data is read again. The callee may have changed the account.
Signer seeds used for PDA-signed CPIs match the seeds in the #[account(seeds = ...)] constraint exactly. One byte off and the runtime rejects the PDA.
No CPI trusts the callee to validate its own accounts. The caller is responsible for passing the right ones.

Why this matters: A CPI that accepts whatever program ID the caller supplies can be redirected to an attacker's program. The attacker's program returns success and the caller believes the work was done.

5. Account Lifecycle

Closed accounts are emptied and marked so they cannot be revived or reused within the same transaction.
No instruction allows reinitializing an already-initialized account. init fails on existing accounts. init_if_needed succeeds silently. Use it deliberately.
Closing an account returns the rent to the correct wallet. Never to an arbitrary signer.
close = authority is used, not manual lamport draining.

Why this matters: An account that is closed but not marked can be reinitialized and reused. An account that is reinitialized loses its old state and can be repurposed by an attacker.

6. Pre-Deploy Hygiene

cargo audit has been run and reports no known advisories in dependencies.
Adversarial tests pass, not just the happy path. Every defense has a test that proves it works.
Property tests pass. Rules like "a deposit never shrinks a balance" hold for random inputs.
Fuzz tests pass. Trident has run the program through thousands of random instruction sequences without a panic.
anchor keys sync has been run. The program ID in lib.rs matches Anchor.toml.
The overflow-checks = true flag is set under [profile.release] in the workspace root Cargo.toml.
grep -rn "UncheckedAccount\|AccountInfo\|/// CHECK" programs/*/src returns only accounts you have manually verified.

Why this matters: The best defense is a test that proves it works. A constraint you cannot see fail is a constraint you are only hoping is there. Run the checklist before every deploy, not just the first one.

This checklist is a living document. Run it before every mainnet deploy, top to bottom. If you find something it misses, open an issue or reach out. Security is a community effort.

This post draws from Days 75-82 of #100DaysOfSolana.

CPIs on Solana: From Confusion to Confidence

Mubarak Yakubu — Fri, 04 Sep 2026 16:29:14 +0000

On Day 71, I thought CPI was a magic black box. I knew it stood for Cross-Program Invocation, but I didn't understand why the runtime needed a program ID, accounts, and sometimes signer seeds. After working through this arc, I realized the pattern is always the same. The program ID says which program to call, the accounts say what data to read or write, and the signer seeds say who's authorized. Whether you're moving SOL through the System Program, minting tokens through Token-2022, or calling your own counter program, the CpiContext shape never changes.

The mental model

A CPI is how one program calls another. Think of it like a function call, but with three explicit pieces.

The program ID tells the runtime which program you're calling. This is like a function name in a library.

The accounts are the data the callee needs. This is like passing arguments, but the arguments are accounts on-chain.

The signer authority is who is authorizing this call. This is either a real wallet (the signature flows through) or a PDA (the program signs with seeds).

The same CpiContext struct bundles all three. You build it once and pass it to the helper function. The runtime handles the rest.

A real code snippet

This is the smallest CPI I wrote this week. The caller program calls the counter program's increment instruction.

pub fn bump(ctx: Context<Bump>) -> Result<()> {
    let cpi_ctx = CpiContext::new(
        ctx.accounts.counter_program.key(),
        Increment {
            tally: ctx.accounts.tally.to_account_info(),
        },
    );
    cpi::increment(cpi_ctx)?;
    Ok(())
}

The first argument is the program ID. counter_program.key() tells the runtime which program to call.

The second argument is the accounts struct. Increment { tally: ... } provides the account the counter program needs.

The signer authority is implied here. The user signed the outer transaction, and that signature flows through to the CPI automatically.

If the signer was a PDA, I would need .with_signer(signer_seeds) to prove the program owns the PDA. But for a regular wallet, the signature just works.

The cpi::increment helper does the actual invocation. If the counter program's increment fails, this function returns an error and the entire transaction rolls back.

What tripped me up

The error that tripped me up most was ConstraintSeeds. I changed one byte in the signer seeds — from b"vault" to b"voult" — and the transaction failed with:

Program log: AnchorError caused by account: vault. Error Code: ConstraintSeeds.

The error meant the runtime re-derived the PDA address from my seeds and got a different address than the account I passed. The seeds must match exactly. One byte off and the runtime refuses to sign.

The fix was simple: match the seeds in the CPI to the seeds in the #[account(seeds = ...)] constraint. If they match, the runtime treats the PDA as a signer. If they don't, you get ConstraintSeeds.

Closing

CPIs are how Solana programs compose. The pattern is always the same: program ID, accounts, signer. Whether you're calling the System Program, Token-2022, or your own code, the CpiContext shape doesn't change.

If you're stuck, check the three pieces. The program ID tells the runtime where to go. The accounts tell it what data to touch. The signer tells it who authorized the call. When all three line up, the CPI works.

This post draws from Days 71-75 of #100DaysOfSolana.

Understanding Solana PDAs: A Web2 Developer's Guide

Mubarak Yakubu — Sun, 09 Aug 2026 17:00:10 +0000

On Solana, programs are stateless. If your program needs to remember something per user, per game, or per configuration, it needs a deterministic address it can find again later without storing it anywhere. PDAs are that address.

What a PDA actually is

In Web2, a database primary key is computed from a row's logical identity — user_id, order_id, something the system already knows. You never look up a row by a random UUID you can't derive. PDAs work the same way, 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.

Unlike a primary key, a PDA is not stored in a table. It's derived on demand and may or may not have an account at that address yet. The program doesn't know if the account exists until it tries to read it. That's why init and init_if_needed exist.

Anatomy of a derivation

Here's the canonical pattern from my counter program:

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

The seeds array is the core of PDA derivation. It contains two parts: a static seed prefix b"counter" and a dynamic seed user.key().as_ref(). The static seed creates a namespace — all counters share this prefix. The dynamic seed separates one user's counter from another's.

The bump is the byte that makes the address off-curve. Anchor computes it during derivation and stores it on the account. The init constraint tells Anchor to create the account at the derived address. payer = user says the user pays the rent. space reserves enough bytes for the account data.

Why the seeds matter

The seeds you choose determine who can access what. In my counter program, I used [b"counter", user.key().as_ref()]. This gives every wallet its own PDA. If I had used only [b"counter"], every wallet would get the same PDA — which is useful for a global config but disastrous for a per-user counter.

I tested this on Day 68. The per-user derivation gave different addresses for different wallets. The global derivation gave the same address for every wallet. Same program ID, same derivation function, different seeds.

Per-user counter PDAs:
  Wallet A PDA: 3ZQj5KhoHaoDb9g1LoFpDZ5tAxMwA4ZumnUzrxmMPFfg
  Wallet B PDA: DgfkXgoFoHDRUGKiHvduDHrjuofRJKoFyJ13SqWqMgFs
  Same address? false

Global counter PDA (no wallet in seeds):
  Derived from A: 2ESHd2ZG3Yjh3kUZdSLGhweaVPfLaqs1qqqF4Hgh4Ndn
  Derived from B: 2ESHd2ZG3Yjh3kUZdSLGhweaVPfLaqs1qqqF4Hgh4Ndn
  Same address? true

What the bump buys you

The canonical bump is the first bump value that produces an off-curve address. find_program_address returns it along with the PDA. Anchor stores it for you when you write bump in the constraint.

You should re-pass the stored bump on subsequent instructions rather than re-deriving every time. Re-derivation is expensive (it hashes the seeds with 256 possible bump values). Storing the bump is free — it's just one byte on the account.

The full lifecycle

Over the course of this arc, I walked through the entire lifecycle of a PDA account:

Derive the address — Use find_program_address with seeds and program ID. No account exists yet, just the address.
Initialize the account — Use init in the accounts struct. This creates the account at the PDA, pays rent from the user, and stores the bump.
Mutate the data — Call instructions like increment. The seeds constraint re-derives the address and verifies it matches the passed account.
Close the account — Use close = user to drain lamports back to the user and mark the account as closed.

Closing is not "delete from a table." It's zero the data, transfer the lamports, and mark it for garbage collection at the end of the transaction. The runtime removes it from the next slot's account state.

What I would tell past me

A few things I wish I had known on Day 64:

The program ID is part of the derivation. The same seeds in a different program produce a different address. This is why PDAs are program-specific.
PDAs cannot sign transactions on their own. Only programs can sign on their behalf using the same seeds. The program signs for the PDA, not the other way around.
init_if_needed is convenient and also a footgun. Use it deliberately when you want idempotent creation, not by default. If you use it everywhere, you lose the ability to know whether an account was just created or already existed.
The bump is not optional. Without it, you can't re-derive the address. Store it on the account and pass it back on every instruction that uses the PDA.

Resources

PDAs are not complicated. They are deterministic addresses derived from seeds, a program ID, and a bump. They replace keypair tracking and let your program own state without a private key. The pattern is always the same: derive, initialize, mutate, close.

If you want to go deeper, start here:

Program Derived Addresses — the official Solana docs
PDAs in Anchor — Anchor's guide
Anchor crate docs — the source

My code is on GitHub.

My First Anchor Program: A Counter with Tests That Actually Catch Bugs

Mubarak Yakubu — Sun, 19 Jul 2026 17:33:46 +0000

I spent 3 days building a counter program on Solana. It does one thing — count. But the real value wasn't the program. It was the tests that proved it worked.

The accounts struct:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
    )]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

This struct defines what accounts the initialize instruction needs. The counter account is being created (init), the authority pays for it (payer) and becomes its owner, and the system_program is required because creating accounts is a System Program operation. The 8 + Counter::INIT_SPACE is 8 bytes for Anchor's discriminator plus the size of the Counter data.

The initialize handler:

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;
    counter.authority = ctx.accounts.authority.key();
    counter.count = 0;
    Ok(())
}

The handler is short. ctx.accounts gives you typed access to the accounts passed in. You set the authority to the wallet that signed the transaction, set count to 0 and return success. Anchor handles the rest.

The increment handler:

pub fn increment(ctx: Context<Increment>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;
    counter.count = counter.count
        .checked_add(1)
        .ok_or(ProgramError::ArithmeticOverflow)?;
    Ok(())
}

The increment handler adds 1 to the count. The checked_add prevents overflow — if the count hits u64 max, the transaction fails cleanly instead of panicking. The constraint in the accounts struct guarantees only the authority can call it.

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut, has_one = authority)]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

The has_one = authority constraint is where the security lives. Before the handler runs, Anchor checks that counter.authority matches the authority signing the transaction. If it doesn't, the transaction fails before your code executes. Declarative authorization — checked at the protocol level.

The happy-path test:

#[test]
fn initialize_then_increment() {
    let mut svm = LiteSVM::new();
    let program_id = counter::ID;
    let so_path = concat!(env!("CARGO_MANIFEST_DIR"), "/../../target/deploy/counter.so");
    svm.add_program_from_file(program_id, so_path).unwrap();

    let authority = Keypair::new();
    svm.airdrop(&authority.pubkey(), 1_000_000_000).unwrap();
    let counter_kp = Keypair::new();

    let init_ix = Instruction {
        program_id,
        accounts: counter::accounts::Initialize {
            counter: counter_kp.pubkey(),
            authority: authority.pubkey(),
            system_program: system_program::ID,
        }
        .to_account_metas(None),
        data: counter::instruction::Initialize {}.data(),
    };

    let tx = Transaction::new_signed_with_payer(&[init_ix], Some(&authority.pubkey()), &[&authority, &counter_kp], svm.latest_blockhash());
    svm.send_transaction(tx).unwrap();

    let inc_ix = Instruction {
        program_id,
        accounts: counter::accounts::Increment {
            counter: counter_kp.pubkey(),
            authority: authority.pubkey(),
        }
        .to_account_metas(None),
        data: counter::instruction::Increment {}.data(),
    };

    let tx = Transaction::new_signed_with_payer(&[inc_ix], Some(&authority.pubkey()), &[&authority], svm.latest_blockhash());
    svm.send_transaction(tx).unwrap();

    let account = svm.get_account(&counter_kp.pubkey()).unwrap();
    let parsed = counter::Counter::try_deserialize(&mut account.data.as_slice()).unwrap();
    assert_eq!(parsed.count, 1);
    assert_eq!(parsed.authority, authority.pubkey());
}

This test proves the program works: initialize creates a counter with count 0, increment changes it to 1, and the final state is exactly what we expect.

The failure test:

#[test]
fn increment_fails_when_wrong_authority_signs() {
    let (mut svm, program_id) = setup_svm_with_program();

    let authority_a = Keypair::new();
    let authority_b = Keypair::new();
    svm.airdrop(&authority_a.pubkey(), 1_000_000_000).unwrap();
    svm.airdrop(&authority_b.pubkey(), 1_000_000_000).unwrap();

    let counter = Keypair::new();

    let init_tx = build_initialize_tx(&svm, program_id, &authority_a, &counter);
    svm.send_transaction(init_tx).expect("initialize should succeed");

    let bad_tx = build_increment_tx(&svm, program_id, &authority_b, counter.pubkey());
    let result = svm.send_transaction(bad_tx);
    assert!(result.is_err(), "increment should fail when signed by the wrong authority");
}

This test proves the authorization works: authority_a creates the counter, authority_b tries to increment it, and the transaction fails.

Breaking it on purpose:
I planted a bug on purpose. I changed checked_add(1) to checked_add(2) in the increment handler. The happy-path test failed with:

assertion `left == right` failed
  left: 2
 right: 1

That's the test catching a real regression. Without that assertion, the program would silently store the wrong number and the suite would still be green. That's why the tests matter.

Next, I'd add more instructions — decrement, reset, maybe a way to transfer ownership. The pattern is the same: define the instruction, define the accounts, write the test, break it, fix it. The counter is just the first step.

What I Learned Minting NFTs on Solana with Token Extensions

Mubarak Yakubu — Fri, 03 Jul 2026 02:04:17 +0000

An NFT on Solana is just a token with supply 1, decimals 0 and metadata. Everything else is optional.

Before this week, I thought Solana NFTs required Metaplex. Turns out you can mint one with just the Token Extensions program, a GitHub Gist and a few CLI commands.

On Solana, an NFT is not a special type. It's a token mint with:

Decimals: 0 (can't be split)
Supply: 1 (only one exists)
Metadata extension (name, symbol, image URI)
Mint authority disabled (can't mint more)

That's it. The rest is metadata, collections, and off-chain JSON.

Everything else you see in wallets and marketplaces—images, attributes, collection pages—is built on top of this foundation.

Over three days, I minted:

A standalone NFT with metadata (name, symbol, image, attributes)
A collection mint with the Group extension (max size 3)
Two member NFTs linked to the collection via the Member extension

All on devnet. All with the Token-2022 program. No separate metadata program needed.

Here's how the collection + member flow works:

# Create collection mint with group extension
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 \
  --enable-metadata \
  --enable-group

# Initialize group with max size 3
spl-token initialize-group <COLLECTION_MINT> 3

# Create member mint with member extension
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 \
  --enable-metadata \
  --enable-member

# Link member to collection
spl-token initialize-member <MEMBER_MINT> <COLLECTION_MINT>

Metadata is mutable by default. The update authority can change name, symbol, URI and custom fields at any time.

This is useful for fixing errors. But it also means you trust the update authority not to rug you.

I mutated my NFT live on devnet:

# Update name
spl-token update-metadata <MINT> name "Field Notes"

# Add custom field
spl-token update-metadata <MINT> rarity legendary

# Remove custom field
spl-token update-metadata <MINT> rarity --remove

On-chain updates are instant. Off-chain image caching is not.

The name updated immediately in Solana Explorer. The new image may took longer to appear in Phantom. That asymmetry is something you have to design for.

What I'd build next

A complete NFT drop with a fixed collection size, automated minting, and on-chain royalties.

Token Extensions support transfer fees. Royalties can be enforced at the protocol level without a separate marketplace integration. No middleware. No trust. Just math.

The takeaway

Solana NFTs are not complicated. They're just tokens with a few extensions enabled.

Metaplex is one way to build them. Token Extensions is another. Both work. One is lighter, more composable, and lives entirely inside the mint account.

If you're coming from Web2, this might feel unfamiliar. But the mental shift is worth it.

Try it yourself. Mint one on devnet. Change its name. Add a custom field. Send it to a friend. The tools are all there.

This post is part of #100DaysOfSolana. Follow along or jump in any day.

Resources

solana.com

Official Solana documentation on token extensions and their use cases

solana.com
Technical reference for storing NFT metadata directly on mint accounts

solana.com
Official guide for building dynamic NFTs with on-chain metadata

SPL Tokens and Token Programs | Understanding Solana Tokens

Learn how SPL tokens work on Solana, including the Token Program, mint accounts, token accounts, and how Metaplex builds on top of the token standard.

metaplex.com
Comparison of original SPL Token, Token-2022, and Metaplex standards

You Already Understand Token Extensions.

Mubarak Yakubu — Mon, 22 Jun 2026 17:29:04 +0000

Because you've built payment flows, loyalty systems and credentials in Web2.

In Web2, charging a 1% transaction fee means building middleware. Verifying a user's identity before they can transact means writing KYC logic. Issuing a credential that can't be traded means designing a database with access controls.

On Solana, all of this is handled at the protocol level by Token Extensions.

What are Token Extensions?

Token Extensions are optional features you enable when creating a token mint. They're not separate smart contracts. They live in the same account as your token. Once enabled, the runtime enforces them.

There are two Token Programs on Solana:

Original Token Program (Tokenkeg...): Basic mint, transfer, burn
Token-2022 Program (TokenzQdBN...): Same basics, plus extensions

Extensions I used:

Transfer fee: Withholds a percentage on every transfer
Metadata: Stores name, symbol, URI on-chain
Default frozen: Every account starts locked
Non-transferable: Tokens cannot be moved (soulbound)
Permanent delegate: Issuer can burn tokens from any wallet
Interest-bearing: Display balance grows over time

A real example: Multi-extension token
One command, three extensions:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 2 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 500 \
  --interest-rate 5 \
  --enable-metadata

This creates a token with:

1% transfer fee (capped at 500 units)
Interest-bearing display balance
On-chain metadata

Then add metadata so wallets can display your token properly:

spl-token initialize-metadata <MINT> "ArcCoin" "ARC" "https://example.com/metadata.json"

Extensions cannot be added after mint creation. You have to declare everything upfront. In Web2, you'd add a feature later. On Solana, the account size is fixed at creation. No space for new extensions. Plan before you mint.

The word "permanent" in permanent delegate. I assumed it meant the address could never change. Tried to change it. It worked. "Permanent" means the authority to burn from any wallet, not an immutable address. Took me a failed assumption to learn that.

Token Extensions aren't separate smart contracts. They live in the mint account. When you create the mint, you're allocating space for extensions. The runtime handles the rest. No middleware, no backend, no bypass.

Token Extensions are how Solana handles real-world financial logic at the protocol level. Transfer fees, compliance gates, credentials, yield-bearing assets — all built in. You don't write the logic. You just enable the extension.

If you want to go deeper, start here:
Token Extensions Official Docs

Or just create a token on devnet and try one. That's what I did.

Transfer Fees, Metadata, and Soulbound Tokens: A Tour of Solana Token Extensions

Mubarak Yakubu — Wed, 17 Jun 2026 17:05:47 +0000

In Web2, adding a transfer fee means building middleware. On Solana, it's a flag. I built four tokens in six days. Here's what I learned.

A few weeks ago, I knew nothing about Solana tokens. I'd used Solana for transfers and read account data, but tokens felt like a black box. I wanted to understand how they actually work, not just copy-paste commands but know what each flag does and why it matters.

The Basic Mint

My first token was barebones. No name. No symbol. Just an address.

spl-token create-token
That's it. One command. A mint account appeared on devnet with a 9-decimal default.

I created a token account to hold it, then minted 100 tokens to myself.

spl-token create-account <MINT> spl-token mint <MINT> 100

What surprised me: You can't receive tokens directly into your wallet. You need a token account for each token type. One per token, per wallet.

The mint is the factory. The token account is your bucket.

Giving It an Identity

A token without metadata is just an address. Phantom would show a random string. No one would know what it is.

I needed a name, symbol and URI.

But the original Token Program (Tokenkeg...) doesn't support metadata on the mint itself. You'd need a separate account.

So I used Token Extensions Program (Token-2022) at TokenzQdBN.... It stores metadata directly on the mint.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 6

spl-token initialize-metadata <MINT> "100daysofsol" "100DSOL" <URI>

One mint. Multiple extensions possible. No separate accounts.

The URI points to a JSON file with description and image. Wallet UIs read it automatically.

Adding Transfer Fees

In Web2, charging a fee on every transaction means building middleware. Handling edge cases. Making sure no one bypasses it.

On Solana, it's a flag.

I used Token-2022 again, this time with --transfer-fee-basis-points.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 200 \
  --transfer-fee-maximum-fee 5000 \
  --enable-metadata \
  --decimals 9

100 basis points = 1%. I set 200 (2%) with a cap of 5000 displayed tokens.

Then I minted 1000, transferred 100 to a second wallet, and watched the fee get withheld.

spl-token transfer <MINT> 100 <RECIPIENT> --expected-fee 2

Recipient got 98. 2 tokens withheld in their token account. They couldn't touch it.

Only the withdrawal authority (me) could collect it.

spl-token withdraw-withheld-tokens <MY_ACCOUNT> <RECIPIENT_ACCOUNT>

I swept the fee back. Balance went from 900 to 902.

The fee logic lives in the mint. Every transfer respects it. No application code required.

Soulbound Tokens

Not all tokens should be transferable.

A course completion certificate. A KYC verification. An employee badge. They're credentials, not currency.

Token-2022 has an extension for this: --enable-non-transferable.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-non-transferable

I minted 10 tokens to myself. Then tried to transfer 5 to a second wallet.

It failed.
Program log: Transfer is disabled for this mint

The blockchain itself rejected the transaction. No client-side check. No middleware. Protocol-level enforcement.

But I could still burn them.

spl-token burn <ACCOUNT> 3

Balance went from 10 to 7. The holder can destroy tokens but cannot send them away.

This is how credentials should work on-chain. They prove something about the wallet that holds them. Trading them defeats the purpose.

What Surprised Me

What surprised me most: the protocol doesn't care about intent. It just enforces rules. When I tried to transfer a non-transferable token, the program rejected it without explanation beyond "Transfer is disabled." No appeal. No admin override. The rules are the rules.

What's Next

I've built tokens. Now I'm moving to programs.

I want to build something that does more than transfer value—something that enforces custom logic on-chain. A game. A marketplace. A DAO.

Follow along. I'm documenting everything.

Solana Accounts for Web2 Developers (You Already Understand Files)

Mubarak Yakubu — Mon, 08 Jun 2026 17:41:13 +0000

I spent the past month building on Solana. Sent transfers. Decoded raw bytes. Inspected accounts until my terminal turned into a wall of hex.

Along the way, I had to unlearn some Web2 habits.

One model. No exceptions.

Your wallet is an account. The program that moves your SOL is an account. The token you just bought? Also an account.

Solana doesn't have special types. Every account has the same five fields:

Lamports (SOL balance, 1 SOL = 1 billion lamports)
Data (raw bytes. empty for wallets)
Owner (the program that can modify this account)
Executable (true if this account holds code)
Rent epoch (ignore this. it's deprecated)

Run solana account on any address. Same structure every time.

$ solana account 8CtdyqtzBd597eDz9PTZHuuT62vvLc6YXdXjVkHnboqj

Public Key: 8CtdyqtzBd597eDz9PTZHuuT62vvLc6YXdXjVkHnboqj
Balance: 3.93896 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 18446744073709551615

Who owns what matters

The owner field determines control.

My wallet is owned by the System Program (111...111). Only the System Program can deduct SOL from it. I sign. The program executes.

A token account is owned by the Token Program. Only that program can move tokens.

In Web2, your app authorizes changes. On Solana, the program that owns the account authorizes changes. Your signature proves you approved it.

Programs have no memory

This was the hardest shift.

In Node.js, my app holds variables in memory. App and state live together.

On Solana, a program account holds code. Nothing else. No variables. No state.

State lives in separate data accounts.

A program reads from its data accounts, does math, writes back. It never stores anything itself.

// In Web2, you store state in variables
let counter = 5;
counter = counter + 1;

// On Solana, you read from a data account, modify, write back
const dataAccount = await fetchAccount(counterAddress);
let counter = dataAccount.value;
counter = counter + 1;
await writeAccount(counterAddress, counter);

Why? Update the program without losing data. One program, many data accounts. Programs stay pure.

The Token Program is 36 bytes of code. The mint accounts it controls? Separate accounts. Owned by the Token Program. Code in one place. State in another.

$ solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Public Key: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Owner: BPFLoaderUpgradeab1e11111111111111111111111
Executable: true
Length: 36 bytes

Rent isn't rent

Every account needs a minimum SOL balance based on data size. For a basic wallet with zero data: ~0.00089 SOL.

Pay once. Store forever. Close the account, get your SOL back.

It's a deposit. Not monthly rent.

You already know this

A file has a name, contents, and permissions.

A Solana account has an address, data, and an owner.

Same pattern. Different environment.

Took me a few weeks to stop overcomplicating it.

I Hit the 1,232-Byte Wall So You Don't Have To

Mubarak Yakubu — Mon, 25 May 2026 04:56:21 +0000

I was building a batch transfer tool. Send SOL to 20 recipients in one transaction. Simple, right?

Wrong.

The RPC rejected my transaction with: Transaction too large: 1400 > 1232

I had no idea what 1232 meant. Now I do.

The Limit

Every Solana transaction — transfer, swap, mint, everything — has a hard cap: 1,232 bytes.

Not 1,232 lines of code. 1,232 bytes

Where does 1,232 come from? IPv6 packet size. The internet requires every packet to be at least 1,280 bytes. Subtract 48 bytes for network headers. Leftover: 1,232 bytes.

Solana didn't choose this number. The internet did.

Why I Hit the Wall

My batch transfer had 22 accounts (sender + 20 recipients + system program). Each account key takes 32 bytes. 22 × 32 = 704 bytes just for the addresses.

Add signature (64 bytes), header (3 bytes), blockhash (32 bytes), instructions (variable). Total: ~1,148 bytes.

Dangerously close to 1,232. Add one more recipient? Fail. Add a memo? Fail. Add any complexity? Fail.

I was 84 bytes from the edge. That's one short sentence.

The Escape

I learned about Address Lookup Tables (ALTs).

An ALT is an on-chain account that stores addresses. Once stored, a transaction references them by a 1-byte index instead of the full 32-byte address.

Think of it like a URL shortener. You store the long URL once. Everyone else uses the short code.

Same concept.

What Changed

My batch transfer went from 22 full addresses to 1 ALT address + 21 one-byte indexes.

Before: 704 bytes for addresses
After: 32 bytes (ALT) + 21 bytes (indexes) = 53 bytes

My transaction size dropped from ~1,148 bytes to ~562 bytes.

Suddenly I had room. Add more recipients. Add a memo. Add error handling. All fit.

What I Learned

The 1,232-byte limit isn't arbitrary. It's Solana prioritizing network speed over developer convenience.

Fragmented packets are slower. Solana said no fragmentation. One packet. One transaction. Done.

This forces constraints:

List every account upfront

Batch operations need ALTs

Complex DeFi requires careful design

But the network stays fast. 4,000+ transactions per second fast.

DEV Community: Mubarak Yakubu

From Token Watcher to Program Builder: 100 Days of Solana

What I expected

The moment it clicked

What I understand now

What I built for the capstone

What I'd tell another developer

What comes next

From Prompt to Policy: How I Made a Solana Agent Safe Enough to Run Unattended

What it does

The inventory

The flow

The tools

Tool: get_balance

Tool: transfer_sol

The policy layer

Annotated run — Trial 1, goal met

Annotated run — Trial 2, policy denial

Lessons learned

Open questions

My Solana Program Launch Checklist

Phase 1: Pre-flight, on devnet

Phase 2: The deploy itself

Phase 3: Authority and verification

Phase 4: Frontend and going live

What surprised me

Resources

My Solana Program Security Checklist

1. Account Validation

2. Authority and Signer Checks

3. Arithmetic Safety

4. CPI Safety

5. Account Lifecycle

6. Pre-Deploy Hygiene

CPIs on Solana: From Confusion to Confidence

The mental model

A real code snippet

What tripped me up

Closing

Understanding Solana PDAs: A Web2 Developer's Guide

What a PDA actually is

Anatomy of a derivation

Why the seeds matter

What the bump buys you

The full lifecycle

What I would tell past me

Resources

My First Anchor Program: A Counter with Tests That Actually Catch Bugs

What I Learned Minting NFTs on Solana with Token Extensions

What I'd build next

The takeaway

Resources

SPL Tokens and Token Programs | Understanding Solana Tokens

You Already Understand Token Extensions.

What are Token Extensions?

Transfer Fees, Metadata, and Soulbound Tokens: A Tour of Solana Token Extensions

The Basic Mint

Giving It an Identity

Adding Transfer Fees

Soulbound Tokens

What Surprised Me

What's Next

Solana Accounts for Web2 Developers (You Already Understand Files)

One model. No exceptions.

Who owns what matters

Programs have no memory

Rent isn't rent

You already know this

I Hit the 1,232-Byte Wall So You Don't Have To

The Limit

Why I Hit the Wall

The Escape

What Changed

What I Learned

Tool: `get_balance`

Tool: `transfer_sol`