DEV Community: Prasiddh Naik

CPI on Solana is a function call with a guest list

Prasiddh Naik — Wed, 08 Jul 2026 11:24:38 +0000

Five days ago CPI was three letters in the docs. Now I have called the System Program to move SOL, Token-2022 to mint tokens, a PDA vault to release lamports, and my own counter program to bump a tally — all through the same mechanism.

Thesis: A cross-program invocation is a function call with a guest list. The runtime does not care whether the callee is built into Solana or forty lines you wrote this morning. Your job is to bring the right program ID, the right accounts, and the right signer authority.

The mental model

Strip away the syntax. Every CPI answers three questions.

Which program are you calling?

A program ID — a public key. In Anchor 1.0, CpiContext::new takes that Pubkey as its first argument: ctx.accounts.counter_program.key(), not to_account_info(). Point at the wrong program and a real one still runs — just not the one you meant. I once passed the System Program ID (11111111…) while sending counter instruction bytes. The log said invalid instruction data. Fair enough. The System Program was not broken; my target was.

Which accounts does it need?

The callee owns an accounts struct: Transfer for SOL, MintTo for tokens, Increment for my counter. You pass every account it expects, wired to AccountInfo. Skip one and Anchor names it: AccountNotEnoughKeys on admin_config means the callee added an account your CPI did not include. Pass the wrong account and you get ConstraintSeeds or has_one instead — same idea, different constraint.

Who authorizes the call?

Two paths, and mixing them up causes most CPI pain.

When a wallet signs the outer transaction, the runtime carries that signature into the inner call. No extra signing code. That is how my Day 71 SOL transfer and Day 72 token mint worked.

When a PDA must authorize, there is no private key. Your program calls invoke_signed with the exact seed bytes plus canonical bump. In Anchor that is .with_signer(signer_seeds) on the CpiContext. Those seeds must match #[account(seeds = ..., bump)] on the PDA account — byte for byte, bump included.

The helper function — transfer, mint_to, cpi::increment — is just the envelope.

The code

Here is compose_lab calling my own counter. Same shape as calling the System Program on Day 71:

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>,
}

declare_program!(counter) read my counter's IDL and generated cpi::increment — the same role system_program::transfer plays for built-in programs. The caller never compiled counter's source. Change counter's internals tomorrow; if the IDL holds, the caller stays the same.

The PDA-signed variant adds one thing — .with_signer — on top of the same pattern:

let signer_seeds: &[&[&[u8]]] = &[&[b"vault", user_key.as_ref(), &[bump]]];

let cpi_ctx = CpiContext::new(
    ctx.accounts.system_program.key(),
    Transfer { from: vault, to: user },
)
.with_signer(signer_seeds);

transfer(cpi_ctx, amount)?;

User deposit: plain CpiContext::new — the wallet signed. Vault withdraw: .with_signer — the vault is a PDA with no keypair.

What tripped me up

On Day 75 I broke vault withdraw on purpose by using the wrong bump. The terminal was specific:

AvSWLkjNFjJ5wrw4jL6342nBUygcwn2By745qHci5gtw's signer privilege escalated
Program failed: Cross-program invocation with unauthorized signer or writable account

The runtime re-derived an address from my seeds, it did not match the vault in the instruction, and it refused to authorize the transfer. Fix: ctx.bumps.vault in signer_seeds — the same bump as the account constraint.

That line is not noise. It is a diagnosis. Read program logs top to bottom; [1] and [2] show which program was running when things broke.

None of my CPI failures were logic bugs inside handlers. They were mismatches at the boundary: accounts the caller passed versus constraints the callee enforced. When a CPI breaks, one of those two sides moved.

This draws from #100DaysOfSolana Days 71–75. Code: solana-100-days — sol-mover, token_cpi, vault, compose-lab.

Solana CPI docs · Anchor CPI guide · system_program helpers

What I learned about PDAs in a week of building on Solana

Prasiddh Naik — Thu, 02 Jul 2026 11:22:11 +0000

On Solana, programs are stateless. If your program needs to remember something per user, per game, or per config, it needs a deterministic address it can find again later without storing that address anywhere. Program Derived Addresses (PDAs) are the addresses.

The mental model

The Web2 framing that finally clicked for me: PDAs are like a database primary key you can compute from a row's logical identity — except the "database" is Solana's entire account model, the key derivation is a hash, and your program ID is baked in so only your program can sign for accounts at that address.

In a normal backend, you insert a row, the database assigns an ID, and you store that ID somewhere so you can look the row up later. On Solana, there is no central database handing out IDs. You pick a logical identity — "counter" plus a user's public key, for example — hash it together with your program ID, and you get an address. Anyone who knows the seeds and the program ID can recompute the same address. No lookup table required.

Where the analogy breaks (and you should be honest about this):

