DEV Community: Gopichand

CPI on Solana: The Mental Model I Wish I Had on Day 71

Gopichand — Thu, 02 Jul 2026 07:01:17 +0000

I stared at CpiContext::new(...) for a solid ten minutes on Day 71. I knew
the arguments existed. I had no idea what they meant. I copied working code,
ran the test, watched it go green, and moved on. Three days later a PDA-signed
withdraw blew up on me and I realised I had been cargo-culting the pattern
without actually understanding it.

Here is everything I wish someone had told me before I wrote a single line of CPI code.

The one sentence that unlocks all of it

A CPI is a function call with a guest list. You name the program you want to
call, you pass it the accounts it needs, and you prove who is allowed to sign.

Every line of CPI code is doing one of those three things.

What the three pieces actually are

The program being called

Every program on Solana lives at a public key. When you write
CpiContext::new(ctx.accounts.system_program.key(), ...), that first argument
is the on-chain address of the program you want to hand execution over to. You
are not importing a library. You are calling an address that holds executable
bytecode. Once that framing clicked for me, the rest of the pattern made sense.

The accounts it needs

The callee has its own #[derive(Accounts)] struct with expectations. Your job
as the caller is to satisfy those expectations by passing the right accounts
through. Anchor ships typed structs for common programs — Transfer { from, to }
for the System Program, MintTo { mint, to, authority } for Token-2022. You
pull those from your own ctx.accounts, fill in the struct, and bundle it into
a CpiContext.

The rule I missed on Day 71: every program you CPI into must appear as an
account in your own #[derive(Accounts)]. It is not enough to know the
address. You need pub system_program: Program<'info, System> in your struct
or Anchor will not compile.

Who is authorised to sign

There are exactly two cases.

Case one is a real user wallet. The user already signed the outer transaction
and the Solana runtime carries that authority down into every CPI automatically.
You write zero extra code.

Case two is a PDA. A PDA has no private key so it cannot sign the normal way.
Instead you re-supply the same seeds you used to derive the PDA. The runtime
re-derives the address from those seeds, checks it against the account you
passed, and if they match that counts as the signature. Seeds stand in for a
private key. That is the entire trick behind CpiContext::new_with_signer.

Day 71: The smallest possible CPI — SOL transfer to the System Program

This is the complete sol-mover handler from my repo. This is already as
small as a CPI gets.

use anchor_lang::prelude::*;
use anchor_lang::system_program::{transfer, Transfer};

declare_id!("2RuhecMfTQqGwfgEC47ca965VqGUbTGefypkSY5Re6ob");

#[program]
pub mod sol_mover {
    use super::*;

    pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {
        let cpi_accounts = Transfer {
            from: ctx.accounts.sender.to_account_info(),
            to: ctx.accounts.recipient.to_account_info(),
        };
        let cpi_context = CpiContext::new(
            ctx.accounts.system_program.key(),
            cpi_accounts,
        );
        transfer(cpi_context, amount)?;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct SolTransfer<'info> {
    #[account(mut)]
    pub sender: Signer<'info>,
    #[account(mut)]
    pub recipient: SystemAccount<'info>,
    pub system_program: Program<'info, System>,
}

Map it to the three pieces: system_program.key() is the program,
Transfer { from: sender, to: recipient } is the guest list, sender: Signer
is the authority — the user signed the outer transaction so the runtime forwards
it automatically.

Full source: day-71-sol-cpi

Day 72: The same pattern, different callee — Token-2022

Day 72 proved that CpiContext is callee-agnostic. Instead of calling the
System Program, this calls Token-2022's mint_to instruction. The struct
changes to MintTo { mint, to, authority } and the program account becomes
Interface<'info, TokenInterface> — which accepts both classic SPL Token and
Token-2022 at runtime without a code change.

use anchor_lang::prelude::*;
use anchor_spl::token_interface::{
    mint_to, Mint, MintTo, TokenAccount, TokenInterface,
};

#[program]
pub mod token_cpi {
    use super::*;

    pub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> {
        let cpi_accounts = MintTo {
            mint: ctx.accounts.mint.to_account_info(),
            to: ctx.accounts.token_account.to_account_info(),
            authority: ctx.accounts.authority.to_account_info(),
        };
        let cpi_ctx = CpiContext::new(
            ctx.accounts.token_program.to_account_info(),
            cpi_accounts,
        );
        mint_to(cpi_ctx, amount)?;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct MintTokens<'info> {
    #[account(mut)]
    pub mint: InterfaceAccount<'info, Mint>,
    #[account(mut)]
    pub token_account: InterfaceAccount<'info, TokenAccount>,
    pub authority: Signer<'info>,
    pub token_program: Interface<'info, TokenInterface>,
}

The test minted 1_000_000_000 base units and confirmed the balance.
Same CpiContext::new shape, different program and accounts struct.

Full source: day-72-token-cpi

Day 73: PDA-signed CPI — the vault withdraw

Day 73 introduced CpiContext::new_with_signer. The vault PDA holds SOL
and the program needs to sign for it without a private key. The only thing
that changes from Day 71 is new becomes new_with_signer and you pass
signer_seeds.

pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
    let user_key = ctx.accounts.user.key();
    let bump = ctx.bumps.vault;
    let signer_seeds: &[&[&[u8]]] = &[&[b"vault", user_key.as_ref(), &[bump]]];

    let cpi_ctx = CpiContext::new_with_signer(
        ctx.accounts.system_program.key(),
        Transfer {
            from: ctx.accounts.vault.to_account_info(),
            to: ctx.accounts.user.to_account_info(),
        },
        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>,
}

The seeds in signer_seeds and the seeds in #[account(seeds = [...])] must
match byte for byte. The bump comes from ctx.bumps.vault — Anchor finds the
canonical bump during account validation and stores it there. Never hardcode it.

Test output: vault balance after deposit was 500_000_000 lamports, vault
balance after withdraw was 0.

Full source: day-73-vault

Day 74: Program calling another program — compose-lab

Day 74 pushed the pattern one step further. Instead of calling a system
program, compose-lab calls another Anchor program I wrote called counter.
Anchor 1.0's declare_program! macro imports the callee's full type system
from its IDL — accounts structs, CPI modules, and program type — giving
compile-time safety with no raw instruction building.

counter/src/lib.rs (the callee)

use anchor_lang::prelude::*;

declare_id!("8GM63Fe2dFnGEhxhJLh162GJ4cSpWgb927uW6sd2vzbx");

#[program]
pub mod counter {
    use super::*;

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        ctx.accounts.tally.count += 1;
        msg!("counter is now {}", ctx.accounts.tally.count);
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub tally: Account<'info, Tally>,
}

#[account]
#[derive(InitSpace)]
pub struct Tally {
    pub count: u64,
}

compose-lab/src/lib.rs (the caller)

use anchor_lang::prelude::*;

declare_program!(counter);

use counter::{
    accounts::Tally,
    cpi::{self, accounts::Increment},
    program::Counter,
};

declare_id!("Gs4H4zaqUtRC1iPJhcvYxcQwpq4sakkHoiJBiRpCRALM");

#[program]
pub mod compose_lab {
    use super::*;

    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(())
    }
}

#[derive(Accounts)]
pub struct Bump<'info> {
    #[account(mut)]
    pub tally: Account<'info, Tally>,
    pub counter_program: Program<'info, Counter>,
}

Two independent programs composing atomically. If the CPI fails, the whole
outer transaction rolls back — no partial state. The caller never owns the
Tally account. It just passes it through. Ownership stays with counter.

Test output: counter value set by the caller: 1 — one passing test.

Full source: day-74-compose-lab

Day 75: The error that taught me the most

On Day 75 I deliberately broke three CPIs to learn how to read the logs.
The most useful failure was changing b"vault" to b"vaultX" in the
signer seeds on the Day 73 vault withdraw. My terminal printed:
Program log: AnchorError caused by account: vault.
Error Code: ConstraintSeeds
Error Number: 2006
Error Message: A seeds constraint was violated.

Program 11111111111111111111111111111111 invoke
Program 11111111111111111111111111111111 failed: privilege escalation

ConstraintSeeds is Anchor telling you the seeds you passed do not reproduce
the PDA it expects. The privilege escalation below it is the System Program
refusing to move lamports from an account you do not control. These two errors
arrive together every time this happens. Start by checking that every byte in
your signer_seeds matches the corresponding byte in your
#[account(seeds = [...])] attribute, including the bump, and that the bump
comes from ctx.bumps not a hardcoded value.

The three-category mental model I built from that session:

What you see	Where to look
`ConstraintSeeds` + `privilege escalation`	Seeds or bump mismatch in `signer_seeds`
`ConstraintHasOne` with an account name	Caller did not satisfy callee's `has_one` constraint
`invalid instruction data` from a wrong program	`CpiContext` is pointing at the wrong program ID

Full source: day-75-cpi-failures

The pattern is the same every time

After five days across four different callees the CpiContext shape never
changed. What changed was which accounts struct you fill in and whether you
use new or new_with_signer. That is the whole surface area of the API.

If you want the full picture from the official sources:

This post draws from Days 71 through 75 of my #100DaysOfSolana journey.
Day 71 was the first CPI to the System Program, Day 72 was Token-2022,
Day 73 was the PDA vault with a PDA-signed withdraw, Day 74 was one Anchor
program calling another via declare_program!, and Day 75 was breaking each
of those deliberately and reading the logs. All the code is at
github.com/gopichandchalla16/100-days-of-solana.

What I Learned About PDAs in a Week of Building on Solana

Gopichand — Sat, 27 Jun 2026 09:23:41 +0000

I spent five days building with PDAs on Solana — Day 64 through Day 68 of my #100DaysOfSolana challenge. By the end I had a working counter program, a config singleton, a close instruction that returned real lamports, and a seed collision experiment where Anchor rejected a spoofed transaction live in my terminal.

This post is the explainer I wish I had on Day 1. It is aimed at backend engineers who know databases but have never touched Solana.

All the code is real. Every terminal output below came from my actual runs.

The Problem PDAs Solve

