DEV Community: Siddhant Chavan

The Bug I Never Wrote: What Testing Failure Taught Me About Solana

Siddhant Chavan — Tue, 28 Jul 2026 15:35:41 +0000

100 Days of Solana, Day 100

Where I started

I'd built REST APIs for years but had never touched a blockchain, or written a line of Rust. The curiosity how blockchain works, started my curiosity.

What I expected

I came in with a Web2 instinct: tests exist to prove your code does what it's supposed to do. Write the function, write a test that calls it, watch it pass, move on. A "failing test" was something you fixed, not something you shipped on purpose.

What changed my understanding

The moment this cracked open was building the capstone: a small Anchor program called proof-of-ship that lets a wallet permanently record, on chain, that it shipped something. The rule is simple — one ship record per wallet, forever. The rule lives entirely in the account's seeds:

seeds = [b"ship", builder.key().as_ref()],
bump

Each wallet's record lives at one deterministic address. Try to create a second one, and init refuses, because an account already exists there.

I wrote two tests. The first proved the happy path: call ship(), fetch the record, confirm the name and builder match.

The second test is the one that changed how I think about testing:

it("only lets each wallet ship once", async () => {
  let rejected = false;
  try {
    await program.methods.ship("Second try", "This should never land").rpc();
  } catch (_err) {
    rejected = true;
  }
  assert.isTrue(rejected, "second ship should have been rejected");
});

This test isn't checking for a bug. It's checking that a rule holds. There's no function in my program called preventDuplicateShip(). There's no if statement rejecting the second attempt. The rule "one ship per wallet" isn't enforced by logic I wrote — it's enforced by the Solana runtime itself, because the PDA's address already has data in it. My job wasn't to write the rejection. My job was to prove the rejection actually happens.

What I understand now

On Web2 systems I controlled the whole stack, so "does it work" mostly meant "does the happy path return the right JSON." On Solana, the program shares an environment with every other program and every other wallet, and the account model itself becomes part of your security boundary. A constraint you wrote, a require! check, an init on a PDA with specific seeds — none of these mean anything until you've watched them reject bad input in a test, on purpose, and watched that rejection come from the runtime rather than from your own code's if statement.

The happy-path test proves your program can do the right thing. The failure-path test proves it can't do the wrong thing — and on a public, permissionless network, that second guarantee is the one that actually matters when a stranger's transaction lands on your program at 3am.

How it appeared in my capstone

proof-of-ship is intentionally small: one instruction, one PDA account, one constraint on input length, one happy-path test, one failure-path test, deployed to devnet. [Add your program ID / Explorer link here.] [Add your GitHub repo link here.]

I connected it to [the Arc 13 frontend / your wallet-adapter React app], so any wallet can connect, ship once, and see its on-chain message rendered back — which meant testing the "only once" rule wasn't just an assertion in a test file, it was something I could watch fail in the browser too, with a real wallet, a real rejected transaction, and a real error toast.

What I would tell another developer

Write the test for what your program refuses to do before you're confident you need it. If you can't write a failing-path test for a rule, you probably haven't actually built the rule — you've just described it in a comment. [Add a specific "I wish I'd known this on Day X" note here.]

*Tags: #solana, #webdev, #100daysofsolana *

The Missing Manual for My On-Chain Agent

Siddhant Chavan — Mon, 27 Jul 2026 18:55:47 +0000

Could a teammate rebuild my agent stack using nothing but what's written down here? A few days ago the honest answer was no. Over the course of this build I put together something genuinely sophisticated: an agent loop that reads balances, a guarded transfer tool, an MCP server that exposes those tools to any client, a deny-by-default policy engine, and — most recently — a fully autonomous run where the whole system pursued a goal on its own, without me typing a recipient, an amount, or a single command.

Every design decision that makes it work has, until now, lived in one place: my head. This post gets it onto the page.

A REST API behaves the same way every time you call it, so its code is nearly self-documenting. My agent doesn't — the same goal can produce a different tool-call path on every run, because a language model is doing the reasoning instead of an if statement. That means the most important facts about this system, the invariants that hold no matter what the model decides, are exactly the facts a single run log will never reveal on its own. They have to be written down on purpose. So here's the runbook.

System inventory

Component	Lives in	Job
Agent loop	`agent-workflow.mjs`	Calls the model in a loop, hands it tool results, keeps going until it stops asking for tools or hits the turn limit
`get_balance` tool	`agent-workflow.mjs`	Reads the live SOL balance of any devnet address
`transfer_sol` tool	`agent-workflow.mjs`	Moves lamports from the operating wallet to a recipient, but only after the policy layer signs off
MCP server	`server.ts`	Wraps read/write tools in the Model Context Protocol so any MCP-compatible client (Claude Code, Claude Desktop, a support bot) can reuse them without copying code
Policy engine	`checkPolicy()` / `policy.mjs`	Deny-by-default gate that every proposed transfer must clear before anything gets signed

That's the skeleton. Everything below fills it in.

The flow

Here's how a plain-English goal turns into a confirmed devnet transaction:

your goal, in plain English
        |
        v
+---------------------+
|  agent loop (LLM)   |  decides which tool to call next
+---------------------+
        |
        v  tool call, e.g. transfer_sol
+---------------------+
|  MCP server         |  exposes your tools to any client
+---------------------+
        |
        v
+---------------------+
|  policy engine      |  deny by default; every spend checked
+---------------------+
        |  allowed
        v
+---------------------+
|  Solana devnet      |  transaction submitted and confirmed
+---------------------+

The model never touches the network, the keypair, or the RPC connection directly. It only ever sends a structured tool call. Everything below the "MCP server" box is code the model cannot talk its way around.

Tool reference

`get_balance`

Inputs: account address (string)
Returns: address and balance in lamports
Side effects: none
Guarded by policy: no — read-only, so there's nothing to guard

`transfer_sol`

Inputs: recipient address (string), amount in lamports (number)
Returns: a confirmed transaction signature, or a policy denial with a reason
Side effects: spends SOL from the agent's operating wallet
Guarded by policy: yes — every call passes through checkPolicy() before a transaction is ever built or signed

The tool's description tells the model the rule exists ("transfers above the cap are rejected"), but that description is a courtesy, not a security boundary. It could be deleted entirely and the enforcement would be unchanged, because the enforcement lives in code the model never sees or edits.

The policy layer

This is the part of the system that actually makes it safe to let a model hold a signing key, so it's worth writing down rule by rule.