PDAs are not stored in a table. They are derived on demand. The address might exist as an on-chain account, or it might not — derivation and initialization are separate steps.
There is no row until you pay rent. Creating an account at a PDA costs lamports (Solana's smallest currency unit; 1 SOL = 1 billion lamports). That payment is called rent, and it reserves space on the chain for your data.
"Deleting" an account is not a SQL DELETE. Closing an account zeros its data, sends the lamports back to a wallet, and the runtime garbage-collects the account at the end of the transaction.

If you hold onto one sentence: a PDA is an address your program can predict, and optionally own, because it was derived from seeds only your program knows how to use.

Anatomy of a derivation

Here is the canonical pattern from my counter program, copied verbatim:

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

Walk through each piece:

seeds = [b"counter", user.key().as_ref()] — This is the logical identity. The first element is a static prefix: a string tag that namespaces this account type inside your program. The second is dynamic: the user's public key, so every wallet gets its own counter. These bytes are concatenated and hashed together with your program ID.

The program ID is not optional. find_program_address (and Anchor's seeds constraint) always includes the deploying program's public key in the hash. The same seed bytes in a different program produce a completely different address. That is a feature, not a quirk.

bump — PDAs must live off the ed25519 curve so they have no private key. The runtime tries bump values 255 down to 0, appending each candidate as an extra seed byte, until the hash result is not a valid curve point. The winning byte is the canonical bump. It is part of the derivation input, not a separate magic number floating beside the seeds.

init — Derivation gives you an address. init actually creates an account there and writes your struct's initial data. Until init runs, the PDA address is just math — no account exists yet.

space = 8 + Counter::INIT_SPACE — Every Anchor account starts with an 8-byte discriminator (so the runtime knows which struct type this is), plus whatever fields you defined. You pay rent proportional to this size.

payer = user — The wallet signing the transaction pays the rent to create the account.

On subsequent instructions, I do not re-derive the bump from scratch. I store it in the account and pass it back:

#[account(
    mut,
    seeds = [b"counter", user.key().as_ref()],
    bump = counter.bump,
    has_one = user,
)]
pub counter: Account<'info, Counter>,

Anchor verifies that counter.bump is the canonical bump for these seeds. If you pass the wrong bump, the transaction fails before your handler runs.

Why the seeds matter

Yesterday I ran a collision exploration script against my deployed program. The output is worth keeping because it makes the seed design concrete.

Per-user counter — seeds: ["counter", wallet_pubkey]

Per-user counter PDAs
  Wallet A PDA: 8Fr8LiP6khZsTcDAeh7Gjvot5TFCbPEDBxuzv7Ju5JMj
  Wallet B PDA: 6ba3KK9vCMYPogDpXrHoS8fYsVxy893vCy7kudwkM4fa
  Same address? false

Alice and Bob each get their own counter. This is what you want when state belongs to one user.

Global counter — seeds: ["counter"] (no wallet)

Global counter PDA (no wallet in seeds)
  Derived from A's perspective: 3VKtGLreXepsZFDnyhFKsCUz9cjy96b1cHXLaYj3XA6z
  Derived from B's perspective: 3VKtGLreXepsZFDnyhFKsCUz9cjy96b1cHXLaYj3XA6z
  Same address? true

Every wallet derives the same address. That is exactly what you want for a global config singleton — my program uses [b"config"] for admin settings and a pause flag. It would be a disaster for a per-user counter, because every user would be mutating the same account.

Near-miss seed variants — change one character and you get a different address entirely:

Near-miss seed variants
  ["counter", walletA]         -> 8Fr8LiP6khZsTcDAeh7Gjvot5TFCbPEDBxuzv7Ju5JMj
  ["counters", walletA]        -> Cre7aNxq6dHKvp68ucUgLfCRzrSNjPNDr2tzyeqMbNcn
  ["counter\0", walletA]       -> FFWPDBuhjXGqALszpVrp9DWJcPLTd4TCoKrk2jpMDAwr
  ["Counter", walletA]         -> 494XwXexJXLpiKk2APhairz1E7KLGp7hiQ4ogQBAQKqf

Seeds are not fuzzy. "counter" and "counters" are different namespaces. "Counter" and "counter" are different. A null byte matters. Treat seed strings like schema migrations: changing them creates a new address, not an updated row.

I also tried to spoof a PDA — pass Wallet B's counter address while signing as Wallet A:

Attempting to spoof a PDA...
  Spoof rejected: AnchorError caused by account: counter. Error Code: ConstraintSeeds. Error Number: 2006. Error Message: A seeds constraint was violated.

The runtime did not care that I knew an address. It recomputed the expected PDA from the seeds and the signer, saw they did not match the account I passed in, and rejected the transaction. That is the whole point of putting seeds in the account constraint.

What the bump buys you

There are 256 possible bump values (255 down to 0). Only one is canonical — the first value that produces a valid off-curve address when tried in that order.

You should always use the canonical bump. Non-canonical bumps might derive valid-looking addresses in some edge cases, but Anchor's seeds constraint expects the canonical one. Passing a wrong bump fails verification.

When you write bump in an init constraint, Anchor finds the canonical bump for you and exposes it as ctx.bumps.counter. Store it in your account struct:

pub struct Counter {
    pub user: Pubkey,
    pub count: u64,
    pub bump: u8,
}

On every later instruction, pass bump = counter.bump instead of re-running the 255→0 search. Re-derivation is cheap in a script and expensive inside a tight on-chain loop. Storing one byte in your account is free by comparison.

The full lifecycle

Here is the sequence my counter program went through over five days, in order:

1. Derive the address (off-chain or in a client)

const [counterPda] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter"), user.toBuffer()],
  program.programId
);

This is pure math. No transaction, no rent, no account yet.

2. Initialize the account at that address

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

The init constraint creates the account, pays rent from the user, writes the discriminator and initial fields.

3. Mutate on subsequent instructions

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

The account already exists. Anchor verifies seeds, bump, and has_one = user before your code runs.

4. Close to reclaim rent

#[account(
    mut,
    close = user,
    seeds = [b"counter", user.key().as_ref()],
    bump = counter.bump,
    has_one = user,
)]
pub counter: Account<'info, Counter>,

close = user does three things: it drains the account's lamports to the user, zeroes the data, and marks the account for deallocation at the end of the transaction. My test logged roughly 1.23M lamports refunded — real money back in the wallet, not a metaphorical row deletion.

One thing that tripped me up: closing is not instant visibility. Within the same transaction the account still exists until the runtime finishes. After confirmation, getAccountInfo returns null. Plan your client code accordingly.