On Solana, programs are stateless. They hold no memory between calls. Every time your program runs, it starts fresh.

So if your program needs to remember something — a user's score, a game state, a global config — it has to store that data in a separate account on-chain. And to find that account again later, it needs a deterministic address it can recompute without storing it anywhere.

PDAs are that address.

A Program Derived Address is a 32-byte public key that your program derives on demand from a set of seeds. Give it the same seeds tomorrow, six months from now, from any machine in the world, and you get the same address back. No lookup table. No database. Pure computation.

The Mental Model

Here is the Web2 analogy that finally made it click for me:

💡 A PDA is like a database primary key you compute from the row's logical identity — except the "database" is the entire Solana account model, and the program ID is baked into every key.

In a relational database you might write:

-- primary key computed from logical identity
SELECT * FROM accounts
WHERE program_id = 'my_program'
  AND user_id    = 'alice'
  AND namespace  = 'counter';

On Solana that becomes:

SHA256(
  "counter"                     ← static seed / namespace
  + alice_wallet_pubkey         ← dynamic seed / row identity
  + program_id                  ← always included automatically
  + "ProgramDerivedAddress"     ← Solana's magic suffix
)
→ 32-byte address

Where the analogy breaks — and you must know this:

PDAs are not rows in a table. The address exists mathematically before any account is created at it. Deriving and creating are two separate steps.
The program ID is baked in. Same seeds, different program → completely different address. Your seeds are never globally unique.
No private key can ever exist for a PDA. PDAs land off the Ed25519 elliptic curve on purpose. Only your program can authorize actions on their behalf.

Anatomy of a Derivation

Here is the exact Anchor constraint 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>,

`b"counter"` — the static seed prefix

A hardcoded byte string that acts as a namespace. It says: "this PDA belongs to the counter feature." If the same program also has a vault PDA, it uses b"vault" — different prefix, guaranteed no collision.

`user.key().as_ref()` — the dynamic seed

The wallet public key of whoever is calling the instruction. Including it means every wallet gets its own independent PDA. Alice's counter and Bob's counter will always be at different addresses.

What actually gets hashed

SHA256(seeds[0] + seeds[1] + ... + program_id + "ProgramDerivedAddress")

The program ID is always appended automatically. You never pass it manually.

`bump` — not magic, just one byte

This is the part that confused me most. The derivation needs to land off the Ed25519 curve, because on-curve addresses could theoretically have private keys.

But most SHA256 outputs land on the curve. So Solana iterates:

bump = 255 → hash → on curve?  ❌ try again
bump = 254 → hash → on curve?  ❌ try again
bump = 253 → hash → off curve? ✅ canonical bump found

The bump is simply the first value that produced a valid off-curve address. Anchor calls find_program_address automatically and stores the result when you write bump in the constraint.

Why the Seeds Matter: Every Byte Counts

Per-user PDAs: include the wallet pubkey

const [pdaA] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter"), walletA.publicKey.toBuffer()],
  programId
);
const [pdaB] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter"), walletB.publicKey.toBuffer()],
  programId
);

Terminal output:

Wallet A PDA : 6khGZheFP1Yn61p7VJmwQtPd5gc5S2BHru8nugJFBHXy
Wallet B PDA : EEwiF4AFLd5nEFgYJA6SN6bRQPEaH9kHj4a8GtkdkyJx
Same address?: false ✅

Two wallets, two completely separate accounts. Use this pattern for per-user counters, inventories, profiles — any data that belongs to one wallet.

Global singleton PDA: omit the wallet pubkey

const [globalPDA_fromA] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter")],
  programId
);
const [globalPDA_fromB] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter")],
  programId
);

Terminal output:

Derived from A: 4f9BPE2BaRMG7SH339sw6dTigKqGJdeSKrtfaiZJXhmc
Derived from B: 4f9BPE2BaRMG7SH339sw6dTigKqGJdeSKrtfaiZJXhmc
Same address?: true ✅

Same address from every wallet. Use this for a global config singleton — one account the whole program shares. My Day 66 config PDA used exactly this:

#[account(
    init,
    payer = admin,
    space = 8 + Config::INIT_SPACE,
    seeds = [b"config"],
    bump
)]
pub config: Account<'info, Config>,

Near-miss variants — one byte, totally different address

seeds = ["counter",   walletA]  →  6khGZheFP1Yn61p7VJmwQtPd5gc5S2BHru8nugJFBHXy
seeds = ["counters",  walletA]  →  A2EKGjtfrPaHWjfoBLaMVtMu7drnAnhUgRZAKh4PmRBa
seeds = ["counter\0", walletA]  →  FfcErcB7U2FkY3YJNiC5UbejQZ7wH8uUEasK6DBxUkkd
seeds = ["Counter",   walletA]  →  FuR4MUZVwDK5qrKA8dpxHH6PY5Xo4uhGSXQLbEeTLS64

One extra letter. One null byte. One capital C. Four completely different addresses. There is no "close enough" in PDA space. Your seeds are an exact hash input.

What the Bump Buys You

Always use the canonical bump

find_program_address tries bumps from 255 downward and returns the first one that works. That is the canonical bump — the only safe one to use, because it is deterministic. Everyone who derives this PDA will always get the same bump.

There is a lower-level function called create_program_address that lets you pass any bump. Do not use it unless you have a specific reason. If you pass the wrong bump, you silently derive a different address and the program rejects the account.

Store the bump once, re-pass it forever

#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub authority: Pubkey,
    pub count:     u64,
    pub bump:      u8,   // ← stored at init time, never re-derived
}

At init, Anchor stores the canonical bump:

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
    let counter       = &mut ctx.accounts.counter;
    counter.authority = ctx.accounts.user.key();
    counter.count     = 0;
    counter.bump      = ctx.bumps.counter;  // ← store it here
    Ok(())
}

On every subsequent instruction, re-pass the stored bump:

// ✅ Correct — reads 1 stored byte, free
#[account(
    mut,
    seeds = [b"counter", user.key().as_ref()],
    bump = counter.bump,
    has_one = authority,
)]
pub counter: Account<'info, Counter>,

// ❌ Avoid — Anchor re-runs find_program_address, loops up to 256 times
#[account(
    mut,
    seeds = [b"counter", user.key().as_ref()],
    bump,
)]
pub counter: Account<'info, Counter>,

The Full Lifecycle

Step 1 — Derive (off-chain, zero cost, no transaction)

const [counterPDA, bump] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter"), wallet.publicKey.toBuffer()],
  program.programId
);
// The address exists mathematically. No account at this address yet.

Step 2 — Init (creates the account on-chain, pays rent)

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

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

What is rent? On Solana, storing data on-chain requires a lamport deposit. A lamport is the smallest unit of SOL — 1 SOL equals 1,000,000,000 lamports. If an account holds enough lamports to cover ~2 years of storage, it is "rent-exempt" and lives forever. That deposit is fully yours — you get every lamport back when you close the account.

My counter account cost 1,231,920 lamports to create.

Step 3 — Mutate (update data, no new account creation)

pub fn increment(ctx: Context<Increment>) -> Result<()> {
    ctx.accounts.counter.count += 1;
    Ok(())
}

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

has_one = authority is Anchor shorthand that verifies counter.authority == ctx.accounts.authority.key() before any logic runs. No custom auth code needed.

Step 4 — Close (reclaim rent, mark for garbage collection)

#[derive(Accounts)]
pub struct CloseCounter<'info> {
    #[account(
        mut,
        seeds = [b"counter", user.key().as_ref()],
        bump = counter.bump,
        has_one = authority,
        close = authority      // zeroes data, transfers lamports back
    )]
    pub counter:   Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub user:      SystemAccount<'info>,
}

close is not DELETE FROM table. Here is exactly what happens at end of transaction:

Account data is zeroed
Lamport balance is transferred to authority
Account is marked for garbage collection by the runtime

The PDA address still exists mathematically. You could init a new account at the same address tomorrow. A closed-then-reopened account is called a reinitialization attack — Anchor's init constraint protects against it by checking the 8-byte account discriminator on every init.

Terminal output after close:

Counter closed ✅
Lamports returned : 1,231,920
getAccountInfo    : null

1,231,920 lamports back in my wallet. Real money returned from storage I no longer needed.

The Spoof Test: Where ConstraintSeeds Earns Its Name

On Day 68 I tried to pass Wallet B's counter PDA to a transaction signed by Wallet A:

// walletA is the signer
// pdaB is wallet B's counter — wrong PDA for this signer
await program.methods
  .increment()
  .accounts({
    counter:   pdaB,                  // ← attacker passes wrong PDA
    authority: walletA.publicKey,
  })
  .signers([walletA])
  .rpc();

Terminal output:

AnchorError caused by account: counter.
Error Code: ConstraintSeeds. Error Number: 2006.
Error Message: A seeds constraint was violated.

Here is exactly what Anchor did under the hood:

Instruction arrives: counter = pdaB, authority = walletA
Anchor re-derives: seeds = [b"counter", walletA.key()] → gets pdaA
pdaA ≠ pdaB → throws ConstraintSeeds immediately
My business logic never ran

You did not write that security check. Anchor did. The seeds are the access control.

What I Would Tell Past Me

🔑 The program ID is always part of the derivation.
Same seeds in a different program → completely different PDA. Your seeds are only unique within your specific program. This is a feature — it means no other program can collide with your PDAs.

🔑 PDAs cannot sign transactions on their own.
They have no private key by design. Only programs can sign on a PDA's behalf by passing signer_seeds to invoke_signed. If you ever need a PDA to transfer lamports or call another program, this is the mechanism.

🔑 Always store and re-pass the canonical bump.
Find it once at init with ctx.bumps.counter, store it as a u8 in your account struct, and pass bump = counter.bump on every subsequent instruction. Re-derivation loops up to 256 times. Reading one stored byte is free.

🔑 init_if_needed is a footgun.
It is convenient for accounts that should be created on first use. But if an attacker can trigger it after you expect the account to exist, they can reset your state. Only reach for it deliberately, with extra constraints guarding against reinitialisation.