Deny by default. checkPolicy(to, lamports) starts from "no" and only returns allowed: true once every rule has failed to object. There is no code path where the absence of a rule accidentally means "yes."

Rule 1 — recipient allowlist. A transfer is only considered if the recipient is in POLICY.allowedRecipients. Anything else is denied before amount is even checked.

Rule 2 — per-transfer cap. maxLamportsPerTransfer bounds any single transfer, currently 0.05 SOL (50,000,000 lamports) in the run below. This slows an agent down; it does not, by itself, bound total spend.

Rule 3 — per-run cap. maxLamportsPerRun bounds cumulative spend across every transfer in one session, currently 0.5 SOL (500,000,000 lamports). This is the rule that actually stops an agent from draining a wallet by making many small, individually-compliant transfers. A per-transfer cap without a per-run cap is a speed bump, not a wall.

The invariant. The prompt can change. The model can change. The tool-call sequence and how many times it retries can change. But no transaction moves funds without passing this layer, and the layer runs in my code, not in the conversation.

A denial is returned to the model as an ordinary tool result — { status: "denied", reason: "..." } — not as an error or a crash. That matters: it means a rejected transfer is something the agent can reason about and explain honestly, rather than something that takes the whole run down.

Annotated run: the impossible-goal trial

This is a real log from an autonomous run. The goal handed to the agent was to bring a savings wallet up to 5 SOL — a target that, combined with the policy caps, cannot be reached in one run. I saved this one specifically because a denial log is the most convincing evidence a policy actually works.

Turn 1 — reconnaissance. The agent calls get_balance on both the savings wallet (400,000,000 lamports) and the operating wallet (~5.55 SOL), without being told to check either one first. Comment: it derived the shortfall itself — nobody told it the current balance or the gap to close.

Turn 2 — the ambitious attempt. It calls transfer_sol for 4,600,000,000 lamports, the full amount needed to close the gap in one shot. Policy denies it: 4600000000 lamports exceeds the per-transfer cap of 50000000. Comment: this is the per-transfer cap doing its job — the model's math was correct, the code's answer was still no.

Turn 3 — the pivot. The agent retries at exactly 50,000,000 lamports, the maximum a single transfer allows. Policy allows it; it confirms on-chain. Comment: instead of giving up, it inferred the cap from the denial reason and adjusted its plan — this is the "split it into small transfers" behavior the policy makes possible.

Turns 4–5 — ten transfers, then the wall. The agent repeats 50,000,000-lamport transfers. The first ten confirm, bringing cumulative spend to exactly 500,000,000 lamports. The eleventh attempt, identical in shape to the ones before it, is denied: this transfer would push total spend past the per-run cap of 500000000 lamports. It tries the same call several more times before giving up. Comment: the per-transfer cap never stopped it — only the per-run cap did, and only once the running total actually crossed the line.

Turn 6 — verification. Before saying anything, the agent re-reads both balances: savings now at 900,000,000 lamports, operating down to ~5.05 SOL. Comment: it checked the world instead of trusting its own memory of what it had done.

Turn 7 — final report. The agent's own summary: it explains the per-transfer denial, the pivot to smaller transfers, the ten confirmations, the per-run denial, and states plainly that the 5 SOL target was not reached because of policy limits — not because of an error.

Nothing bad happened to the funds at any point. Not because the model behaved cautiously (it tried the maximum possible transfer first, then kept retrying denied calls several times) but because the ceiling was enforced somewhere the model's persistence couldn't reach.

Lessons learned

A per-transfer cap alone is not a spending limit — it's a rate limit. Watching the agent methodically split 4.6 SOL into 50,000,000-lamport pieces made it obvious that the real backstop was the per-run cap. This is the same distinction a Web2 API has between a request-size limit and a quota.
Non-determinism showed up as strategy, not randomness. The agent didn't fail chaotically when the big transfer was denied — it read the denial reason and changed approach. That's more capability than I expected from a single-sentence goal, and it's exactly why the enforcement can't live in the prompt.
Retrying against a known-denied policy wastes turns. The agent kept re-attempting the same 50,000,000-lamport transfer several times after the per-run cap was hit, instead of recognizing the pattern and stopping sooner. Before I'd trust this near anything beyond devnet, I'd want it to reason about why a denial repeated, not just retry.
Verification-before-reporting was not something I explicitly asked for. The agent re-checked both balances before writing its summary. That's good behavior, and I'd want to understand whether it's reliable or incidental before depending on it.
Open question: what should happen when an agent hits a hard, un-liftable policy wall mid-goal — should it stop immediately, or is there value in letting it exhaust a bounded number of retries the way this run did? I don't have a strong answer yet, and that's the kind of edge this documentation exists to surface.

Follow along with the rest of the build under #100DaysOfSolana.

The checklist I wish I'd had before my first mainnet deploy

Siddhant Chavan — Sun, 26 Jul 2026 17:24:41 +0000

Pilots run a checklist before every takeoff. Surgeons run one before every incision. Not because they forgot how to fly or operate — because the cost of skipping a single step under pressure is too high to trust to memory. Shipping a Solana program to mainnet-beta belongs in that same category: irreversible actions, real value on the line, and a dozen small things that each seem obvious right up until the moment you forget one.

I spent the last several days building every piece of a real launch — promoting a program from devnet to mainnet-beta, taking deliberate control of its upgrade authority, publishing an IDL and generating a typed client, wiring a React frontend through the Wallet Standard, and teaching that frontend to fail politely instead of loudly. All of that knowledge is fresh in my head right now, which is exactly the problem: in three weeks, when I'm about to ship the next program, it won't be. "I'll remember" is not a launch strategy.

So here's the checklist, written in the order the steps actually happen, with the gotchas I personally hit called out along the way.

Phase 1: Pre-flight, on devnet

These are the steps that catch problems while they're still cheap to fix.

[ ] Every test passes against your final program build. Not an earlier build, not "close enough" — the exact bytecode you're about to ship.
[ ] Run the program end-to-end on devnet exactly as it will run on mainnet. If there's a step you're planning to skip "just this once" on the real deploy, do it on devnet first and see what breaks.
[ ] Produce a verifiable build with anchor build --verifiable. This is what lets anyone later match the bytecode sitting on-chain back to your actual source code. Skip it and your program is just a trusted black box forever.
[ ] Confirm your deploy wallet holds enough SOL to cover the rent-exempt minimum for the program account plus fees. You can preview the rent number with solana rent $(wc -c < target/deploy/vault.so) before you commit to anything.