What I would tell past me

The program ID is part of the derivation. Same seeds, different program, different address. Copy-pasting seed logic between programs without updating the program ID will silently point at the wrong account.
PDAs cannot sign transactions on their own. They have no private key. When a PDA needs to transfer tokens or invoke another program, your program signs on its behalf using signer seeds — the same seed bytes plus the bump, passed to invoke_signed. Client wallets sign with a keypair; programs sign for PDAs with seeds.
init_if_needed is convenient and also a footgun. Reach for it deliberately when you genuinely want "create if missing, otherwise use existing." Default to explicit init so you never accidentally overwrite or underpay for an account you thought was new.
Start the local validator before you deploy. Every fetch failed and failed to get recent blockhash error I hit was because nothing was listening on localhost:8899. Terminal 1: solana-test-validator. Terminal 2: everything else.
The seeds constraint and has_one do different jobs. Seeds prove you passed the right account address. has_one proves the data inside that account belongs to the signer. You need both when users own their own PDAs.

Where to go from here

If you are exactly where I was a week ago — program compiles, tests pass, mental model still fuzzy — write your own explainer. Every sentence you cannot finish cleanly is a gap worth filling.

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

Prasiddh Naik — Tue, 23 Jun 2026 11:06:38 +0000

The counter program is small, but the useful part was not the counter. The useful part was learning where state lives, how Anchor turns account validation into Rust types, and how a test suite can prove that a permission check is actually doing work.

Here is the first piece that made Anchor feel different from a normal Web2 backend:

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

In a Web2 handler, I am used to receiving a request body and then deciding what database rows to read or write. In Anchor, the accounts are part of the request. This struct says the counter account should be created, the authority signer pays for that account, and the System Program is available because account creation needs it. The space value reserves enough bytes for Anchor's discriminator plus the fields in my Counter account.

The account itself is tiny: it stores the wallet allowed to update the counter and the current number.

The initialize handler is short because the account plumbing already happened before the body runs:

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

ctx.accounts gives me typed access to the accounts from the Initialize struct. At this point, Anchor has already checked that authority signed, that the counter account can be initialized, and that the right programs are present. My code only has to write the starting state.

The second instruction increments the counter. This is the important part:

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

The key line is has_one = authority. It tells Anchor to compare the authority field stored inside the Counter account with the signer passed into this instruction. If they do not match, the handler body never gets to run.

That was the permission check. The next question was whether my tests could prove it.

The Happy Path

The first test creates a fresh LiteSVM instance, initializes a counter, increments it, then reads the account back. The whole point is this final check:

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

This test would fail if initialize stored the wrong authority, if increment changed the wrong amount, or if the account could not be deserialized back into Counter state.

But happy paths are not enough.

If I only test that the right wallet can increment, I have not proved that the wrong wallet cannot. That is the Solana version of testing that an admin endpoint works but never testing that a non-admin gets rejected.

The Failure Path

So I added a test where authority_a creates the counter and authority_b tries to increment it. The important assertion is:

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

This test would fail if I accidentally removed the has_one = authority constraint or otherwise allowed any signer to increment someone else's counter.

That sentence is the whole reason the test exists.

Breaking It On Purpose

The most useful thing I did was break the program intentionally.

For one experiment, I changed the increment logic from "add one" to "add two":

.checked_add(2)

The transaction still succeeded, but the test caught the wrong state:

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

That is the kind of failure I want. It is clear, specific, and tied directly to the behavior I care about.

I also removed has_one = authority once. Before the failure test existed, the suite stayed green. After the failure test existed, the suite failed exactly where it should:

increment should fail when signed by the wrong authority

That was the moment the permission check stopped being a line I trusted and became a line I could audit by running tests.

What I Learned

Anchor programs are small on the surface, but a lot happens before a handler body runs. The account structs are not just TypeScript-style types or documentation. They are validation rules. They decide which accounts are writable, which accounts must sign, which accounts get initialized, and which relationships must already be true.

I also learned that a green test suite only means something if it tries to prove the program wrong. The happy path proved the counter could work. The failure path proved the authority gate was real. The mutation experiments proved both assertions were load-bearing.

If I had another week, I would add one more failure test for double initialization, tighten the failure assertions to check the exact Anchor error, and then move the counter account to a PDA so the client does not have to create a random keypair for it.

Small program. Real lesson.

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

Prasiddh Naik — Tue, 16 Jun 2026 12:13:34 +0000

If you know SPL tokens but not Token Extensions, here is the short version: Token-2022 is the upgraded Solana token program. At mint creation, you can opt into extensions: fees, interest, transfer rules, and other behaviors that live directly on the mint account. Think of it like middleware baked into the asset. Every wallet and program that touches the token sees the same rules, not a wrapper I wrote on the side.

I shipped three mints on devnet over this arc. Same CLI, three different behaviors.

Mint 1: Transfer Fee

Days: 50 and 51

Mint: 8gSexQr1JF4NeCKRR72nckSUdexmN5ZCuBTVuTfsJdPp

Explorer: View on Solana Explorer

Extension: Transfer fee, configured at 100 basis points, with a max fee of 1,000,000 tokens.

This was the first mint where the token itself started enforcing behavior. I configured a 1% transfer fee and then sent 1000 tokens to a fresh recipient wallet. The recipient received 990 spendable tokens, while 10 tokens sat in the account's withheld fee field until I withdrew them with the fee authority.

The create command:

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

Then I created my token account and minted supply:

spl-token create-account 8gSexQr1JF4NeCKRR72nckSUdexmN5ZCuBTVuTfsJdPp
spl-token mint 8gSexQr1JF4NeCKRR72nckSUdexmN5ZCuBTVuTfsJdPp 1000