🔑 Closing is not deleting.
The PDA address is a derivation — it always exists mathematically. close returns the lamports and zeroes the data, but the address is re-derivable forever. Build your program assuming a closed account can be reopened.

Resources and Code

Everything I cited in this post is verifiable:

Solana PDA documentation — canonical explanation of off-curve derivation and find_program_address
Anchor PDA guide — constraints, bump storage, init_if_needed, close
anchor-lang crate docs — full API reference

My code from this week — all five days, live on GitHub:

Day	Topic	Link
Day 64	Derive PDA	day-64-derive-pda
Day 65	PDA Counter	day-65-pda-counter
Day 66	Config PDA	day-66-config-pda
Day 67	Close PDA	day-67-close-pda
Day 68	PDA Collision Explorer	day-68-pda-collisions

Full repo: github.com/gopichandchalla16/100-days-of-solana

This is Day 69 of my #100DaysOfSolana build log. If something here is wrong or unclear, tell me in the comments — I am still learning and I will fix it.

How I Built a Counter Program in Anchor and Learned to Trust My Tests

Gopichand — Sat, 20 Jun 2026 05:53:59 +0000

I spent Days 57–61 building the same counter program over and over.
Not because I kept breaking it (well, I did), but because each day
revealed something about Anchor that the previous day's green tests
had been quietly hiding.

This is that story.

The Accounts Struct — Where Anchor Earns Its Name

Every Anchor instruction starts with an accounts struct. Here's mine
for Initialize:

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

Three fields, three jobs:

counter — the new on-chain account being created. Anchor's init constraint handles the create_account CPI to the System Program automatically. space = 8 + 40 is the discriminator (8 bytes) plus the actual struct data (40 bytes).
authority — the wallet paying for the account and signing the transaction. mut is required because its lamport balance will decrease.
system_program — Solana requires you to pass the System Program explicitly whenever you're creating accounts. Nothing happens if it's missing — the transaction just fails.

Coming from backend development, this was the first thing that
genuinely surprised me. In Web2 you pass data to a function. In
Anchor you first declare every account your instruction will touch,
with its permissions, and Anchor verifies all of it before your
handler code runs even one line.

The Handlers — Short by Design

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

ctx.accounts gives you typed, validated access to every account
declared in the struct above. The handler is three lines because
Anchor already did the hard work — account creation, lamport
deduction, ownership checks — before this function was called.

Now increment:

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

And its accounts struct:

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

has_one = authority is the constraint that does the real work.
Before increment runs, Anchor checks that counter.authority == authority.key(). If a different wallet signs, the transaction
reverts with ConstraintHasOne (Error 2001) before a single line
of my handler executes. The constraint is a pre-condition, not a
runtime check I have to write myself.

The Tests — Two Paths That Matter

Happy path:

#[test]
fn initialize_then_increment() {
    // ... setup ...
    let res = svm.send_transaction(increment_tx);
    assert!(res.is_ok());
    let counter: Counter = svm.get_account_data(&counter_kp.pubkey());
    assert_eq!(counter.count, 1);
}

What would have to go wrong for this to fail? The increment
handler would have to not add 1 — either wrong arithmetic, a
missing account write-back, or a serialization error.

Failure path — wrong authority:

#[test]
fn increment_fails_when_wrong_authority_signs() {
    // wrong_wallet is a fresh keypair, not the counter's authority
    let res = svm.send_transaction(bad_tx);
    assert!(res.is_err(), "increment should fail when signed by wrong authority");
}

What would have to go wrong for this to fail? The has_one
constraint would have to be missing or wrong. Without it, any
wallet could increment anyone's counter — which is exactly the
exploit this test exists to prevent.

Day 61 — Mutation Testing: Proving the Tests Are Real

Green tests don't prove your code is correct. They prove your code
satisfies your tests. Those are different things if your tests are
wrong.

So on Day 61 I intentionally broke the program three ways and
watched the test suite respond.

Bug 2: I changed checked_add(1) to checked_add(2)

// Before
counter.count = counter.count.checked_add(1).ok_or(ErrorCode::Overflow)?;

// After (intentional bug)
counter.count = counter.count.checked_add(2).ok_or(ErrorCode::Overflow)?;

Test output:
thread 'initialize_then_increment' panicked at programs/counter/tests/counter.rs:97:5:
assertion left == right failed
left: 2
right: 1

The test caught it immediately. The assertion assert_eq!(counter.count, 1) exists precisely because of off-by-one errors like this. Before this experiment I had pattern-matched that assertion from a tutorial. After the experiment I understood why it has to be exactly 1 and not "nonzero" or "greater than 0."

I ran git restore and all three tests went green again.

What Writing This Revealed

The has_one constraint took me three drafts to explain cleanly.
I had been thinking of it as "check the authority" — vague enough
that I couldn't have told you exactly when it runs or what it
compares. Writing forced precision: it compares counter.authority
(stored on-chain at init time) against the authority account
passed in at increment time, and it runs before the handler, not
inside it.

That distinction — constraint vs. runtime check — is the thing
I would have gotten wrong in a code review before this week.

What's Next

Week 10 will push past single-account programs. I want to build
something with multiple accounts interacting — a vault, an escrow,
or a simple DEX instruction — where the account constraints do
more than guard a single field. That's where I expect the next
gap to show up.

→ Full code on GitHub

Day 62 of 100. Building daily.

Three Token-2022 Mints in One Week: Fees, Yield, and Soul-Bound

Gopichand — Fri, 12 Jun 2026 09:10:31 +0000

If you have built middleware in Web2, you already understand Token-2022 extensions.
The old SPL token program is like a plain Express router. Token-2022 is the same
router with a plugin system baked in. You opt a single mint into behaviors — fees,
interest, transfer locks — at creation time, and the protocol enforces them forever.
No forking, no custom Rust, no deploying your own program. Just flags.

I spent Days 50–54 of my #100DaysOfSolana challenge shipping three mints that each
demonstrate one of those behaviors. Here is what I built, the exact commands I ran,
and when you would actually reach for each extension.

Mint 1 — Transfer Fee (Days 50 & 51)

Mint: HxDYFvcXnLuy4VdxXCooUXrch8DZW34oUteQ6N2EFxEr
Explorer: View on Devnet
Extension: TransferFeeConfig

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 6 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000

--transfer-fee-basis-points 100 means 1% of every transfer is withheld before
the recipient gets credited. The withheld amount sits in the recipient's token
account until a privileged instruction sweeps it to the treasury.

When would you use this?
Creator royalties on a community token. A protocol fee on a stablecoin. A DAO
treasury skim that funds development every time the token changes hands. The key
insight: the fee is enforced by the Token-2022 program itself, not by your API.
Nobody can route around it by calling the program directly.

On Day 51 I ran the full lifecycle — transfer, inspect the withheld amount, then
sweep it back:

spl-token transfer $MINT 1000 $RECIPIENT --expected-fee 10
spl-token withdraw-withheld-tokens $MY_TA $RECIPIENT_TA

The --expected-fee 10 flag is a safety assertion. If the mint's fee math
doesn't produce exactly 10 tokens withheld, the instruction aborts. It is the
on-chain equivalent of an idempotency check.

Mint 2 — Transfer Fee + Interest Stacked (Day 52)

Mint: A6TAeNgxBVwYna8NqQVmBpQzjVYKoZA3e68yMvoVVUva
Explorer: View on Devnet
Extensions: TransferFeeConfig + InterestBearingConfig

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 6 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000 \
  --interest-rate 5000

One command, two TLV entries, two completely different mechanics.

What the interest extension does — and does NOT do:

This is the subtlety most tutorials skip. The InterestBearingConfig extension
does not mint new tokens. The raw amount stored on-chain never changes between
transactions. What changes is the UI amount — the number your wallet displays.

The formula is: UI amount = raw_amount × e^(rate × time_elapsed)

The network clock and the rate stored on the mint are all the CLI needs to compute
a growing display number every time you query. I proved this by reading the balance
twice with a 30-second sleep between them, with zero transactions in between:

spl-token accounts $MINT --verbose | awk 'NR==3'
sleep 30
spl-token accounts $MINT --verbose | awk 'NR==3'
# Output:
# 999032.271358
# 999032.762062   ← +0.49 tokens, no transaction fired

Think of it like a savings account display ticker. The number on screen grows.
The ledger entry does not change until a real transaction touches it.

Two extensions, zero conflict: TransferFeeConfig operates on raw amounts at
transfer time. InterestBearingConfig operates on the display layer at query time.
They are orthogonal, which is why they compose cleanly on a single mint.

Mint 3 — Non-Transferable / Soul-Bound (Day 54)

Mint: BQzJeZVZgkSvAYPj9f1M1apv56P7kggAgPNc9uSq7T5m
Explorer: View on Devnet
Extension: Non-transferable

spl-token create-token --program-2022 --enable-non-transferable

I minted one badge token to myself, then deliberately tried to send it to a throwaway wallet. Here is the exact runtime rejection:
Program log: Instruction: TransferChecked
Program log: Transfer is disabled for this mint
Program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb failed: custom program error: 0x25

Error 0x25 is decimal 37, the NonTransferable entry in the Token-2022 error
enum. The rejection came from the validator, not from the CLI or the RPC layer.
There is no way to call the program "around" the extension. The rule lives on the
asset.

spl-token display $MINT
# Extensions
#   Non-transferable

When would you use this?
Completion certificates. Event attendance proofs. KYC credentials tied to a
specific wallet. Anything where the point is that the credential belongs to the
holder and cannot be resold or delegated.

In Web2 you would enforce this with a database constraint or an API check. The
risk is that anyone who can reach the database directly can break the rule. On
Solana the rule is in the program. The program is in the validator. There is no
around.

What surprised me

I expected the stacking to be complicated. It wasn't. Two flags at creation time,
two TLV entries in the same byte buffer, and the CLI just prints both in the
Extensions block of spl-token display. The Token-2022 design is genuinely
composable in a way that feels like it was designed by someone who got burned by
non-composable systems before.