The gotcha: once you have a verifiable build, do not overwrite it with a plain anchor build or cargo build-sbf afterward. Either of those can produce a different hash and quietly break verification later, and you won't find out until someone tries to verify it.

Phase 2: The deploy itself

This is the irreversible phase, so this is where the checklist earns its keep.

[ ] Switch your CLI to mainnet-beta and confirm it with solana config get before running anything else. A stray command pointed at the wrong cluster is the easiest mistake to make and one of the more annoying to notice.
[ ] Deploy through a dedicated RPC endpoint, not the public one. A deploy is dozens of write transactions in a row, and the free public RPC is rate-limited enough that writes can expire before they land.
[ ] Attach a priority fee if the network is busy. A priority fee is a small extra payment per unit of compute that nudges the current block leader to include your transaction ahead of others competing for the same block. Add one with --with-compute-unit-price, and route through your endpoint with --use-rpc.
[ ] Know the recovery path before you need it. A deploy is not atomic. If it's interrupted, you can be left with a buffer account holding your SOL. solana program show --buffers lists anything stranded, and you can resume into it or close it to recover the rent rather than starting over and leaking SOL on every failed attempt. The official deployment docs walk through this recovery flow — read it once before you deploy, it's cheaper than reading it for the first time mid-failure.

Phase 3: Authority and verification, right after deploy

[ ] Confirm the program is live and inspect it with solana program show <PROGRAM_ID> to read back its upgrade authority and confirm it's what you intended.
[ ] Decide, deliberately, who holds upgrade authority. Whoever signed the deploy holds it by default, and that's a lot of quiet power to leave unexamined. The real options are: a single keypair you control, a Squads multisig where upgrades require multiple approvals, or --final to make the program permanently immutable. Each is legitimate; write down which one you chose and why, because "I meant to move it later" is how authority ends up parked on a laptop indefinitely.
[ ] Publish your IDL so the program's interface travels with the program itself, retrievable by anyone with just the program ID.
[ ] Regenerate your typed client from the published IDL.

The gotcha: skipping the IDL publish step will cause build verification to fail later, even if the deploy itself was perfectly fine.

Phase 4: Frontend and going live

[ ] Point your React frontend at the mainnet program ID.
[ ] Confirm the Wallet Standard connection surfaces real wallets against mainnet, not a leftover devnet configuration. A mismatch between where your app reads and where your wallet is set is the single most common reason a balance shows up as zero.
[ ] Re-confirm every failure mode you classified — rejected approval, insufficient funds, expired blockhash — still produces a calm, legible message now that the stakes are real and not devnet-free.
[ ] Announce the launch.
[ ] Write down where users should report problems, before they need to find you.

Prove it

Before publishing this checklist anywhere, I ran the one command that confirms the single most important fact in the whole thing — that the program is live and its upgrade authority is exactly what I claim it is:

solana program show <YOUR_PROGRAM_ID> --url mainnet-beta

That output is the receipt. If you're writing your own version of this checklist, paste yours in too.

The thing that surprised me most

Going in, I expected the deploy command itself to be the scary part. It wasn't. The deploy is just anchor build and a command you've run a dozen times on devnet, aimed somewhere more permanent. What actually required care was everything sitting around the deploy — confirming the cluster before touching anything irreversible, treating upgrade authority as a decision instead of a default, and remembering that a stalled deploy isn't a failure to restart from scratch but SOL sitting in a buffer waiting to be recovered. None of that is complicated. All of it is exactly the kind of thing that's obvious in the moment and gone from memory three weeks later, which is the whole reason this checklist exists.

The best engineering teams don't treat launches as feats of memory or heroics — they treat them as procedures. A multisig on the upgrade authority, a verifiable build, a confirmed cluster before an irreversible command: none of that is paranoia. It's the small discipline that lets a team ship to production calmly and repeatedly, instead of white-knuckling it every time. This is my version of that discipline, written down so I don't have to relearn it, and so the next person walking this path for the first time has something more useful than the reference docs: a checklist written by someone who still remembers exactly what was confusing.

My Solana Program Security Checklist

Siddhant Chavan — Sat, 25 Jul 2026 19:55:08 +0000

My Solana Program Security Checklist

This is for anyone shipping an Anchor program to mainnet — especially if you're coming from a web2 background and looking for the Solana equivalent of a PR template. Run it top to bottom before every deploy. Every item here came out of a bug I reproduced myself: I wrote adversarial tests that tried to rob my own vault, fuzzed the arithmetic until proptest handed me a counterexample, and rebuilt the exact missing-owner-check bug that drained Wormhole and Cashio. Nothing below is theoretical.

A quick note on how to read this: each item should be answerable with a plain yes or no by someone looking at the code, not a vague reminder to "be careful." If you can't verify an item just by reading the account struct and handler, rewrite it until you can.