The fee lifecycle looked like this:

spl-token transfer \
  --expected-fee 10 \
  $MINT 1000 $RECIPIENT \
  --allow-unfunded-recipient

spl-token display $RECIPIENT_TA
spl-token withdraw-withheld-tokens $MY_TA $RECIPIENT_TA

Where I would use it: a creator token with royalties on secondary movement, a protocol treasury skim, or a community currency where every transfer contributes a small amount back to the project. The important part is that the fee is not enforced by a web server. The Token-2022 program enforces it during transfer.

Mint 2: Transfer Fee Plus Interest

Day: 52

Mint: 6KHkyuc1v8BqZySkEp6wGdAiG26TJnH6h5JGSU91FD7s

Explorer: View on Solana Explorer

Extensions: Transfer fee and interest-bearing.

This mint stacked two behaviors onto the same asset: the same 1% transfer fee, plus an interest-bearing configuration at 5000 basis points. In CLI terms, that is a 50% interest rate.

The create command:

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

After creation, spl-token display showed both extensions:

Extensions
  Interest-bearing:
    Current rate: 5000bps
    Average rate: 5000bps
  Transfer fees:
    Current fee: 100bps

One subtle thing matters here: the interest-bearing extension changes the displayed UI amount over time. It does not mint new supply into existence. After minting 1,000,000 tokens, I watched the account's displayed balance creep upward over about 30 seconds:

1000004.991023
1000005.482204

That distinction is easy to miss. It feels like yield, but it is a Token-2022 display behavior based on the configured rate, not a custom staking program minting rewards.

Where I would use it: savings-style balances, loyalty points that visibly grow, or any token where a wallet-facing balance should accrue over time without a custom program.

Mint 3: Non-Transferable

Day: 54

Mint: DRVQaZxsixMWiUrJxUmwXq6eY6vj1ZjEUz5epgoc25fk

Explorer: View on Solana Explorer

Extension: Non-transferable.

This one flipped the mental model. Instead of making transfers more complex, it disabled transfers entirely.

The create command:

spl-token create-token --program-2022 --enable-non-transferable
spl-token create-account $MINT
spl-token mint $MINT 1

Then I created a recipient account and tried to transfer the token:

spl-token create-account $MINT --owner $RECIPIENT --fee-payer ~/.config/solana/id.json
spl-token transfer $MINT 1 $RECIPIENT --allow-unfunded-recipient

The program rejected it:

Program log: Instruction: TransferChecked
Program log: Transfer is disabled for this mint
Program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb failed: custom program error: 0x25

And spl-token display confirmed the mint-level rule:

Extensions
  Non-transferable

Where I would use it: certificates, proof-of-attendance badges, reputation credentials, or any token that should stay attached to the original holder instead of becoming a tradable asset.

The Audit Habit

Before writing this, I ran spl-token display on each mint and checked the Extensions block. That felt like doing DESCRIBE table after a database migration. I was not trusting the commands I remembered typing. I was reading the public account state that wallets, explorers, and other programs read too.

One practical note: these mints live under the Token-2022 program. If spl-token display <MINT> says an account does not exist, try:

spl-token display <MINT> --program-2022

I hit that exact confusion while testing.

What Surprised Me

The surprising part is how much product behavior can live on the mint itself. Transfer fees felt like something I would normally write in backend code. Interest felt like something I would expect from a staking program. Non-transferability felt like an app-level rule. In Token-2022, all three are mint configuration.

In a real product, I would reach for transfer fees when the asset needs a treasury or royalty mechanism, interest-bearing tokens when the displayed balance should grow over time, and non-transferable tokens when the point is reputation or identity rather than liquidity.

That is the arc I wanted to understand this week: not just how to create a token, but how much behavior can be attached to the token before writing a custom program.

All mints and transactions above are on Solana devnet.

What I learned minting NFTs on Solana with Token Extensions published: true

Prasiddh Naik — Wed, 10 Jun 2026 11:48:12 +0000

Before this week I thought a Solana NFT was a Metaplex thing. It turns out you can mint a full NFT — with metadata, a collection, and live updates — using just the Token Extensions program and the spl-token CLI.

The mental model

If you already understand SPL tokens, an NFT is the same program with tighter rules: 0 decimals (nothing to split), supply capped at 1, and mint authority disabled when you are done so no one can ever inflate it. Uniqueness is enforced by token math, not by a is_nft flag.

The Metadata extension stores name, symbol, and URI directly on the mint account — no separate Metaplex metadata account. The URI points at a JSON file hosted somewhere public; that JSON holds the image URL and attributes. Wallets and Solana Explorer read the on-chain fields, fetch the JSON, render the art.

Collections use the Group and Member extensions: one mint is the collection (group), each NFT mint points back to it (member). Web2 analogy: a collection_id foreign key stamped into the row — except there is no central database to join against.

What I built

Over Days 44–47 on devnet I went from a named NFT to a collection I could inspect and patch live.

1. NFT with on-chain metadata. I minted Black Box Oracle (ORCL) on Token-2022 with --enable-metadata, pointed the URI at a gist JSON file, minted one token, and disabled mint authority.

export TOKENZ=TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

spl-token create-token --program-id $TOKENZ --enable-metadata --decimals 0 ./nft....json
spl-token initialize-metadata <MINT> "Black Box Oracle" "ORCL" "<GIST_RAW_URL>"
spl-token mint <MINT> 1
spl-token authorize <MINT> mint --disable

Mint: Nft5CnhQbXUjvce9RGux9BVJwdH8QNGZgqoQtQ2KJeJ