The interest extension surprised me most. I came in expecting it to mint tokens.
It doesn't. It's a view function disguised as a balance. Once I understood that,
I stopped thinking of it as a financial primitive and started thinking of it as
a display configuration. That reframe changed how I'd use it in a real product —
probably for a points or loyalty system where the raw backing supply is fixed but
the displayed "value" grows over time.

If I were building a real product today, I'd reach for TransferFeeConfig for any
token that needs sustainable protocol revenue, and NonTransferable for any
credential or badge that should be identity-bound. The interest extension I'd hold
for a specific display-layer use case where the raw supply needs to stay auditable
but the user-facing number should grow.

All code and terminal output is in my public build log:
👉 https://github.com/gopichandchalla16/100-days-of-solana

Day 55 of #100DaysOfSolana

Solana NFTs Without Metaplex: What I Learned Building with Token Extensions published: true

Gopichand — Tue, 09 Jun 2026 05:22:24 +0000

Before this week I thought you needed Metaplex to build a real Solana NFT. It turns out you can mint a full NFT, stamp metadata directly onto it, group it inside a collection, audit every byte, and mutate it live — using only the Token Extensions program and the SPL token CLI. No third-party framework required.

This post covers what I built during Days 44–47 of #100DaysOfSolana, what surprised me coming from a Web2 background, and what I would build next.

The Mental Model: What a Solana NFT Actually Is

Before writing a single command, I had to unlearn something. In Web2, an NFT feels like a record in a database that points to a JPEG. On Solana, it is simpler and more precise than that.

A Solana NFT is just a mint account with three properties set just right:

Property	Value
Supply	1 (exactly one token exists)
Decimals	0 (cannot be split)
Mint authority	(not set) — disabled forever

That is it. The "NFT-ness" is not a special program. It is a configuration of the same SPL Token primitives that power every fungible token on the network.

What makes a modern Solana NFT different from a bare 1-of-1 token is the Token Extensions program (Token-2022). Instead of storing metadata in a separate account managed by Metaplex, Token Extensions lets you stamp the name, symbol, URI, and custom fields directly onto the mint account itself. Everything lives in one place. Any wallet, any marketplace, any RPC node can read it without trusting a third-party indexer.

What I Built: Four Days, Four Commands

Day 44 — First NFT with on-chain metadata

I minted a 1-of-1 token using the Token-2022 program, initialized a Metadata Pointer extension on it, and attached a name, symbol, and URI pointing to a JSON file on GitHub Gist.

# Create the mint with metadata extension enabled
spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 0 \
  ./nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF.json

# Stamp name, symbol, and URI directly onto the mint
spl-token initialize-metadata \
  nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF \
  "First Light" \
  "LIGHT" \
  "https://gist.githubusercontent.com/gopichandchalla16/..."

Mint address: nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF
View on Solana Explorer (devnet)

Day 45 — NFT collection using Group and Member extensions

I created a separate collection mint using the Group extension, then minted two member NFTs and registered each one under the collection using the Member extension.

# Register a member NFT into the collection
spl-token group-member-initialize \
  <MEMBER_MINT> \
  <COLLECTION_MINT> \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The collection mint ended up with Size: 2, Max Size: 3. Each member NFT carries a Group field that points byte-for-byte to the collection mint — the on-chain equivalent of a foreign key.

Day 46 — Auditing every byte on devnet

Instead of trusting that everything worked, I read both mints back from devnet the same way a senior engineer reviews their own work before shipping.

spl-token display nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF
spl-token display AC3peC3tdZUnLY44zGYC7YAuEaPknkMcRqsmAyvXJtMx

The key check was this line inside Token Group Member on each member NFT:
Group: AC3peC3tdZUnLY44zGYC7YAuEaPknkMcRqsmAyvXJtMx ✅

That address matches the collection mint exactly. Phantom and every marketplace reads this field to verify collection membership — without trusting any off-chain index. That is what "verifiable provenance" actually means. Not marketing. Just two byte arrays comparing equal.

Day 47 — Mutating metadata live

This was the day I stopped treating the NFT like a fragile artifact and started treating it like a live row of data.

# Rename it
spl-token update-metadata nftTnVuy... name "Field Notes"

# Add a custom field — the schema is completely open
spl-token update-metadata nftTnVuy... rarity legendary

# Remove it
spl-token update-metadata nftTnVuy... rarity --remove

# Swap the URI to point at a new metadata JSON
spl-token update-metadata nftTnVuy... uri https://gist.githubusercontent.com/janvinsha/...

Every command was one transaction. Every change appeared in Explorer within seconds.

The Surprising Part

Three things hit differently than I expected coming from Web2.

1. The on-chain layer and the off-chain layer move at different speeds.

When I renamed the NFT to "Field Notes", Explorer showed the new name in seconds. But the image — which lives at the URI I pointed at, hosted on GitHub Gist — stayed cached in wallets for much longer. The on-chain pointer updates instantly. The thing it points at does not. This is why serious NFT projects use Arweave or IPFS for permanent image hosting instead of a mutable HTTP server.

2. There is no separate NFT program.

I kept waiting to discover the "real" NFT layer. There is none. The same Token-2022 program that handles transfer fees, interest-bearing tokens, and compliance controls is also the program that handles NFT metadata and collections. Extensions compose on the same primitives.

3. The metadata schema is a blank canvas.

The additional_metadata array accepts any key-value pair you want. I stamped rarity: legendary onto a live mint in one CLI call and watched it appear on Explorer. No migrations. No schema definitions. No contract upgrades. Just one transaction.

What I Would Build Next