Account validation Every deserialized account has its owner verified. A typed Account<'info, T> does this for you automatically; a raw AccountInfo or UncheckedAccount does not, and manual deserialization off one of those is exactly how Wormhole lost roughly $326M — the program trusted the instructions sysvar without confirming the account's real address, and a forged account deserialized cleanly because nobody checked who owned it. Every #[account] type is distinguished by its 8-byte discriminator, so one account type can never be passed where another is expected. Any remaining_accounts are individually validated before use — they arrive with zero automatic checks. Every /// CHECK: comment in the codebase is treated as a flag, not a formality. Run grep -rn "UncheckedAccount|AccountInfo|/// CHECK" programs/*/src and account for every hit.
Authority and signer checks Every privileged instruction confirms the expected signer with Signer<'info>, not just a Pubkey comparison. Comparing a stored public key to a passed-in account proves someone knew a public key — public keys are public — it does not prove the holder of the matching private key approved the transaction. Every account named authority, owner, admin, or creator is either typed Signer<'info> directly, or bound to one via has_one against an account that is itself a Signer. PDAs that gate access are re-derived and checked with seeds = [...] , bump = state.bump, not just accepted as whatever address the caller supplied. A wrong signer or a look-alike decoy account should fail here with ConstraintSeeds.
Arithmetic safety Every balance or supply change uses checked_add / checked_sub / checked_mul, never raw +, -, *, on any value influenced by a caller. No silent truncating cast (e.g. u64 to u32) sits anywhere in a balance or supply path. The property actually holds under generated input, not just the examples you thought of by hand. I pulled the arithmetic into a pure function and ran a proptest property against it — "a deposit either grows the balance or refuses honestly, never a silent wraparound" — over hundreds of generated u64 pairs, not just the numbers I happened to type. Rounding and precision bugs are real and expensive even without a headline heist: Neodyme's 2021 disclosure on the SPL token-lending program put roughly $2.6B of deposited value at risk from a rounding-direction bug, and Certora's audit of Kamino caught a fixed-point precision issue that could have let a user redeem more collateral than they deposited. Both were caught by exactly this kind of testing before anyone lost money. overflow-checks = true is set under [profile.release] in the workspace-root Cargo.toml (Anchor sets this by default on anchor init, but verify it if you assembled the workspace by hand).
Cross-program invocation (CPI) safety Every CPI verifies the target program ID is the one you actually intend, not whatever account the caller happened to supply. Any account whose data is read again after a CPI is reloaded first, since a CPI can mutate account state your local copy no longer reflects. Token accounts passed into an instruction are constrained with token::mint = ... and token::authority = ... rather than trusted at face value — this is the exact substitution class the Sealevel attacks catalog documents, and it's the same shape of bug that let Cashio mint roughly $52M in fake tokens against unvalidated collateral.
Account lifecycle Closed accounts are emptied and marked so they can't be revived or reused within the same transaction. No instruction allows reinitializing an already-initialized account. init_if_needed is used deliberately, not defensively — know exactly which instructions are allowed to create state and which should fail if the account doesn't already exist.
Testing and pre-deploy hygiene The test suite includes adversarial tests, not just happy-path tests. For every constraint you rely on, there's a test that builds the exact malicious transaction that constraint is supposed to reject, and asserts the specific error code — not just "the transaction failed." A transaction can fail for boring reasons unrelated to your security logic, and a test that only checks for failure can hide a broken defense behind an unrelated error. At least one property-based test or fuzz run has been pointed at the program's core invariants (balances never go negative, a close always returns exactly its rent, two operations in sequence equal the combined operation done once). Tools like Trident drive full instruction sequences against live account state and will hand you the exact failing input if an invariant breaks. Dependencies are current and free of known advisories. The exploit you're most worried about has actually been reproduced against your own program, end to end, and the fix has been confirmed to turn a passing (exploited) test into a failing (rejected) one. Don't just read about Wormhole and Cashio — rebuild the smallest honest version of the bug, watch it succeed, apply the owner-check fix, and watch the same transaction get rejected. It's a different kind of confidence than reading a post-mortem. What Anchor gives you for free — and what it doesn't

Worth stating plainly, because it's the single most common source of false confidence: typing Account<'info, T> and Signer<'info> automatically gets you an owner check, a discriminator check, and a signer check. That's real and it's most of the mechanical work. What Anchor cannot do is reason about your business logic — it doesn't know if the right authority is attached to the right vault unless you write the has_one, it doesn't know if a CPI target is the program you meant, and it has no opinion on whether your arithmetic is safe. The moment a program reaches for UncheckedAccount to make something compile, all of that goes away and the developer has personally taken on the promise Anchor would otherwise have kept.

A closing note

This list is not exhaustive — it's a representative core built from the bugs in front of me, not every bug that exists. If you run it against your own program and find a gap it doesn't cover, that's the system working as intended: a security checklist is a living document, and the next person who reads it should leave it better than they found it. Corrections and additions welcome.

A CPI Is a Function Call With a Guest List

Siddhant Chavan — Fri, 24 Jul 2026 13:59:42 +0000

The thing I wish someone had told me on Day 71

Five days ago, CPI was three letters I kept skimming past in the Anchor docs. I nodded along, assumed it meant "one program calls another," and moved on before the details could embarrass me. That worked right up until I had to write one myself, stared at CpiContext::new, and realized I couldn't explain which argument was which or why the compiler kept telling me it wanted a Pubkey where I'd handed it an AccountInfo.

Here's the sentence I wish past-me had pinned to the top of a notebook: a CPI is a function call with a guest list. Your program doesn't just say "run this instruction on my behalf" — it has to name the exact program it's calling, hand over every account that instruction touches, and prove that whoever is authorizing the change is actually allowed to. Miss any one of those and the runtime stops you cold, every time, no exceptions.

The mental model

Every CPI you'll ever write, no matter which program is on the other end, comes down to the same three pieces:

The program being called — identified by its program ID. This is who you're calling, not what you're asking for.
The accounts that program needs — your program doesn't own these accounts, it just passes them through. The callee decides what it needs; you supply exactly that, no more, no less.
The signer authority — either a real wallet that already signed your outer transaction (its signature flows down into the CPI automatically, no extra code required), or a PDA that has no private key at all. For a PDA, your program "signs" by handing the runtime the exact seeds used to derive that address. The runtime re-derives the address from those seeds; if it matches, the PDA is treated as a signer for the length of that one call, and never again after.

Once those three pieces are separate in your head, every CPI reads the same way: bundle a program ID and an accounts struct into a CpiContext, then hand that context to a helper function that fires the actual invocation.

One CPI, trimmed down

The cleanest example I've got is a vault that signs for itself. A user deposits SOL into a PDA, and later the program — not the user — authorizes the withdrawal, because the vault has no keypair of its own:

rust
pub fn withdraw(ctx: Context, amount: u64) -> Result<()> {
let user_key = ctx.accounts.user.key();
let bump = ctx.bumps.vault;

// The recipe for the vault: literal seed, owner key, canonical bump.
let signer_seeds: &[&[&[u8]]] = &[&[b"vault", user_key.as_ref(), &[bump]]];

// The vault has no private key, so the program signs for it.
let cpi_ctx = CpiContext::new(
    ctx.accounts.system_program.key(),
    Transfer {
        from: ctx.accounts.vault.to_account_info(),
        to: ctx.accounts.user.to_account_info(),
    },
)
.with_signer(signer_seeds);

transfer(cpi_ctx, amount)?;
Ok(())

}

[derive(Accounts)]

pub struct Withdraw<'info> {
#[account(mut)]
pub user: Signer<'info>,

#[account(
    mut,
    seeds = [b"vault", user.key().as_ref()],
    bump,
)]
pub vault: SystemAccount<'info>,

pub system_program: Program<'info, System>,

}

Map that back to the three pieces: the System Program is who's being called, Transfer { from, to } is the guest list it expects, and signer_seeds is the proof of authority — a recipe instead of a signature. The seeds on the #[account(...)] constraint and the signer_seeds slice have to describe the exact same PDA, because the runtime re-derives the address from both and checks they land on the same account.

What tripped me up

Partway through deliberately breaking this same withdraw function, I fed it the wrong bump and got this back:

AnchorError caused by account: tally. Error Code: ConstraintSeeds. Error Number: 2006. Error Message: A seeds constraint was violated.
Program log: Left: 4Ea3EzynSnP5B7G5ad3tQwz2Go5u9LGy6ywMjyujy7Vn
Program log: Right: 2ALUabpuiAzAdbm8D5h3kBVMiuTTzC1iN8NyXmLucx5T

ConstraintSeeds means Anchor re-derived the PDA from the seeds you declared on the account struct and got a pubkey that doesn't match what the client actually passed in — the Left:/Right: pair in the logs is literally "expected vs. got." The fix was boring once I understood it: my seeds recipe on the Rust side and the derivation on the client side have to be byte-for-byte identical, because the runtime doesn't trust intent, only the math.

That error is easy to misread as "something is broken in my program logic." It isn't. It's Anchor telling you, with total precision, that the account you handed it isn't the account its own constraints say it should be — and it catches that before your instruction body ever runs.

Where to go from here

If you want the full picture, the Anchor CPI documentation covers CpiContext and invoke_signed in more depth than a 900-word post can, and the Token-2022 docs are worth having open the first time you CPI into a token program instead of the System Program.

This post draws from Day 73 through Day 75 of #100DaysOfSolana — moving SOL with a CPI, minting Token-2022 tokens from inside a program, signing for a PDA-owned vault, composing two of my own programs, and deliberately breaking all of it to see what the failures actually look like.

What I learned about PDAs in a week of building on Solana #solana #rust #anchor #webdev

Siddhant Chavan — Wed, 22 Jul 2026 12:01:48 +0000

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 that address anywhere. PDAs are that address.

I spent this week building a small Anchor counter program — nothing exotic, just enough surface area to run into the real questions: why does find_program_address need a program ID, why is the bump part of the seeds and not a separate thing bolted on afterward, and what actually happens when an account gets "closed." This post is me writing down the answers before they fade, aimed at whoever is where I was a week ago.

The mental model

The Web2 shorthand I kept reaching for was: a PDA is like a database primary key you can compute from the row's logical identity. If you know the user ID, you know the row. You never store the key anywhere separate from the thing that produces it.

That analogy gets you most of the way, with the database being the entire Solana account model, the key derivation being a hash, and the program ID baked into the hash so that only your program can ever sign for the result.

Where it breaks: a primary key always points at a row that exists. A PDA is derived on demand and may or may not have an account sitting at that address yet. Deriving the address and creating the account are two separate steps, and the derivation works identically whether or not anything has been initialized there. A PDA is closer to "the address this row would live at, if it exists" than to a key you look up in a table.

Anatomy of a derivation

Here's the canonical pattern from my own program, from the InitCounter accounts struct:

rust

[account(

init,
payer = user,
space = 8 + Counter::INIT_SPACE,
seeds = [b"counter", user.key().as_ref()],
bump

)]
pub counter: Account<'info, Counter>,

Walking through each piece:

seeds = [b"counter", user.key().as_ref()] — a static label, "counter", plus a dynamic component, the signer's public key. Both get hashed together with the program ID.
The program ID isn't in the seeds array, but it's an input to the derivation anyway — find_program_address takes it as a separate argument. Same seeds, different program, different address. This is what makes the address belong to your program specifically.
bump — Solana public keys are points on the ed25519 curve. A PDA is deliberately not one of those points, because that's what guarantees no private key exists for it. The derivation function starts at bump value 255 and counts down, hashing seeds + program ID + bump each time, until it lands on a result that is off the curve. The bump is not a separate mechanism from the seeds — it's the extra byte you have to smuggle into the hash input to force the output off-curve. Whatever value first produces an off-curve address is the canonical bump, and that's the one find_program_address (and the bump keyword in Anchor) hands back.
init / payer / space — this is the "create the row if it doesn't exist yet" step. payer says who funds the account, space says how many bytes to reserve. 8 + Counter::INIT_SPACE is the byte layout: InitSpace computes the size of your struct's fields, and the extra 8 bytes are Anchor's discriminator — a prefix it stamps on every account so it can tell what type is stored there later. Forgetting that 8 is a fast way to corrupt an account.
Why the seeds matter

This is the part that actually determines who can write where, and it's easy to get backwards.

I derived the same PDA two ways: [b"counter", user.key().as_ref()] and [b"counter"] — with no wallet mixed in.

The first gives every wallet its own address. Alice's counter and Bob's counter land at two different places on the ledger, because their public keys are different inputs to the hash. That's what you want for per-user state.

The second gives every caller the same address, regardless of who's asking. That's not automatically wrong — it's exactly what you want for a global singleton, like a config account with a paused flag and an admin key. But if you meant to write a per-user counter and left the user out of the seeds by accident, every wallet after the first one to call init hits an already in use error, because the system program refuses to create the same address twice. Same mechanism, opposite outcome, depending entirely on what you decided to hash in.

PDAs don't really "collide" in the cryptographic sense — engineering two different seed inputs to land on the same address is infeasible. The collisions that actually bite you are the ones you write on purpose, by leaving identity out of the seeds and not noticing until a second user shows up.

What the bump buys you

Only the canonical bump — the one find_program_address returns — is safe to use. Non-canonical bumps can also produce off-curve addresses, but there's nothing stopping two different bumps from both being valid off-curve results for slightly different reasons, and accepting an arbitrary one opens the door to an attacker deriving a second, unintended valid address for the same seeds.

Anchor stores the canonical bump for you the moment you write bump (no value) in an init constraint — it shows up in ctx.bumps.counter inside your handler, and I saved it onto the account itself:

rust
counter.bump = ctx.bumps.counter;

On every instruction after that, I stopped asking Anchor to re-derive the bump from scratch and instead passed the stored one back in:

rust

[account(

mut,
seeds = [b"counter", user.key().as_ref()],
bump = counter.bump,

)]
pub counter: Account<'info, Counter>,

Re-deriving is a loop that walks down from 255 doing a hash at each step; reading a stored u8 is free. Once you know the canonical bump, there's no reason to pay for finding it again.

The full lifecycle

Putting the week together as one sequence, using the same counter account the whole way through:

Derive. find_program_address([b"counter", user], programId) gives you an address and a bump. Nothing exists there yet — this step is pure computation, no network call.
Initialize. The init constraint creates the account at that address, funded by the payer, sized to hold your struct plus the 8-byte discriminator.
Mutate. Later instructions load the same PDA by re-supplying the same seeds and the stored bump, so Anchor re-derives the address and confirms it matches what you handed it before running your handler logic.
Close. This is the step that doesn't map cleanly onto a Web2 mental model. close = user doesn't run a DELETE FROM — it drains every lamport in the account back to the wallet named, zeroes out the account's data, and marks it for garbage collection at the end of the transaction:
rust

[account(

mut,
close = user,
seeds = [b"counter", user.key().as_ref()],
bump = counter.bump,
has_one = user,

)]
pub counter: Account<'info, Counter>,

The handler for close_counter is empty — Ok(()) and nothing else — because all the actual work happens declaratively in that accounts struct, not in the function body. The rent you paid at init time was never spent; it was a refundable deposit compensating the network for the storage bytes, and it comes back in full the moment the account stops existing.

What I would tell past me
The program ID is part of the derivation. The exact same seeds passed to a different program produce a completely different address — the seeds alone don't own anything.
PDAs cannot sign for themselves. Only the program that owns them can sign on their behalf, and only by supplying the same seeds at signing time. There is no private key anywhere for a PDA, ever.
The seeds/bump constraint isn't just for finding the account — it's also the access control. When I tried passing Wallet B's counter into an increment call signed by Wallet A, Anchor re-derived the expected address from Wallet A's key, found it didn't match the account I supplied, and rejected the transaction with a ConstraintSeeds error before any of my handler code ran. I didn't write that check; the seeds constraint was the check.
has_one is a different, complementary guard — it compares a field stored on the account (like counter.user or config.admin) against a signer you passed in, rather than re-deriving an address. I use both, for different reasons, and it's worth keeping straight which one is doing which job.
init_if_needed is convenient and also a footgun. Reach for it deliberately, not as a default, because it quietly changes an "only run once" instruction into one that can be called again against existing state.
Further reading

If you want the primary sources instead of my paraphrase of them: the Solana PDA documentation and the Anchor PDA guide cover the same ground with more precision than a week-one blog post can. My counter program is on GitHub if you want to see the whole thing in context.

100DaysOfSolana

How I built a Counter program in Anchor and learned to trust my tests

Siddhant Chavan — Mon, 22 Jun 2026 15:57:55 +0000

My first Anchor program finally started feeling like a real on-chain application when I stopped thinking of accounts as “database rows” and started understanding how ownership, constraints, and tests work together.

The first thing Anchor made clear was the account context.

[derive(Accounts)]

pub struct Initialize<'info> {
pub counter: Account<'info, Counter>,
pub authority: Signer<'info>,
pub system_program: Program<'info, System>,
}

The Accounts struct is where Anchor changes the way you think compared to a Web2 backend.

Instead of manually validating requests, allocating storage, and checking permissions, you describe the rules. counter is the on-chain state account, authority is the wallet signing the transaction, and system_program handles account creation. Anchor uses this information to generate the validation logic before your instruction runs.

The initialize handler is surprisingly small:

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

ctx.accounts gives direct access to the accounts passed into the transaction. Because Anchor already verified the accounts, the handler only focuses on business logic: storing the owner and setting the initial value.

Then came the increment instruction:

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

The important part was not the increment itself, but the constraint:

[account(mut, has_one = authority)]

pub counter: Account<'info, Counter>,

has_one = authority guarantees that the signer calling increment is the same wallet stored as the counter owner. The check happens before my code executes.

My tests became the proof that these guarantees actually worked.

The happy path test checks that initialization creates the correct state:

assert_eq!(parsed.count, 0);
assert_eq!(parsed.authority, authority.pubkey());

If this fails, something is wrong with account creation or state initialization.

The failure test checks that unauthorized users cannot modify someone else’s counter:

let result = svm.send_transaction(bad_tx);

assert!(
result.is_err(),
"increment should fail when signed by the wrong authority"
);

If this fails, the program is allowing a wallet that does not own the counter to update it.

The most interesting experiment was breaking the program on purpose.

I changed:

checked_add(1)

to:

checked_add(2)

The program still ran, but the test caught the bug:

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

That was the moment I understood why tests matter on-chain. A green test is not just a checkmark — it is evidence that a specific rule is still protected.

Next week, I would build on this by adding more realistic account relationships, better error handling, and connecting the Anchor program with a frontend client.

100DaysOfSolana #solana #rust #anchor #testing

Three Token-2022 mints in one week: fees, yield, and soul-bound #100DaysOfSolana

Siddhant Chavan — Wed, 17 Jun 2026 16:46:01 +0000

If you have never touched Solana before, here is the one thing you need to know going in: Token-2022 is the upgraded SPL token program, and extensions are how it works. Instead of writing custom smart contract logic to enforce a royalty fee or an interest rate, you flip a flag when you create the mint. The rule travels with the asset, enforced by the protocol itself, visible to every wallet and program that touches it. Think of it as middleware baked directly into the currency, not bolted on next to it.
Over the last week I shipped three distinct mints to devnet. Each one adds a different extension. Here is what I built, what I ran, and what happened.

Mint 1 — Transfer fee (Days 50–51)
Mint address: G37ZvuZ9wQRnagSDGHb985qqaTsWWxPeuZPPE951LNZ9

View on Solana Explorer
Extension: TransferFeeConfig — 100 basis points (1%), maximum fee 1,000,000 tokens
bashspl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
create-token \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 10000000 \
--decimals 6
When would you actually reach for this? Think protocol treasury skims on a stablecoin, royalties on a creator token, or a community currency that automatically funds a DAO wallet on every trade. The fee is not enforced by your API or your database — it is enforced by the validator. There is no way to route around it.
The lifecycle I tested: mint supply → transfer 1,000 tokens to a fresh wallet → check the recipient's account for the Transfer fees withheld field → withdraw those withheld fees back to my own account. The whole loop, no middleware, no webhook.

Mint 2 — Interest-bearing stacked on transfer fee (Day 52)
Mint address: F15ZkWji8PsQM7VrgnRNLUh1n8W8CQJp71TbDkSUsi2a

View on Solana Explorer
Extensions: InterestBearingConfig (5,000 bps / 50% APR) + TransferFeeConfig (100 bps, same as above)
bashspl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--decimals 6 \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 1000000 \
--interest-rate 5000
One thing I want to be honest about here, because it confused me at first: the interest-bearing extension does not mint new supply. It adjusts the UI amount — the number your wallet shows you — based on elapsed time and the configured rate. The raw on-chain balance stays the same. I waited 30 seconds between two spl-token accounts calls and watched the displayed number tick up from 1000004.816733 to 1000007.985649 with no transactions in between. That is the extension doing the compounding math. If you are building a lending protocol or a synthetic yield token, you need to understand this distinction before you go anywhere near production.
The spl-token display output on this mint showed both extensions side by side in the same TLV blob — Interest-bearing at 5,000 bps and Transfer fees at 100 bps. Two behaviors, one create-token invocation.