2. A collection with two members. Solana Sketchbook (SKTCH) uses --enable-group; each sketch uses --enable-member. Both flags must be set at mint creation — you cannot bolt them on later.

spl-token initialize-group <COLLECTION> 3
spl-token initialize-member <MEMBER> <COLLECTION>

Collection: 6CBzxZ96JX87hhVbrr7NdyiXSneeTbVW2mTHCExGFVbg · Members: Sketch #1 · Sketch #2. Group shows size: 2, max_size: 3.

3. An on-chain audit. I ran spl-token display on the member and collection mints and verified extension blocks, supply, and that TokenGroupMember → Group matched the collection address byte-for-byte. Same habit as querying a row after a migration — trust the CLI output, not just the Explorer UI.

4. Live metadata edits. While I still held update authority, I renamed Sketch #1 to Field Notes, added and removed a custom rarity field, and pointed the URI at new JSON — each change one transaction, visible in Explorer within a slot.

The surprising part

Extensions are schema decisions. Group and member must be declared when you create the mint. I could not retro-fit my metadata NFT into the Sketchbook collection afterward.

Three layers, three speeds. Name and URI update on chain immediately. The image lives off chain and wallets cache it aggressively — Explorer showed "Field Notes" while Phantom still showed the old art.

No separate NFT program. Collectibles are SPL Token plus a small set of extensions. Metaplex Core is still the common marketplace path; Token Extensions is the native SPL stack when you want metadata and grouping inside the token program itself.

What Token Extensions Finally Made Me Understand

Prasiddh Naik — Thu, 04 Jun 2026 11:09:02 +0000

Subtitle: Token-2022 showed me that tokens can have rules, not just balances.

This week I moved past basic SPL tokens and started using Token Extensions.

At first, I thought a token was mostly just:

a mint
token accounts
balances
transfers

But Token-2022 adds something more interesting: behavior.

A token can charge transfer fees.
A token can display interest over time.
A token can start every account frozen.
A token can be non-transferable.
A token can have a permanent delegate for revocation.

That made tokens feel less like simple coins and more like product systems.

Interest-bearing tokens

The first extension that clicked was interest-bearing tokens.

The weird part is that the raw balance does not actually grow. If I mint 1000 tokens, the account still holds 1000 tokens. The interest-bearing extension changes the UI amount by applying an interest formula over time.

So it feels like a savings account, but without a backend cron job constantly minting more tokens.

That was the first “ohhh” moment.

Multi-extension tokens

Then I tried combining extensions.

One mint could have:

transfer fees
interest
metadata

That means the token can charge a fee when it moves, display an interest-adjusted balance, and carry its name, symbol, and URI.

The important lesson: extensions must be planned before the mint is created. You cannot just bolt them on later like a random npm package. Annoying, but fair.

Here is the kind of command I used:

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

That creates a Token-2022 mint with multiple extensions enabled.

Default frozen accounts

The default frozen account extension felt like a compliance system.

Every new token account starts frozen. The authority has to thaw an account before it can receive, send, or burn tokens.

In Web2 terms, it is like saying:

“You can have an account, but you cannot use it until you are approved.”

That makes sense for regulated assets, gated communities, or tokens where both sender and receiver need permission.

Inspecting mints

One of the best lessons was not building, but reading.

Using:

spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

I could inspect which extensions were active on a mint.

That made me realize extension configuration is like reading a project’s config file. Before trusting a token, you should check its rules.

Does it have fees?
Who controls the fee authority?
Is there a freeze authority?
Is there a permanent delegate?

The token’s behavior is part of the trust model.

Revocable credentials

My favorite idea was combining:

non-transferable tokens
permanent delegate
metadata

That creates something like a certificate.

The token cannot be transferred, so the holder cannot sell it or send it to someone else. But the issuer can still revoke it by burning it through the permanent delegate.

That makes sense for:

course certificates
badges
memberships
licenses
reputation tokens

This was the moment Token Extensions felt less like “crypto stuff” and more like actual product design.

Token Extensions are not random features.

They are rules.

Transfer fees decide what happens when value moves.
Interest-bearing extensions decide how balances are displayed.
Default frozen accounts decide who is allowed in.
Non-transferable tokens decide whether something can be sold.
Permanent delegates decide who can revoke or control tokens.

The big lesson: with Token-2022, the token program can enforce behavior that an app would normally need to manage itself.

That is powerful.

Also slightly terrifying.

Because once these rules exist, users need to know what they are holding.

Tags: #solana #web3 #learning #100daysofsolana

Solana Token Extensions: Fees and Metadata

Prasiddh Naik — Tue, 26 May 2026 14:48:24 +0000

Over five days on devnet I went from a basic mint to on-chain metadata, transfer fees enforced by the Token-2022 program, a full lifecycle run without notes, and a non-transferable credential token. The throughline: token behavior is configured at the mint, not patched in later.

This post is what I wish I had read before I started.

Starting point

I already had Solana accounts, wallets, and SOL transfers down. Tokens were the next layer.

The Token Extensions Program (Token-2022) attaches capabilities to the mint account at creation time. Transfer fees, metadata pointers, non-transferability — you opt in with CLI flags when you run create-token. You cannot add those extensions after the fact.

Plan the token's rules before you mint.

Token Program vs Token Extensions

Solana has two token programs:

Program	Address (short)	What I used it for
Original SPL Token	`TokenkegQfeZyiNw...`	Classic fungible tokens
Token Extensions (Token-2022)	`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`	Metadata, transfer fees, non-transferable mints

If you want extensions, opt in at mint creation:

--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Lesson I learned the hard way: after creating a Token-2022 mint, pass --program-2022 (or --program-id TokenzQd...) on every follow-up spl-token command. I hit AccountInvalidOwner on initialize-metadata until I added that flag. The CLI defaults to the original Token Program unless you tell it otherwise.

Day 29–30: Mint and metadata

The first step is boring on purpose — create a mint, create an associated token account, mint supply:

solana config set --url devnet
solana balance

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

That gives you a fungible token. Wallets and explorers can show a balance, but without metadata it is just an address with decimals.

Token-2022 lets you attach identity on-chain:

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

spl-token initialize-metadata <MINT> "MyToken" "MTK" \
  "https://example.com/metadata.json" \
  --program-2022

Name, symbol, and URI live in the mint's extension data. Explorers and wallets read them directly from chain state.

Order matters: initialize metadata before you mint large supply if your workflow depends on a fully configured mint from the start.

Day 31: Transfer fees at the protocol level

This is where Token Extensions stopped feeling like "SPL Token plus extras" and started feeling like a different design surface.

I created ReinforceCoin (RFC) with a 2% transfer fee (200 basis points):

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

Mint: 8rVUkh7tbh1uR9GMbAZYZeFQ3EZ8Tkqu5nh3kToSAZ7a

After metadata, I minted 1000 tokens to my wallet, created a token account for a second devnet wallet (second-wallet.json), and transferred 100 tokens:

spl-token transfer --fund-recipient <MINT> 100 <RECIPIENT_PUBKEY> \
  --expected-fee 2 \
  --allow-unfunded-recipient \
  --program-2022

The recipient balance was 98, not 100. Two tokens were withheld as fees — enforced by the Token-2022 program during TransferChecked, not by anything I wrote in a script.

Every transfer through this mint pays the same fee. Wallets, DEXs, and CLI tools all hit the same on-chain rule.

To collect withheld fees, the mint authority withdraws from the recipient's token account:

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

Fees accrue on transfer and get collected in a separate step. That two-phase flow was not obvious from the docs alone.

Day 32: Reinforcing the full lifecycle

Day 32 was deliberately repetitive: run the entire flow in one sitting without notes. Create mint → metadata → mint supply → fund recipient → transfer with fee → withdraw withheld → verify with spl-token display.

Muscle memory, not trivia.

The commands that stuck:

spl-token display <MINT> --program-2022 — extensions, fee config, authority
--expected-fee on transfer — CLI sanity-checks your math against on-chain rules
Token account addresses vs mint addresses — see below

Day 33: Non-transferable tokens (soulbound credentials)

For credentials, diplomas, or achievement badges, you want the chain to reject transfers — not a UI warning.

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

Mint: Gvztbeuf4Szs9KDvXxHkzRGPEsnf895FozQPoTnUPipu

I minted 10 tokens to my ATA (5abnDEFHy5Btm2kyazagTaiaQaXUv4bStZusw69jndS3) and tried to send 5 to an experiment wallet. The transaction failed in simulation:

Program log: Transfer is disabled for this mint
custom program error: 0x25

That failure was success. The Token-2022 program enforces non-transferability — no workaround at the client level.

Burning still worked. I reduced my balance from 10 to 7 by burning from the token account, not the mint:

# Wrong — mint address is not a token account
spl-token burn Gvztbeuf4Szs9KDvXxHkzRGPEsnf895FozQPoTnUPipu 3 ...

# Right — pass the ATA that holds your balance
spl-token burn 5abnDEFHy5Btm2kyazagTaiaQaXUv4bStZusw69jndS3 3 \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Address	Role
`Gvztbeuf...`	Mint — token definition
`5abnDEFH...`	My associated token account — holds balance
`5K6a2t28...`	Experiment wallet's token account

Confusing mint with a token account is an easy mistake to make. The CLI error messages nudge you toward the right object, but knowing the account model saves time.

What surprised me

Rules are chosen at birth. Extensions are set when the mint is created. Plan the economics before you mint.
Fees are withheld, not instantly routed. Transfer fees sit in recipient token accounts until someone with authority runs withdraw-withheld-tokens.
Non-transferable does not mean frozen. I can still mint and burn. I just cannot move balances between owners — which is exactly what you want for credentials.
The --program-2022 flag is load-bearing. Same CLI, different program owner. Forgetting the flag produces errors that look like corruption but are just wrong program IDs.
Write down addresses as you go. Mint, your ATA, recipient ATA — each step prints new ones. I lost time re-deriving them from transaction logs.

Useful references while you work: Tokens on Solana, Token Extensions, and the SPL Token CLI.

Solana Mental Model for Web2 Developers

Prasiddh Naik — Sun, 17 May 2026 12:02:14 +0000

If you come from Web2 development, the easiest way to understand Solana is to stop thinking about contracts first and start thinking about accounts.

On Solana, almost everything is an account. A wallet is an account. A token balance is an account. A program which is Solana's version of a smart contract is also an account. Instead of storing application state in a database table or inside a contract object, Solana stores state in accounts that live on-chain.

A Solana account is like a file in a filesystem. It has an address, some metadata, and some contents. The address is a 32-byte public key. The metadata tells you who owns it, whether it is executable, and how much SOL it holds. The contents are just raw bytes.

Every Solana account has five core fields:

{
  "lamports": 1000000000,
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rentEpoch": 18446744073709551615,
  "data": []
}

lamports are the account's SOL balance. One SOL equals one billion lamports.

data is a byte array. This is where programs store custom state. A normal wallet account usually has zero bytes of data. A token account or NFT metadata account has structured data inside this field.

owner is the program that controls the account. This is one of the most important ideas in Solana. Only the owner program can modify an account's data or debit its lamports.