Permanent image hosting — move the image URI from GitHub Gist to Arweave so the pointer and the asset are both permanent
Dynamic NFT — use the mutable metadata to track something that changes over time, like XP or level in a game (Solana's official Dynamic Metadata NFT guide covers this pattern)
Metaplex comparison — Metaplex Core is the dominant alternative NFT standard on Solana, with a different account structure and royalty model. I want to build the same collection in both standards and write a direct comparison.

Resources I Actually Used

Token Extensions overview — the canonical reference
Metadata Pointer and Token Metadata — how metadata lives on the mint
Token Groups and Members — how collection membership works
Dynamic Metadata NFTs guide — the official Solana guide for what comes next
Solana Explorer (devnet) — for verifying every change live

All the code and terminal output from every day is in my public repo:
👉 github.com/gopichandchalla16/100-days-of-solana

This post is part of #100DaysOfSolana. Follow along or jump in any day at mlh.link/solana-100.

44 Days of Solana: From an Empty README to a Live NFT on-chain — My Finish-Up-A-Thon Story

Gopichand — Thu, 04 Jun 2026 05:55:51 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Honestly, I almost didn't write this post.

Not because I didn't have anything to show — but because I kept telling myself
"it's not done yet." Sound familiar?

Back in early 2026, I started a repo called
100 Days of Solana.
The idea was simple: learn Solana development from absolute zero, build
something on-chain every single day, and document it publicly.

Day 1, I generated a keypair. That was it. One file in the repo —
a README with a title and no code. I had no blockchain background,
only a Web2 history in Python and JavaScript. I didn't even know
what "rent" meant in the context of Solana accounts.

But I kept showing up. 44 days later, here's what that same repo became:

✅ Wallets, airdrops, SOL transfers, SPL token creation
✅ Token-2022 extensions — transfer fees, interest-bearing tokens, default frozen, non-transferable (soulbound), permanent delegate
✅ A fully named, on-chain NFT — "First Light" — with metadata, image, and permanently locked supply. Minted using only the Solana CLI. No Metaplex. No framework.
✅ 9 published DEV.to articles translating every concept into Web2-friendly language
✅ Every single transaction signature linked to Solana Explorer so you can verify my work on-chain

This project means more to me than any side project I've ever started.
It's proof that 30 minutes a day, compounded over 44 days,
produces something real and verifiable.

And GitHub Copilot is a big reason I didn't quit on Day 8, Day 23, or Day 39.

🔗 Repo: https://github.com/gopichandchalla16/100-days-of-solana

Demo

🌐 "First Light" — My First NFT, Live on Solana Devnet

I built this NFT end-to-end using nothing but spl-token CLI commands.
No framework. No JS. Just me, the terminal, and a lot of patience.

Field	Value
Name	First Light
Symbol	LIGHT
Mint Address	`nftTnVuyNU1kwTgv7edG6BPmHCtp2NMrawbw94kwZTF`
Program	Token-2022
Supply	1 (locked forever)
Decimals	0
Extensions	`metadataPointer` + `tokenMetadata`
Mint Authority	Disabled 🔒

🔗 View "First Light" on Solana Explorer

The vanity keypair starting with nft took about 20 minutes to generate
locally using solana-keygen grind. Every character you see in that address
was intentional.

📋 Every Step — Verified On-Chain

Here are all 5 transactions, in order. You can click any of them and
see exactly what happened on the Solana blockchain:

Step	What I Did	Verified Transaction
1	Created mint account, initialized metadata pointer, initialized mint	3iXwa…jzXtz
2	Initialized token metadata — name, symbol, URI	45PYG…Kv2D4
3	Created the associated token account	gWLGo…Ymmgj
4	Minted exactly 1 token	3B8MS…wrQoP
5	Revoked mint authority — forever	3Yhop…kckqo

No one can ever mint another LIGHT token. That is by design.

📰 9 Published DEV.to Articles (300+ total reactions)

These are not just summaries of what I did. Each one is a full
explanation written specifically for Web2 developers entering the
Solana ecosystem:

📊 Where the Project Stands

Metric	Status
🟣 Daily Build Progress	44 / 100 Days Complete
🖤 DEV.to Articles	9 Published
🟢 On-Chain Transactions	Live on Solana Devnet
📄 License	MIT
🔒 NFT Mint Authority	Disabled Forever

The Comeback Story

Let me be honest about where this project started and where it almost ended.

Day 1 — What the repo actually looked like

gopichandchalla16/100-days-of-solana
└── README.md ← literally just a title

That was it. I had written "100 Days of Solana — learning in public"
and committed it at midnight. No code. No plan. Just a title and the
pressure of having put it on GitHub.

The first week was rough. The Solana docs are not beginner-friendly
if you're coming from Web2. The Token-2022 documentation is especially
sparse. I spent 3 hours on Day 4 just trying to understand why my
airdrop wasn't showing up (I was checking the wrong cluster).

There were three moments where I almost stopped entirely:

Day 8 — I couldn't figure out why my token transfer kept failing
with a cryptic 0x1 error. I had been at it for two hours and it was
past midnight. I nearly closed the laptop and told myself I'd "come back to it."

Day 23 — I hit a wall with Token-2022 extension architecture.
I understood how individual extensions worked but not how to compose
them safely. Nothing I read explained it in plain terms.

Day 39 — The NFT build broke on step 2 of 5. My metadata wasn't
being initialized because I ran initialize-mint before
initialize-metadata-pointer. The error wasn't obvious.
I almost started over from scratch.

I didn't quit any of those nights. GitHub Copilot helped me through
each one — and I'll explain exactly how in the Copilot section.

Day 44 — What the repo became

gopichandchalla16/100-days-of-solana
├── day-01/ through day-44/ ← 44 documented daily builds
├── 9 DEV.to articles published
├── Every tx signature verified on Solana Explorer
├── Token-2022 extensions built and tested:
│ ├── Transfer fees (compliance use case)
│ ├── Interest-bearing tokens (DeFi use case)
│ ├── Default frozen + thaw (regulated assets)
│ ├── Non-transferable / soulbound (credentials)
│ └── Permanent delegate (revocable access)
├── NFT "First Light" — vanity keypair, Token-2022,
│ on-chain metadata, locked supply
└── README with live progress bar, week logs,
all explorer links

The difference between Day 1 and Day 44 is not just the code.
It's the understanding behind it.

The 3 moments that defined this project

Day 13 — The account model finally made sense.

I had been running solana balance and spl-token create-account for
days without really understanding why Solana accounts need rent.
Then I sat down and wrote a DEV.to article explaining it with a
Web2 analogy: accounts are like database rows, rent is like a monthly
hosting fee — stop paying and the row gets deleted.

Writing that article forced me to understand it deeply enough to
explain it simply. After Day 13, I stopped copying commands and started
understanding what each one actually does.

Days 36–40 — Five Token-2022 extension combinations in one week.

This was the hardest week. I built:

A transfer fee token (simulating a transaction tax)
An interest-bearing token (simulating a yield-bearing asset)
A default-frozen token with thaw authority (compliance gating)
A non-transferable soulbound token (on-chain credential)
A permanent delegate token (revocable programmatic access)

Each one is a real devnet transaction. Each one has a verifiable
signature on Solana Explorer. Each one taught me something different
about how Token-2022 is designed to handle real-world financial
and compliance scenarios.

Days 43–44 — My first NFT. No Metaplex. Just the CLI.

I wanted to understand NFTs at the protocol level — not through
a framework, not through a library, but through raw spl-token commands.

I generated a vanity keypair starting with nft using solana-keygen grind.
I added two Token-2022 extensions: metadataPointer and tokenMetadata.
I minted exactly 1 token. I disabled the mint authority forever.

"First Light" now lives on-chain permanently with its name, symbol,
and metadata URI intact. Nobody can create another one. That's what makes it an NFT.

The biggest technical lesson of 44 days

Token-2022 extensions cannot be added after mint creation. Ever.

There's no workaround. No patch. No update instruction.
You must decide your full extension set before you run
initialize-mint. It's like designing a database schema —
you can't add a non-nullable column without a migration.

I learned this the hard way on Day 38 when I tried to add
interest-bearing to an existing mint. The transaction failed
and I had to start the token from scratch. That 30-minute mistake
became the most important architectural lesson I've had in 44 days.

My Experience with GitHub Copilot

I want to be specific here, not just say "Copilot helped a lot."
Here are the exact moments where it made the difference.

When I was stuck on `0x11` at midnight (Day 37)

My compliance-gated token transfer failed with error 0x11 —
AccountFrozen. I knew the token was frozen by design but I thought
I had thawed it. The transaction kept failing anyway.

I was staring at the error in my terminal. Copilot's inline suggestion
explained what I was missing: both the sender's ATA and the
recipient's ATA need to be thawed — not just the sender's.
One suggestion. One minute. Problem solved.

Without Copilot, I would have been digging through the SPL Token
source code for the next hour — or worse, I would have given up
and moved on without truly understanding the error.

When soulbound tokens confused me (Day 40)

Non-transferable tokens are conceptually simple — once minted to a
wallet, they can never move. But when I tried to demonstrate this
by attempting a transfer, the transaction failed with 0x25.

I didn't expect the error. Copilot explained: non-transferable tokens
can be burned but not transferred. It then suggested I write a burn
script to demonstrate the constraint properly — which turned into
the best hands-on example in my Week 6 article.

The bug became the feature. That happens a lot when Copilot is involved.

Writing CLI commands faster and correctly

The Token-2022 program ID is 44 characters long:
TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Before Copilot, I copied this from docs and sometimes mis-pasted it.
With Copilot, it autocompleted the entire ID, the --program-id flag,
all the relevant options, and even the correct sequence of commands.

The sequence matters enormously in Token-2022. For the NFT build,
initialize-metadata-pointer must come before initialize-mint.
The Solana docs don't emphasize this clearly for beginners.
Copilot's autocomplete surfaced the correct order naturally,
in context, while I was typing. That saved me from the exact error
that had broken my build on Day 39.

Turning raw terminal output into readable articles

Every DEV.to article I wrote started the same way:
a terminal window full of transaction signatures, error codes,
and hex-encoded account data.

Copilot helped me turn that raw output into:

Clear Web2 analogies that explain Solana concepts without jargon
A consistent structure: what I planned → what broke → what I learned
Opening paragraphs that hook readers who have never touched blockchain

Nine articles. 300+ reactions across all of them.
That audience engagement would not exist without Copilot helping me
bridge the gap between "developer notes" and "readable article."

Explaining the "why" — not just the "how"

This is the thing I appreciate most about Copilot, and it's hard to
quantify. When a command worked, I often didn't fully understand why
it worked. Copilot's inline comments filled those gaps constantly:

"This flag enables close authority so you can reclaim rent later."
"The metadata pointer must be initialized first because the mint instruction reads the extension list."
"Revoking mint authority is a one-way operation — there's no re-enable instruction in Token-2022."

These micro-explanations compounded over 44 days into real,
deep understanding of the protocol. I'm not just writing Solana
commands anymore. I understand what they do and why they exist.

The honest summary

GitHub Copilot didn't write this project for me.
Every transaction on Solana Explorer is a decision I made,
a command I typed, a concept I understood.

But Copilot removed the friction that would have made me quit.
It turned 2-hour debugging sessions into 10-minute ones.
It turned terminal output into articles people actually read.
It turned "I don't understand this" into "oh, that's why."

44 days in. 56 to go. I'm not stopping.

🔗 GitHub Repo: https://github.com/gopichandchalla16/100-days-of-solana

📰 DEV Profile: https://dev.to/gopichand_dev

🐦 X / Twitter: https://x.com/GopichandAI

If you're a Web2 developer curious about Solana — follow the repo.
Every day folder has the exact commands I ran, the errors I hit,
and what I learned. It's all there.

#100DaysOfSolana #Solana #Web3 #BuildInPublic

I Built 5 Token Extension Combinations on Solana This Week — Here's What Each One Does

Gopichand — Tue, 02 Jun 2026 06:04:10 +0000

If you have ever used a brokerage account, you already understand token extensions.

Your brokerage locks your account until you verify your identity. A stock you own cannot be
transferred to someone else without compliance checks on both sides. A professional license
is tied to you — the issuing body can revoke it, but you cannot sell it. An interest-bearing
savings account accrues value over time without you doing anything.

All of these are real-world rules applied to value. Token-2022 extensions let you encode
those same rules directly into a Solana token mint — at the protocol level, not the
application layer. No backend. No database. No API that can go down.

Over the past several days I built five different token configurations as part of my
100 Days of Solana challenge.
Here is what I learned.

What Are Token Extensions?

Token-2022 is Solana's upgraded token program
(TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb).
It is backwards-compatible with the original SPL Token program, but it lets you attach
extensions to a mint at creation time.

Extensions are stored as TLV (type-length-value) blobs in the mint account's data.
Each extension adds bytes, and those bytes cost rent. More extensions = bigger account =
more SOL locked at creation. That is the core tradeoff to understand before you design
a token.

Extension 1 — Interest-Bearing Tokens

The Web2 analogy: A savings account that accrues interest over time.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --interest-rate 500

This sets an initial rate of 500 basis points (5%). The rate can be updated later by
the rate authority:

spl-token set-interest-rate <MINT_ADDRESS> 15000

What surprised me: The extension does NOT mint new tokens. It is purely a
calculation layer. Wallets and apps read the rate and elapsed time to display an
adjusted "UI balance." The raw on-chain balance stays the same. When you run
spl-token display, you see both:
Current rate: 15000bps
Average rate: 500bps ← historical average is preserved

Use cases: Yield-bearing stablecoins, loyalty points that grow over time,
reward tokens for long-term holders.

Extension 2 — Transfer Fees

The Web2 analogy: A payment processor that takes a cut of every transaction.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee 100 50000
# 100 basis points (1%) fee, max 50000 tokens per transfer

Fees are collected at the token account level (withheld in the recipient's account),
not sent automatically. The withdrawal authority must harvest them:

spl-token withdraw-withheld-tokens <DESTINATION> --include-mints <MINT>

What surprised me: The fee is enforced by the Token-2022 program itself on every
TransferChecked instruction. No smart contract needed. No way to bypass it from
the frontend.

Use cases: Protocol revenue, DAO treasury funding, creator royalties on every transfer.

Extension 3 — Default Account State (Frozen)

The Web2 analogy: A brokerage that freezes every new account until KYC passes.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-freeze \
  --default-account-state frozen

Every token account created for this mint starts in a frozen state. Nobody can
receive, send, or burn tokens until the freeze authority explicitly thaws them:

spl-token thaw <TOKEN_ACCOUNT_ADDRESS>

The key insight I learned the hard way: It is not enough for the sender to be
thawed. The recipient must also be thawed. Both sides need to pass the compliance check.

When I tried to transfer from a thawed account to a still-frozen one: Program log: Error: Account is frozen (custom program error: 0x11)

Use cases: Regulated security tokens, KYC-gated stablecoins, permissioned loyalty
programs.

Extension 4 — Non-Transferable (Soulbound)

The Web2 analogy: A professional certification that belongs to you — you cannot sell it.

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

--decimals 0 because credentials are whole units. You either have the credential or
you don't.

Any transfer attempt fails immediately: Program log: Transfer is disabled for this mint (custom program error: 0x25)

0x25 = decimal 37 = NonTransferableError in the Token-2022 source.

Use cases: DAO membership badges, hackathon completion certificates,
verified contributor status, employee access tokens.

Extension 5 — Permanent Delegate (Revocable)

The Web2 analogy: Your employer can revoke your access badge at any time, without
asking you.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-permanent-delegate \
  --enable-non-transferable \
  --enable-metadata \
  --decimals 0

Combining --enable-non-transferable with --enable-permanent-delegate creates a
revocable soulbound token: the holder cannot move it, but the issuer can burn it
from any account without the holder's signature.

# Revoke the credential — no holder signature needed
spl-token burn <RECIPIENT_TOKEN_ACCOUNT> 1 \
  --owner ~/.config/solana/id.json \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

What surprised me: The Solana runtime logs a warning whenever a token account is
created for a mint with a permanent delegate:
Warning: Mint has a permanent delegate,
so tokens in this account may be seized at any time

Full transparency baked in at the protocol level. The holder is informed at account
creation — not buried in a ToS.

The Cost of Extensions

Each extension adds bytes to the mint account. More bytes = more rent-exempt SOL:

Configuration	Data Size	Rent
Default frozen only	171 bytes	~0.0021 SOL
Interest-bearing only	222 bytes	~0.0024 SOL
Transfer fees + Interest + Metadata	599 bytes	~0.0051 SOL

Metadata is the biggest cost driver because it stores variable-length strings
(name, symbol, URI) directly inside the mint account. Every character costs rent.

What Cannot Be Changed After Creation

This is the part that matters most before mainnet deployment:

Extensions cannot be added after mint creation. The account is allocated with exactly the space for the declared extensions. You must plan upfront.
The permanent delegate cannot be removed once set (only transferred to a different address if the current delegate signs).
Non-transferable is permanent. Once set, no authority can enable transfers.

Think of it like a database schema. Define it before you insert the first row.

Inspecting Any Token Extension Config

spl-token display <MINT_ADDRESS> \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

This single command decodes every extension in the mint account and prints it in
human-readable form. I now run this before touching any Token-2022 mint I didn't
create myself.

Where to Go Next

Token Extensions official docs — the canonical reference, well-maintained
Token-2022 Extensions Guide — deeper per-extension implementation notes
My full 100 Days of Solana repo — every command I ran, every error I hit, documented day by day

The best way to learn these is to run the CLI commands yourself on devnet. Each failure
message tells you exactly what rule was violated and which error code fired. That feedback
loop is faster than any tutorial.

This post is part of my #100DaysOfSolana challenge — building and documenting in public
every day. Follow along on X @GopichandAI or
GitHub.

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

Gopichand — Sun, 24 May 2026 17:05:43 +0000

I spent the last five days building tokens on Solana — and it completely
changed how I think about what a "token" actually is.

Coming from Web2 and EVM development, I assumed a token was a number in a
database with some transfer logic wrapped around it. On Solana, it's much
closer to a configurable protocol object. Here's everything I learned across
Days 29–33 of my #100DaysOfSolana challenge.

The Starting Point: Two Token Programs

Solana has two token programs:

SPL Token (original) — simple, battle-tested, does the basics
Token Extensions Program (Token-2022) — everything the original does, plus built-in extensions for fees, metadata, soulbound tokens, and more

I used Token-2022 for almost everything this week because it lets you attach
behavior directly to the mint — no separate smart contract needed.

Day 29 — Creating My First SPL Token

The first thing that surprised me: a token on Solana is two separate accounts.

Mint account — holds the token's configuration (supply, decimals, mint authority)
Token account — holds a specific wallet's balance of that token

spl-token create-token --decimals 9
spl-token create-account <MINT_ADDRESS>
spl-token mint <MINT_ADDRESS> 1000

In Web2, this would be one database table with a balance column. On Solana,
the separation means the mint config is completely independent of who holds
what — any wallet can hold any token as long as they have a token account for it.

Day 30 — Token-2022 with On-Chain Metadata

The original SPL token has no name or symbol stored on-chain. You need an
external metadata program (Metaplex) to give it an identity. Token-2022
changes this with the metadata extension — name, symbol, and URI live
directly inside the mint account.

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

spl-token initialize-metadata <MINT_ADDRESS> \
  "GopichandToken" "GOPI" \
  "https://your-metadata-uri.json"

Run spl-token display <MINT_ADDRESS> and you'll see the name and symbol
sitting right there in the mint account output. No external call. No
separate metadata program. The token is the metadata.

Day 31 — Transfer Fees at the Protocol Level

This is where it got interesting. I attached a 1% transfer fee to a
token mint — meaning every transfer automatically withholds 1% in the
recipient's token account, uncollectable by the recipient, waiting for the
mint authority to withdraw.

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

After transferring 100 tokens, the recipient got 99. The 1 withheld token
sat locked in their account until I ran:

spl-token withdraw-withheld-tokens \
  <MY_TOKEN_ACCOUNT> \
  <RECIPIENT_TOKEN_ACCOUNT>

In Web2, building a platform fee on transfers requires intercepting every
transaction in your backend. On Solana, it's a flag on the mint. The
program enforces it — not your server.

Day 32 — The Full Lifecycle in One Sitting

Day 32 was a consolidation day. No new concepts — just proving I could
build the complete token lifecycle from scratch without checking notes:

Create Token-2022 mint with metadata + 2% transfer fee
Initialize metadata (name: ReinforceCoin, symbol: RFC)
Create token account and mint 1000 RFC
Transfer 100 to a second wallet → recipient gets 98, 2 withheld
Withdraw withheld fees → balance becomes 902 Mint: 6YnDTE8cETtvKyesVM9frSeWCfpQUx757qcCQyHaBe9T Final balance: 902 RFC ✅

The "aha" moment: I realized the pattern is always the same regardless of
which extensions you use. Create → configure → mint → transfer →
collect. The specifics change. The lifecycle doesn't.

Day 33 — Soulbound Tokens

The most conceptually interesting day. I created a non-transferable
token — a token that is permanently locked to the wallet it's minted into.

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

I minted 10 tokens, then tried to transfer 5 to a second wallet. The
program rejected it instantly:
Program log: Transfer is disabled for this mint
custom program error: 0x25

That error code 0x25 (decimal 37) is NonTransferable — a first-class
error in the Token Extensions Program. This isn't application logic that
a clever script could bypass. The program itself rejects the instruction.

What's interesting is that burning still works. The owner can destroy
tokens they hold. They just can't send them. After burning 3, my balance
dropped from 10 to 7 — exactly as expected.

Real-world uses for non-transferable tokens:

Course completion certificates
KYC / identity verification
Hackathon participation badges
Employee credentials
On-chain reputation scores

In Web2, preventing credential trading means writing application rules that
can be worked around. On Solana, the restriction is part of the asset itself.

What Surprised Me

The separation of mint and token accounts took longer to internalize than
I expected. I kept confusing "the mint address" with "my token account."
They're different accounts with different purposes. The mint is the factory.
The token account is the warehouse.

The error messages are actually readable. Transfer is disabled for this mint is exactly what it sounds like. Coming from debugging opaque
EVM reverts, this felt refreshingly honest.

Extensions compose. You can combine metadata + transfer fees in a
single mint creation command. Day 32 showed me that Token-2022 isn't a
collection of separate features — it's a composable system.

What's Next

I'm on Day 33 of 100. Next up: deeper into Token-2022 extensions
(interest-bearing tokens, confidential transfers), then moving into
Anchor and on-chain programs.

I'm building toward AI agents that can own wallets and execute Solana
transactions autonomously — and understanding the token layer deeply is
a prerequisite for that.

If you're following along, my full build log is at:
👉 github.com/gopichandchalla16/100-days-of-solana

Day 34 of #100DaysOfSolana — writing in public, building in public.

Week 5 on Solana: Everything I Learned About Tokens (Days 29–31)

Gopichand — Thu, 21 May 2026 05:07:38 +0000

Five weeks into my #100DaysOfSolana challenge and I just crossed into
the most exciting territory yet — Solana's token layer. This week I went
from zero token knowledge to creating, branding, minting, distributing,
and even charging fees on tokens — all on-chain. Here's everything I learned.

What "Tokens" Actually Means on Solana

Before this week, I thought tokens were complicated. Smart contracts,
deployment scripts, audits — the whole Web3 horror story.

Turns out, Solana has a completely different model. The SPL Token Program
is a single shared, audited program already deployed on-chain. Every token
on Solana — from USDC to memecoins to your own project token — is created
using the same program. You never write token logic. You just call it.

This is the Web2 equivalent of using Stripe instead of building your own
payment processor. The infrastructure is already there.

Day 29: My First Token — Raw and Nameless

On Day 29, I ran one command:

spl-token create-token

A token appeared on-chain. Supply: 0. Decimals: 9. Mint authority: me.

Then I minted 100 tokens into a token account:

spl-token create-account MINT_ADDRESS
spl-token mint MINT_ADDRESS 100
spl-token display MINT_ADDRESS

Output: SPL Token Mint
Address: 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
Supply: 100000000000
Decimals: 9
Mint authority: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Freeze authority: (not set)

Key insight: Supply shows 100000000000 for 100 tokens because
decimals = 9, so 100 × 10^9. All on-chain math is integer arithmetic —
no floating point, no rounding errors.

One problem: Explorer showed it as "Unknown Token." No name, no symbol.
That sent me to Day 30.

Day 30: Giving My Token an Identity with Token-2022

The fix: switch to Token Extensions Program (Token-2022). This newer
standard embeds metadata — name, symbol, URI — directly inside the mint
account. No separate Metaplex account needed.

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

spl-token initialize-metadata MINT_ADDRESS \
  "100DaysCoin" "HUNDO" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json"

My token now had an identity: 100DaysCoin (HUNDO).

Then I minted 1000 HUNDO and transferred 250 to a second wallet:

spl-token transfer MINT_ADDRESS 250 SECOND_WALLET \
  --fund-recipient --allow-unfunded-recipient

Final: 750 HUNDO (me) / 250 HUNDO (second wallet). The
--fund-recipient flag automatically created the recipient's Associated
Token Account (ATA) and covered rent. One flag replaces what would be
multiple API calls in Web2.

Day 31: Built-in Transfer Fees — No Middleware Required

This was the most mind-bending day. In Web2, charging a per-transaction
fee means building middleware, hooking into payment flows, writing fee
collection jobs. On Solana, it's one flag at mint creation:

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

100 basis points = 1% fee. The program enforces it on every transfer —
no middleware, no bypass possible.

spl-token transfer MINT_ADDRESS 100 SECOND_WALLET --expected-fee 1

The --expected-fee flag is a safety check: the transfer fails if the
calculated fee doesn't match what you specify. After the transfer:
My wallet: 900 tokens
Second wallet: 99 tokens ← received 100, 1 withheld as fee

The withheld fee sits locked in the recipient's token account. Only the
withdraw withheld authority (set to my wallet at creation) can collect it:

spl-token withdraw-withheld-tokens MY_TOKEN_ACCOUNT SECOND_WALLET_TOKEN_ACCOUNT

Final result: 901 tokens in my wallet (900 + 1 fee swept back) ✅

The Mental Model That Changed Everything

Web2 Concept	Solana Equivalent
Rewards program definition	Mint account
User balance row in DB	Token Account (ATA)
Display name / branding	On-chain metadata (Token-2022)
Transfer API endpoint	`spl-token transfer`
Payment processor fee	Transfer fee basis points
Fee collection middleware	`withdraw-withheld-tokens`
Admin-only mint permission	Mint authority (cryptographic)

SPL Token vs Token-2022: Quick Reference

Feature	SPL Token	Token-2022
Basic minting & transfers	✅	✅
On-chain metadata	❌	✅
Transfer fees	❌	✅
Interest-bearing tokens	❌	✅
Confidential transfers	❌	✅

For any new token in 2026: Token-2022 is the default.

What's Next

Week 6 goes deeper — more Token Extensions, and eventually building
tokens with real utility. The foundation is solid.

31 days in. 69 to go.

Articles in this series:

→ Day 29: SPL Token Basics

→ Day 30: Token-2022 Branded Token

🔗 GitHub: 100-days-of-solana

Building daily → @GopichandAI | #100DaysOfSolana

How I Created My First Solana Token from Scratch (SPL Token Basics Explained)

Gopichand — Thu, 21 May 2026 04:48:07 +0000

On Day 29 of my #100DaysOfSolana challenge, I created my first-ever token
on Solana's devnet. Not by deploying a smart contract. Not by writing a
single line of code. Just a CLI and 5 commands.

Here's what I learned — and why Solana's token model is fundamentally
different from anything in Web2.

The Web2 Mental Model (and Why It Breaks Here)

In Web2, when you build a rewards or credits system, you:

Create a tokens table in your database
Write API endpoints to create, read, update balances
Handle edge cases like double-spending yourself
Maintain a server to keep it all running

On Solana, none of that exists. The SPL Token Program is a shared,
audited, on-chain program that any developer can use — no custom backend,
no smart contract needed. You just call it.

The Two Key Accounts You Need to Understand

Before touching the CLI, understand this mental model:

Mint Account = the global definition of your token

Stores total supply
Stores decimal precision
Stores who has authority to mint more
One per token type

Token Account = a wallet's individual balance for ONE specific token

Think of your wallet as a filing cabinet
Each token account is a separate folder inside it
One folder per token type you hold

This separation is unusual coming from Web2 — but it's how Solana keeps
its data organized and its runtime blazing fast.

Step-by-Step: Creating My First SPL Token

Prerequisites

solana config set --url devnet
solana address    # confirm your wallet
solana balance    # confirm you have SOL for fees

I had 6.13 SOL on devnet — more than enough. No airdrop needed.

Step 1: Create the token mint

spl-token create-token

Output: Creating token 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
under program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Address: 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
Decimals: 9

This created a Mint account on-chain. Supply is zero. Decimals default
to 9. My wallet is the mint authority — the only one who can create more.

Step 2: Create a token account

spl-token create-account 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq

Output: Creating account B4SSsjUA1fcJmjMhmYis3EpLTSBD9GGo1DBEZAwjae7c

You cannot receive tokens directly into your wallet. You need a
dedicated token account for each token type. This is the "folder in the
filing cabinet."

Step 3: Mint some supply

spl-token mint 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq 100

Output: Minting 100 tokens
Token: 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
Recipient: B4SSsjUA1fcJmjMhmYis3EpLTSBD9GGo1DBEZAwjae7c

Step 4: Inspect everything

spl-token supply 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
# → 100

spl-token accounts
# Token                                         Balance
# 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq  100

spl-token display 2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
# SPL Token Mint
#   Address:          2M6t3SbJMz95mZ8nzF8MLq364v2ZQQ235BkxhE93g7hq
#   Program:          TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
#   Supply:           100000000000
#   Decimals:         9
#   Mint authority:   AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
#   Freeze authority: (not set)

The Decimals Trick

Notice the supply shows 100000000000 even though I minted 100.

That's because decimals = 9, so:
100 tokens × 10^9 = 100,000,000,000 raw units

This is identical to how SOL works with lamports: 1 SOL = 1,000,000,000 lamports

All on-chain arithmetic is integer math — no floating point, no rounding
errors. The CLI handles the conversion for you.

What "Mint Authority" Actually Means

The mint authority field is your wallet address — meaning only you
can call spl-token mint to create more supply.

This is the on-chain equivalent of "only the admin can issue new credits"
in a Web2 system. Except here, it's enforced by cryptography, not by
an if (user.role === 'admin') check in your backend.

You can also permanently disable minting (set supply to fixed) by
running spl-token authorize YOUR_MINT mint --disable. Once done,
it's irreversible.

Freeze Authority: What It Is and Why I Left It Unset

Freeze authority: (not set) means no one can freeze token accounts
holding this token. If freeze authority were set, the authority could
prevent specific wallets from sending or receiving the token — useful
for compliance in real-world asset tokens, but not needed here.

The Big Picture

You just created a digital asset. Not a database row, not an API response
— a real token living on a public blockchain that anyone in the world
can verify right now:

🔗 View on Solana Explorer

Tomorrow (Day 30), I upgraded this with Token-2022 — giving the token
a real name, symbol, and on-chain metadata. The difference is dramatic.

🔗 Full code: GitHub

Building daily → @GopichandAI | #100DaysOfSolana Day 29/100

I Built a Branded Token on Solana in 5 Minutes (No Smart Contract Needed)

Gopichand — Thu, 21 May 2026 04:40:48 +0000

I spent years thinking "creating a token" meant writing complex smart contract
code, deploying it, hoping nothing breaks. Today on Day 30 of my

100DaysOfSolana challenge, I created a fully branded token — with a name,

symbol, and on-chain metadata — in under 5 minutes. No Solidity. No Rust.
Just a CLI.

Here's exactly what I did and what it means.

The Problem with Yesterday's Token

On Day 29, I created my first SPL token on Solana devnet. It worked — but
when I looked it up on Solana Explorer, it showed up as "Unknown Token." Just
a random address with no name, no symbol, no identity.

That's like launching a rewards program for your app but forgetting to give
it a name. Users would see a random ID and have no idea what it represents.

Today I fixed that using Token-2022 — Solana's next-generation token program.

Token-2022 vs the Original SPL Token Program

The original SPL Token Program is solid but basic. To add metadata (name,
symbol, image), you'd traditionally need a separate Metaplex account — an
extra transaction, extra cost, extra complexity.

Token Extensions Program (Token-2022) changes this. It lets you embed
metadata directly inside the mint account itself. One account. Everything
in one place. Fewer transactions, lower cost.

Think of it like this:

Web2 Concept	Solana Equivalent
Reward program definition	Mint account
Display name / branding	On-chain metadata (name, symbol, URI)
User balance record	Associated Token Account (ATA)
Transfer API	`spl-token transfer` instruction

What I Built: 100DaysCoin (HUNDO)

Token name: 100DaysCoin
Symbol: HUNDO
Decimals: 6
Program: Token Extensions (Token-2022)
Mint: 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt

Step-by-Step: How I Did It

Step 1: Create the mint with metadata enabled

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

The --program-id flag tells the CLI to use Token-2022 instead of the
original SPL Token Program. The --enable-metadata flag activates the
metadata extension on the mint.

Output: Creating token 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt
Address: 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt
Decimals: 6

Step 2: Initialize on-chain metadata

spl-token initialize-metadata \
  3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt \
  "100DaysCoin" "HUNDO" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json"

This writes the token's name, symbol, and a URI directly onto the mint
account. The URI points to a JSON file with extended details — description,
image, attributes. This is now verifiable by anyone on-chain.

Step 3: Create a token account and mint supply

spl-token create-account 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt
spl-token mint 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt 1000

Balance check: 1000

Step 4: Transfer tokens to a second wallet

solana-keygen new --outfile ~/second-wallet.json --no-bip39-passphrase

spl-token transfer 3zX5oyL9skYKWo2ZoUHgBwLpG9BzLe1ViuXLgH8joqFt 250 \
  $(solana-keygen pubkey ~/second-wallet.json) \
  --fund-recipient --allow-unfunded-recipient

The --fund-recipient flag is key — it automatically creates the recipient's
Associated Token Account (ATA) and covers the rent cost from my wallet. In
Web2 terms, it's like your API automatically creating a user's balance row
before their first transaction.

Final balances

My wallet: 750 HUNDO ✅
Second wallet: 250 HUNDO ✅

The "Aha" Moment

In Web2, building a token/rewards system means:

Database schema for the currency definition
CRUD API endpoints for balance management
Custom transfer logic with double-spend protection
A server running 24/7 to keep it all alive

On Solana with Token-2022:

create-token = currency definition
create-account = user balance row
transfer = transfer API
Zero server. Zero maintenance. Publicly verifiable.

And critically — the metadata lives on-chain. Not in your database. Not
on your server. On a public ledger that anyone can read, forever.

What's Next

Day 31 onward: deeper into token extensions — transfer fees,
interest-bearing tokens, and eventually building tokens with real utility.
The foundation is set.

🔗 Full code + notes: GitHub

🔗 Mint on Explorer: Solana Explorer

Building daily → @GopichandAI | #100DaysOfSolana Day 30/100

Solana's Account Model Explained for Web2 Developers (No Blockchain Experience Needed)

Gopichand — Mon, 18 May 2026 06:57:15 +0000

If you're a Web2 developer looking at Solana for the first time, the account
model will either click immediately or confuse you completely. I was in the
second camp — until I spent 26 days building on Solana daily as part of the
100 Days of Solana challenge.

Here's the explanation I wish I'd had on Day 1.

The Filesystem Analogy

Think of Solana like a filesystem.

Each account is a file. Every file has metadata (owner, permissions, size)
and contents (data). Programs are executable files. Data accounts are the
documents those programs read and write. The System Program is the
operating system kernel that manages file creation and ownership transfers.

That's the whole model. Let's go deeper.

Everything Is an Account

In Ethereum, there are two types of things: externally owned accounts (wallets)
and contract accounts (smart contracts). They behave differently.

Solana has one type: accounts. Everything — your wallet, a smart contract,
a token mint, a clock showing the current time — is an account. They all live
in one flat key-value store where the key is a 32-byte address and the value
is the account itself.

This uniformity is powerful once it clicks.

The Five Fields Every Account Has

Every single Solana account — whether it's your wallet or the System Program
itself — has exactly five fields. Here's what they look like when you inspect
your own wallet with the Solana CLI:

solana account $(solana address)

Public Key: AWKYsCGBcfGLSz6QpmXzRn7EJ9fRhiJsjYSLDV3c9L9y
Balance: 6.137925 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 18446744073709551615

And in JSON:

{
  "lamports": 6137925000,
  "data": ["", "base64"],
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rentEpoch": 18446744073709551615,
  "space": 0
}

Let's break each field down:

1. lamports — your SOL balance in the smallest unit. 1 SOL = 1,000,000,000
lamports. My wallet has 6,137,925,000 lamports = 6.137925 SOL. Think of
lamports like wei in Ethereum, or paise in INR — the atomic unit.

2. data — a raw byte array. For a basic wallet, this is empty (0 bytes).
For a token mint, it's 82 bytes of structured data. For a program, it's the
compiled bytecode. This field holds the entire state of the account.

3. owner — the program that controls this account. My wallet is owned by
11111111111111111111111111111111 — the System Program. Only the owner program
can modify the account's data or debit its lamports. Anyone can add lamports,
but only the owner can remove them. This one rule is most of Solana's
security model.

4. executable — a boolean. false for wallets and data accounts. true
for programs. When you call a program, Solana checks this flag first.

5. rent_epoch — deprecated. Ignore it. It's always set to the maximum u64
value (18446744073709551615) for all rent-exempt accounts, which is everything
on mainnet today.

Programs Don't Store Their Own State

This is the part that surprises every Web2 developer.

In Web2, a server typically owns its own database. In Solana, programs are
stateless. A program's executable code lives in one account. Any data it
needs to read or write lives in separate data accounts that are passed in
with each transaction.

Here's the direct comparison:

Web2	Solana
Web server	Program account (executable=true)
Database	Data account (executable=false)
Database row	Individual account's `data` field
HTTP request	Transaction instruction
Request body	Instruction data + account list

Why does this matter? Because it means Solana can process transactions in
parallel. If two transactions touch different accounts, they can run at the
same time. That's a big reason Solana achieves 3,000–4,000 TPS on mainnet.

The Ownership Rules Are Simple But Powerful

Three rules govern everything:

Only the owner program can modify an account's data
Only the owner program can debit lamports from an account
Anyone can credit (send) lamports to any account

That's it. No complex permission system. No role-based access control. Just:
you own it, you control it.

When you send SOL to someone, the System Program (owner of both wallets)
executes the transfer. When a token program moves a token, it's the owner of
the token account doing the write. The ownership chain is always clear.

Rent Exemption

Every account must hold a minimum lamport balance proportional to its data
size to stay on-chain permanently. This is called being rent-exempt.

For a basic wallet (0 bytes of data):

solana rent 0
# Rent-exempt minimum: 0.00089088 SOL

For a token mint account (82 bytes):

solana rent 82
# Rent-exempt minimum: 0.0015 SOL

Think of it as a deposit you make to reserve space on the network. You get it
back if you ever close the account. The network needs this mechanism to prevent
people from spamming millions of empty accounts.

Seeing It All in Practice

After 26 days of building on Solana, the account model stopped being abstract
and became obvious. When I inspected the System Program itself:

solana account 11111111111111111111111111111111

Owner: NativeLoader1111111111111111111111111111111
Executable: true
Data: system_program ← literally the program name in bytes

And the Clock sysvar:

solana account SysvarC1ock11111111111111111111111111111111

Owner: Sysvar1111111111111111111111111111111111111
Executable: false
Length: 40 bytes ← slot, epoch, unix timestamp packed as binary

The pattern is always the same: executable=true means it's code,
executable=false means it's data. The owner tells you who controls it. The
data tells you what it stores.

The Mental Model That Clicked For Me

After weeks of building, here's the one-sentence summary:

Solana is a global key-value store. Keys are 32-byte addresses. Values are
accounts with 5 fields. Programs are accounts that transform other accounts
when you call them.

Everything else — tokens, NFTs, DeFi protocols, oracles — is built on top of
this foundation. Once you see it, you can't unsee it.

I'm building in public with the 100 Days of Solana
challenge by MLH. Follow along on GitHub
and X/Twitter.

Day 27 of 100. #100DaysOfSolana

DEV Community: Gopichand

CPI on Solana: The Mental Model I Wish I Had on Day 71

The one sentence that unlocks all of it

What the three pieces actually are

Day 71: The smallest possible CPI — SOL transfer to the System Program

Day 72: The same pattern, different callee — Token-2022

Day 73: PDA-signed CPI — the vault withdraw

Day 74: Program calling another program — compose-lab

Day 75: The error that taught me the most

The pattern is the same every time

What I Learned About PDAs in a Week of Building on Solana

The Problem PDAs Solve

The Mental Model

Anatomy of a Derivation

b"counter" — the static seed prefix

user.key().as_ref() — the dynamic seed

What actually gets hashed

bump — not magic, just one byte

Why the Seeds Matter: Every Byte Counts

Per-user PDAs: include the wallet pubkey

Global singleton PDA: omit the wallet pubkey

Near-miss variants — one byte, totally different address

What the Bump Buys You

Always use the canonical bump

Store the bump once, re-pass it forever

The Full Lifecycle

Step 1 — Derive (off-chain, zero cost, no transaction)

Step 2 — Init (creates the account on-chain, pays rent)

Step 3 — Mutate (update data, no new account creation)

Step 4 — Close (reclaim rent, mark for garbage collection)

The Spoof Test: Where ConstraintSeeds Earns Its Name

What I Would Tell Past Me

Resources and Code

How I Built a Counter Program in Anchor and Learned to Trust My Tests

The Accounts Struct — Where Anchor Earns Its Name

The Handlers — Short by Design

The Tests — Two Paths That Matter

Day 61 — Mutation Testing: Proving the Tests Are Real

What Writing This Revealed

What's Next

Three Token-2022 Mints in One Week: Fees, Yield, and Soul-Bound

Mint 1 — Transfer Fee (Days 50 & 51)

Mint 2 — Transfer Fee + Interest Stacked (Day 52)

Mint 3 — Non-Transferable / Soul-Bound (Day 54)

What surprised me

Solana NFTs Without Metaplex: What I Learned Building with Token Extensions published: true

The Mental Model: What a Solana NFT Actually Is

What I Built: Four Days, Four Commands

Day 44 — First NFT with on-chain metadata

Day 45 — NFT collection using Group and Member extensions

Day 46 — Auditing every byte on devnet

Day 47 — Mutating metadata live

The Surprising Part

What I Would Build Next

Resources I Actually Used

44 Days of Solana: From an Empty README to a Live NFT on-chain — My Finish-Up-A-Thon Story

What I Built

Demo

🌐 "First Light" — My First NFT, Live on Solana Devnet

📋 Every Step — Verified On-Chain

📰 9 Published DEV.to Articles (300+ total reactions)

📊 Where the Project Stands

The Comeback Story

Day 1 — What the repo actually looked like

Day 44 — What the repo became

The 3 moments that defined this project

The biggest technical lesson of 44 days

My Experience with GitHub Copilot

When I was stuck on 0x11 at midnight (Day 37)

When soulbound tokens confused me (Day 40)

Writing CLI commands faster and correctly

Turning raw terminal output into readable articles

Explaining the "why" — not just the "how"

The honest summary

I Built 5 Token Extension Combinations on Solana This Week — Here's What Each One Does

What Are Token Extensions?

Extension 1 — Interest-Bearing Tokens

Extension 2 — Transfer Fees

Extension 3 — Default Account State (Frozen)

Extension 4 — Non-Transferable (Soulbound)

`b"counter"` — the static seed prefix

`user.key().as_ref()` — the dynamic seed

`bump` — not magic, just one byte

When I was stuck on `0x11` at midnight (Day 37)