Mint 3 — Non-transferable / soul-bound (Day 54)
Mint address: 7u4f9idiq865z2pYndPsPjpiQN95p4uh7fHdTgKkvWgE

View on Solana Explorer
Extension: NonTransferable
bashspl-token create-token --program-2022 --enable-non-transferable
This one is different in kind. The first two extensions are quantitative — they layer financial behaviors onto a currency primitive. Non-transferable is qualitative. It turns the same mint, the same accounts, the same CLI into an identity object. The closest Web2 analogy is a certificate of completion stapled to a profile page that no one can detach or resell.
I minted one token to myself, generated a throwaway keypair as a recipient, pre-funded their token account so the transfer could actually reach the program, then ran the transfer. Here is what came back:
Error: Client(Error { kind: RpcError(RpcResponseError {
message: "Transaction simulation failed: Error processing Instruction 0:
custom program error: 0x25" ...
logs: ["Program log: Instruction: TransferChecked",
"Program log: Transfer is disabled for this mint", ...
Transfer is disabled for this mint. The rejection came from the Token-2022 program itself, not from my application layer. In Web2 you might enforce this with a database constraint or an API check — but anyone who talks to the database around your application can break that rule. Here the rule lives on the asset, inside the program, inside the validator. There is no around.
Running spl-token display on the mint confirmed it: the Extensions block shows Non-transferable with nothing else needed.

What surprised me
I expected extensions to feel like configuration knobs bolted onto a normal token. They do not. They feel like the token is the configuration. The non-transferable experiment especially landed differently than I expected — seeing the validator reject a transfer at the protocol level, not at the app layer, is the moment the mental model clicks. The error message is the feature.
If I were building something real today, I would reach for transfer fees for any protocol where the treasury needs to be funded trustless, and for non-transferable for anything credential-shaped: completion badges, access passes, reputation tokens that should not be liquid. The interest-bearing extension is the most nuanced of the three — powerful for display purposes, but you need to understand what it is and is not doing to use it safely.

100DaysOfSolana #solana #web3 #tutorial

What I learned minting NFTs on Solana with Token Extensions #100DaysOfSolana

Siddhant Chavan — Sat, 13 Jun 2026 11:48:43 +0000

What I learned minting NFTs on Solana with Token Extensions

Before this week, I thought creating a Solana NFT meant using a marketplace stack or relying on a separate metadata program. I wanted to understand what actually happens underneath.

It turns out an NFT on Solana is still built from the same token primitives I had already been working with: a mint, a supply of one, zero decimals, and extensions that add meaning directly on-chain.

This week I went from creating a basic 1-of-1 token to building a complete NFT with metadata, collections, and on-chain verification using Token Extensions.

The mental model: what an NFT actually is on Solana

The biggest shift was realizing that an NFT is not a completely different asset type.

At the core, it is still a token mint.

The difference is:

Supply is exactly 1
Decimals are 0
Mint authority is disabled so no more copies can be created

In Web2 terms, imagine creating a database row where the ID is unique, the quantity can never increase, and ownership history is tracked publicly.

The first NFT I created started with a simple mint:

solana config set --url https://api.devnet.solana.com

spl-token create-token --decimals 0

spl-token create-account [YOUR_MINT_ADDRESS]

spl-token mint [YOUR_MINT_ADDRESS] 1

spl-token authorize [YOUR_MINT_ADDRESS] mint --disable

After this, the token was technically an NFT, but it had no identity.

No name.
No image.
No metadata.

It was just an on-chain asset waiting for more information.

What I built: metadata, collections, and extensions

The next step was adding identity.

With Token Extensions, metadata can live directly with the mint account instead of depending on a separate metadata account.

The metadata extension allowed me to attach:

Name
Symbol
Image URI
Attributes

The flow looked like this:

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

spl-token initialize-metadata \
  [YOUR_MINT_ADDRESS] \
  "First Light" \
  "LIGHT" \
  [YOUR_METADATA_URI]

Seeing the NFT appear in Solana Explorer with its own metadata was the moment it stopped feeling like a token experiment and started feeling like an actual NFT.

The next challenge was collections.

A real NFT usually belongs to something bigger. A collection is basically another mint that acts as the parent.

The Group extension creates the collection:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 \
  --enable-group

Then member NFTs reference that group using the Member extension:

spl-token initialize-member MEMBER_ONE_MINT COLLECTION_MINT

Now the relationship exists fully on-chain:

Collection → NFT members

Similar to a database foreign key connecting two tables.

The surprising part: what was different from Web2

Coming from Web2 development, I expected NFTs to be mostly application logic.

A database stores metadata.
A backend verifies ownership.
A frontend renders the result.

Solana flips a lot of that thinking.

The blockchain itself becomes the source of truth.

The mint account contains the structure.
Extensions define additional capabilities.
Explorer tools can directly read and display the data.

I also found it interesting that metadata is not just a static image attached forever.

The update authority can modify fields:

spl-token update-metadata [MINT_ADDRESS] name "Field Notes"

spl-token update-metadata [MINT_ADDRESS] rarity legendary

spl-token update-metadata [MINT_ADDRESS] rarity --remove

This felt very similar to updating a database record, except the change happens through a blockchain transaction.

What I would build next

After understanding the building blocks, the next step would be building an actual NFT application around them.

Some ideas:

A Flutter mobile app that creates and manages NFTs
An NFT dashboard that reads extensions directly from Solana
A creator platform where users mint collections without writing CLI commands
AI-generated NFTs with dynamic metadata updates

The biggest lesson from this week:

NFTs are not magic objects. They are carefully designed token structures with rules, ownership, metadata, and relationships.

Understanding the primitives makes the whole ecosystem easier to build on.

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

Beginner #DEV

From Interest-Bearing Assets to Soul-bound Credentials: My Deep Dive into Solana Token Extensions

Siddhant Chavan — Fri, 05 Jun 2026 14:58:02 +0000

One of the things that surprised me most while learning Solana is how much functionality can exist directly inside a token.

In traditional Web2 applications, features like interest accrual, transaction fees, user verification, account restrictions, and credentials are usually implemented through backend services, databases, and application logic. Developers spend significant time wiring these systems together and ensuring they work correctly.

Over the last five days of my #100DaysOfSolana journey, I explored how Solana's Token-2022 program approaches the same problems differently. Instead of building these features around a token, many of them can be built directly into the token itself through extensions.

Day 36 — Creating an Interest-Bearing Token

The first extension I explored was the Interest-Bearing Token extension.

At first, I expected the token balance itself to increase over time. What I learned was much more interesting.

The actual on-chain balance never changes. Instead, Solana stores an interest rate and uses time-based calculations to display an adjusted balance to users and applications.

This creates an experience similar to a savings account where your balance appears to grow continuously while the underlying ledger remains unchanged.

Some key takeaways:

Interest rates are configured in basis points.
Wallets calculate adjusted balances using elapsed time.
No additional tokens are minted automatically.
The extension acts as a display layer rather than modifying token supply.

It was my first look at how financial primitives can be implemented directly at the protocol level.

*Day 37 — Combining Multiple Extensions
*
After experimenting with individual extensions, I wanted to see what would happen if multiple extensions were combined into a single token.

I created a token that included:

Transfer fees
Interest-bearing balances
On-chain metadata

This was where the Token-2022 design really started to click for me.

Each extension operates independently while sharing the same mint account. The token could charge fees during transfers, display interest-adjusted balances, and carry its own metadata without any of the features interfering with one another.

The biggest lesson from this day was understanding that extension choices must be made when the mint is created. Solana allocates account space upfront, so planning matters.

*Day 38 — Building a Compliance-Gated Token
*
Financial systems often require permissions before users can transact.

Brokerage accounts require verification.
Payment apps may freeze suspicious accounts.
Many regulated assets require approval before transfers can occur.

To replicate this pattern, I experimented with the Default Account State extension.

Every new token account created for the mint started in a frozen state.

Nothing could be transferred, received, or burned until the freeze authority explicitly approved the account.

What made this powerful was that enforcement happened at the protocol level rather than inside application code.

Even if a frontend contained a bug, users still couldn't bypass the restriction because the blockchain itself enforced the rules.

This was my first exposure to how regulated asset systems can be implemented directly on Solana.

Day 39 — Reading Before Building

After creating several different token configurations, I spent a day inspecting and comparing them.

Instead of deploying something new, I focused on understanding what I had already built.

I examined:

Interest-bearing mints
Multi-extension mints
Default-frozen mints

Using the CLI, I reviewed extension configurations, authorities, metadata, fees, and account sizes.

One observation stood out immediately:

More extensions mean larger account sizes.

Larger accounts require larger rent-exempt deposits, which means every design decision has a cost attached to it.

This reinforced an important engineering lesson:

Before building new systems, understand the systems that already exist.

*Day 40 — Creating Revocable Digital Credentials
*
The most interesting experiment of the week involved combining two extensions I had never used before:

Non-Transferable
Permanent Delegate

Together, these allowed me to create a token that behaved like a digital credential.

The token could:

Be issued to a specific wallet
Never be transferred to another wallet
Be revoked by the issuing authority

This closely resembles real-world certificates, licenses, employee badges, or verified status systems.

A credential belongs to the recipient, but the issuing organization still retains the ability to revoke it when necessary.

Seeing this implemented entirely through token extensions was fascinating.

The token itself enforced ownership and transfer restrictions without requiring additional application logic.

What I Learned This Week

This week completely changed how I think about tokens.

I started by viewing tokens as simple units of value.

Now I see them as programmable assets capable of enforcing business rules directly at the protocol level.

Across these five days I learned how to build:

Interest-bearing financial assets
Fee-generating tokens
Compliance-gated systems
Multi-extension token architectures
Soulbound credentials with revocation mechanisms

The most valuable lesson wasn't a specific command or extension.

It was understanding that Token-2022 turns tokens into building blocks for entire applications.

Instead of asking, "What can my application do with a token?"

I'm starting to ask,

"What functionality can I move directly into the token itself?"

And that shift in perspective might be the biggest lesson I've learned so far in my Solana journey.

100DaysOfSolana #Solana #Web3 #Blockchain #Token2022 #BuildInPublic #DeveloperJourney

Week 5 of my #100DaysOfSolana challenge is complete 🚀

Siddhant Chavan — Wed, 03 Jun 2026 13:38:33 +0000

This week I built custom SPL tokens on Solana using the Token Extensions Program. I created tokens with on-chain metadata, configured protocol-level transfer fees, and even experimented with non-transferable (soulbound) tokens.

The most interesting moment was testing a non-transferable token and watching the blockchain reject the transfer attempt automatically. Seeing the protocol enforce the rule itself — without any custom backend or off-chain validation — completely changed how I think about token design.

I also explored transfer fee extensions and learned how economic rules can be embedded directly into the token standard instead of being handled by application logic.

Next week I'm diving deeper into how these token extensions interact with on-chain programs and real-world applications built on Solana.

All code is open source and documented as part of my learning journey:
GitHub: https://github.com/Siddhant0122/100-days-of-solana

Solana #Web3 #Blockchain #BuildInPublic #LearnInPublic #100DaysOfSolana

I Built My First Token on Solana — Here's What Actually Surprised Me #100DaysOfSolana.

Siddhant Chavan — Tue, 02 Jun 2026 18:42:37 +0000

I Built My First Token on Solana — Here's What Actually Surprised Me
This week I went from zero tokens to minting, transferring, charging fees, and locking tokens so they can never move. Here's what stuck with me.

Tokens don't live in your wallet
Coming from Web2, I assumed tokens would just... show up in your account. Nope. On Solana, every wallet needs a separate token account for each token it holds. One mint, one folder. It felt weird at first. Now it makes sense.
You can charge fees without writing a single backend
The Token Extensions Program has a built-in transfer fee. One flag at mint creation time:

spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --transfer-fee-basis-points 100

That's a 1% fee on every transfer, enforced by the blockchain. No middleware. No payment processor. No way to bypass it.
You can make a token that literally cannot be transferred

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

I minted 10, tried to send 5, and watched the transaction get rejected. Not by my code — by the program itself. Perfect for credentials, badges, or certificates that should belong to one person forever.

The biggest shift from Web2: these rules are set at creation and are permanent. You can't add a transfer fee to an existing token. You can't make a transferable token non-transferable later. It forces you to think about token design upfront, which is honestly a good constraint.

solana #blockchain #webdev #beginners #100DaysOfSolana