executable tells you whether the account is a program. If it is true, the account contains executable program code. If it is false, it is a regular data account.

rentEpoch is a legacy field. Today, accounts are generally rent-exempt, and this field is usually set to the maximum value.

The ownership rule is Solana's security model in one sentence: only the owning program can change an account's data. For example, your wallet is owned by the System Program, so the System Program handles SOL transfers. Token accounts are owned by the Token Program, so only the Token Program can move tokens or update token balances.

The part that surprises many Web2 developers is that Solana programs do not store their own state. Programs are stateless. A program account stores executable code, while separate data accounts store the actual application state.

A useful analogy is a web server and a database. The program is like the backend server: it contains the logic. The accounts are like database records: they contain the data. When a transaction runs it tells the program which accounts it wants to read or write.

This is different from Ethereum, where a smart contract usually owns both the code and the state together. On Solana code and state are separated. That separation is one reason Solana can process many transactions in parallel. If two transactions touch different accounts, they can often run at the same time.

There is also the idea of rent exemption. Because account data takes space on-chain accounts must hold a minimum SOL balance based on their size. This keeps the account alive. For a basic account with no extra data, the rent-exempt amount is small roughly around 0.00089 SOL. You can calculate exact values with the Solana CLI or the getMinimumBalanceForRentExemption RPC method.

So the mental model is simple:
Solana is a giant public key-value store. The key is an account address. The value is an account object with balance, owner, executable status, and raw data. Programs are accounts that contain code. Data accounts are accounts that contain state. The owner field decides who is allowed to modify what.

Once this clicks, the rest of Solana starts to make more sense. Tokens, NFTs, DeFi protocols, staking, governance, and games all use the same basic building block: accounts.

Solana Transactions Cost Money Even When They Fail

Prasiddh Naik — Sat, 09 May 2026 11:50:55 +0000

Here's what I learned in 3 weeks: failed transactions on Solana cost real SOL.

The Surprise

As a backend dev, I'm used to failed requests being free. A 500 error? Retry it. It's no big deal.

Solana is different. When you send a transaction, three things can happen:

CLI catches it → Free (local balance check)
Simulation catches it → Free (RPC preflight check)
On-chain fails → Costs 0.000005 SOL

Watching It Happen

I created a broke wallet (0 SOL) and tried to transfer:

solana transfer --from /tmp/broke-wallet.json $RECIPIENT 1
# Error: insufficient funds (caught locally, free)

Then I used a funded wallet but tried to send more than my balance:

// With skipPreflight = true (dangerous)
await rpc.sendTransaction(tx, { skipPreflight: true });

Result:

Signature: 5NWqdwSCmc3vz2PAwMmBQppL6uogPB7qkRWzUnCFtA9...
Status: Error processing Instruction 0: custom program error: 0x1
Fee: ◎0.000005
Balance: 8.39795 -> 8.397945 SOL

The transaction failed. The fee was still charged.

Why This Matters

In Web2, validation happens before the operation:

if (account.balance >= amount) {
  await db.transfer(account, recipient, amount);
}

In Solana, validation happens inside the transaction. The blockchain doesn't check first—it tries to execute and fails if conditions aren't met. The attempt itself is a processed transaction.

The Fix

Always simulate before sending:

// Default: skipPreflight = false (simulates first)
await rpc.sendTransaction(tx, { skipPreflight: false });

And check balances client-side:

const balance = await rpc.getBalance(sender).send();
if (balance.value < amount + fee) {
  throw new Error("Insufficient funds");
}

Bottom Line

On Solana, there's no "try it and see." Every attempt that reaches the network costs money. Design your error handling accordingly.

Day 19 of 100 Days of Solana. Full code: [https://github.com/prasiddhnaik/solana-100-days]

Tags: #solana #web3 #blockchain #backend

BharatZero

Prasiddh Naik — Fri, 08 May 2026 12:34:30 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

BharatZero is an India-focused legislative explorer that aggregates parliamentary data spanning 1947 to the present into a unified, searchable platform. The app solves a critical transparency problem: India's legislative information is scattered across dozens of government portals (Sansad, PRS Legislative Research, Parliament Digital Library, Data.gov.in), hidden in PDFs, and nearly impossible to navigate comprehensively.

BharatZero brings it all together:

4,708 bill records from three different official sources
7,253 timeline events tracking parliamentary activity
2,560 sitting days with chronological browsing
Prime Minister term filtering—see what legislation passed during any PM's tenure
Complete source attribution for data provenance

The platform features eight sections: Overview, Houses (with Lok Sabha power charts), Timeline, Bills, Committees, Debates, Acts, and Sources. Every record shows exactly where it came from—critical for democratic transparency.

Demo

bharatzero.vercel.app

Code

prasiddhnaik / Bharat0

BharatZero

BharatZero is an India-focused legislative explorer for bills, Acts, Parliament timelines, House power, Prime Minister terms, and official source coverage. It is built as a Vite/React frontend with a small Node API server, Prisma, and PostgreSQL/Neon.

The current app is no longer just a static prototype. It uses generated legislative datasets plus a Prisma-backed repository path for runtime data.

Current Coverage

Generated local datasets currently include:

4,708 Bill records
7,268 Bill action records
7,253 timeline events
2,560 sitting days
217 Act records
15 Prime Minister profile records
16 Lok Sabha power snapshots

Main source families:

Sansad legislation data, as of 2026-04-25
PRS historical bill data, 1992-2019
Parliament Digital Library bill/proceeding data, 1947-2003
Curated Prime Minister profile data from PM India
Curated Lok Sabha power snapshots from ECI/IPU-style election summaries

The PDL sync now covers older Prime Ministers, including Nehru, Shastri, Nanda, and Indira Gandhi-era windows where source records exist.

…

View on GitHub

How I Used Gemma 4

I chose Gemma 4 31B Dense (gemma-4-31b-it) via the Gemini/OpenAI-compatible API for bill analysis generation. Legislative bills are dense, technical documents—often 50+ pages of legal language. Citizens, journalists, and researchers need accessible summaries, but manual summarization doesn't scale across 4,700+ bills.

BharatZero uses Gemma 4 to generate plain-language summaries, economic impact analysis, key provisions extraction, and social implications analysis. The model handles the bilingual nature of Indian legislation seamlessly—bill titles and summaries work in both English and Hindi contexts without separate model tuning.

Analysis is expensive, so BharatZero implements a persistent cache layer. Once a bill is analyzed, results are stored in PostgreSQL. Subsequent requests serve cached results instantly.

Why Gemma 4 31B Dense was the right fit:

Long context: Bills are lengthy documents; Gemma 4 handles full text input
Structured output: Returns consistent JSON for parsing into the UI
Factual accuracy: Critical for legislative analysis—hallucinations are dangerous
Cost efficiency: More economical than alternatives for high-volume batch analysis

solana notes - week 2

Prasiddh Naik — Wed, 06 May 2026 14:26:30 +0000

100DaysOfSolana

i've used normal databases for years, so i kept trying to force solana into that shape. tables, rows, queries. some of that helps, a lot of it breaks.

what surprised me

reading a balance is stupidly simple:

const { value: balanceInLamports } = await rpc
  .getBalance(targetAddress)
  .send();

the code is easy. the mental model is what's hard.

the click moment

ran solana account $(solana address) and saw my wallet data. then realized: anyone can do this. no api keys, no auth. just the public key and you're reading someone's balance.

that's uncomfortable in a good way. in web2 data is hidden unless i expose it. here it's visible unless i design around it.

the sdk

@solana/kit feels normal. not crusty like i expected. async/await, clean imports. the devnet() and mainnet() wrappers aren't just for show—they actually tag the network for type safety. someone thought about DX.

where the database comparison breaks

normal thinking	solana reality
sql joins	lol no. fetch signatures, then fetch details
private by default	public by default
i control who reads	everyone reads
alter table, migrations	nope. design upfront, serialize to bytes

i keep wanting SELECT * FROM transactions WHERE user_id = 123. instead:

const signatures = await rpc
  .getSignaturesForAddress(address, { limit: 5 })
  .send();
// then fetch each one i guess

more manual. that's the tradeoff.

devnet vs mainnet hit different

--- Devnet ---
Balance : 0.001159846 SOL

--- Mainnet ---
Balance : 0.069875097 SOL

same address, same code, different world. staging vs production except anyone can view production.

still fuzzy on

PDAs - when do i actually use them vs regular accounts?
rent - deposit not fee, but the exact economics? need to build something that creates/closes accounts
cross-program calls - just words to me right now
writing transactions - reading is safe. writing feels serious. nervous about it.

send a simple transaction
one PDA example end to end
build something that actually writes, not just reads

where i'm at

day 12. not an expert. but less intimidated.

the code looks familiar while the assumptions underneath are totally different. public data by default. accounts instead of tables. pay for storage not queries. still rewiring my brain.

if you're also confused by accounts, PDAs, or why everything is public: same. i think that's just part of it.

What Does "Identity" Actually Mean on a Blockchain?

Prasiddh Naik — Sat, 25 Apr 2026 11:17:13 +0000

If you've been writing code for a while, you've probably used SSH keys. You generate a key pair, drop the public key on a server, and from that point on, you prove who you are by holding the private key. No username, no password reset. You either have the key, or you don't

Solana identity works on the same principle: you have the key, or you don't — except that, instead of a single server, it's the entire network.

The problem with Web2 identity

In Web2, you have no power; you're just renting space. You don't control your GitHub or Google accounts; the company does. They give you access, but they can also take it away.

Even when it feels like yours, it isn't. Your email address exists because Google or Microsoft allows it to.

How Solana does it differently

On Solana, your identity starts with a single cryptographic keypair — a public key and a private key. The public key is your address, something like 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5. That's what the world sees. The private key never leaves your wallet, and it's the only thing that can authorize actions on your behalf.

No company issues this key pair. No server stores it. You generate it yourself, you hold it, and it works across every application on the Solana network without asking anyone's permission. There's no sign-up form, no email verification, no "log in with Google." Your keypair is your identity, and it's yours in a way that a Web2 account never is.

Ownership that actually means something

Here's the part that takes a moment to sink in: on Solana, only the holder of the private key can sign transactions for an account. Not a company. Not an admin. Not a support team. There's no password reset flow, no "verify your identity" email, no override. If you hold the private key, you control the account. If you lose it, it can't be recovered.

That sounds scary, and it is if you're careless. But it also means no one can lock you out of your own account. No platform ban, no policy change, no company going bankrupt takes your identity with it. The tradeoff is real responsibility — but so is real ownership.
What this identity actually unlocks

On-chain identity isn't just a replacement for a username. Because it's cryptographic, it becomes the foundation for everything else on the network. Token ownership is tied to your keypair. When you vote in a DAO governance proposal, your keypair is the vote. When you interact with a program, your keypair authorizes it. When you build a reputation across DeFi protocols or NFT platforms, it all traces back to the same address.

In Web2, your reputation on GitHub doesn't carry over to LinkedIn, which doesn't carry over to your bank. Each platform starts from zero. On Solana, your keypair is consistent across the entire ecosystem. Any application can read your on-chain history without you having to re-verify anything.