DEV Community: Mubarak Yakubu

My Solana Program Security Checklist

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

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

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

1. Account Validation

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

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

2. Authority and Signer Checks

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

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

3. Arithmetic Safety

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

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

4. CPI Safety

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

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

5. Account Lifecycle

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

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

6. Pre-Deploy Hygiene

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

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

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

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

CPIs on Solana: From Confusion to Confidence

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

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

The mental model

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

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

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

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

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

A real code snippet

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

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

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

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

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

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

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

What tripped me up

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

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

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

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

Closing

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

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

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

Understanding Solana PDAs: A Web2 Developer's Guide

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

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

What a PDA actually is

In Web2, a database primary key is computed from a row's logical identity — user_id, order_id, something the system already knows. You never look up a row by a random UUID you can't derive. PDAs work the same way, except the database is the entire Solana account model, the key derivation is a hash, and the program ID is baked in so only your program can sign for it.

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

Anatomy of a derivation

Here's the canonical pattern from my counter program:

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

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

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

Why the seeds matter

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

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

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

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

What the bump buys you

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

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

The full lifecycle

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

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

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

What I would tell past me

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

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

Resources

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

If you want to go deeper, start here:

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

My code is on GitHub.

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

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

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

The accounts struct:

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

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

The initialize handler:

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

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

The increment handler:

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

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

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

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

The happy-path test:

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

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

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

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

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

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

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

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

The failure test:

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

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

    let counter = Keypair::new();

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

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

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

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

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

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

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

What I Learned Minting NFTs on Solana with Token Extensions

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

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

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

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

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

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

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

Over three days, I minted:

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

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

Here's how the collection + member flow works:

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

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

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

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

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

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

I mutated my NFT live on devnet:

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

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

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

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

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

What I'd build next

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

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

The takeaway

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

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

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

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

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

Resources

solana.com

Official Solana documentation on token extensions and their use cases

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

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

SPL Tokens and Token Programs | Understanding Solana Tokens

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

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

You Already Understand Token Extensions.

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

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

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

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

What are Token Extensions?

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

There are two Token Programs on Solana:

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

Extensions I used:

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

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

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

This creates a token with:

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

Then add metadata so wallets can display your token properly:

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

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

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

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

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

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

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

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

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

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

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

The Basic Mint

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

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

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

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

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

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

Giving It an Identity

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

I needed a name, symbol and URI.

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

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

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

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

One mint. Multiple extensions possible. No separate accounts.

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

Adding Transfer Fees

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

On Solana, it's a flag.

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

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

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

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

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

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

Only the withdrawal authority (me) could collect it.

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

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

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

Soulbound Tokens

Not all tokens should be transferable.

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

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

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

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

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

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

But I could still burn them.

spl-token burn <ACCOUNT> 3

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

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

What Surprised Me

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

What's Next

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

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

Follow along. I'm documenting everything.

Solana Accounts for Web2 Developers (You Already Understand Files)

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

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

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

One model. No exceptions.

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

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

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

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

$ solana account 8CtdyqtzBd597eDz9PTZHuuT62vvLc6YXdXjVkHnboqj

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

Who owns what matters

The owner field determines control.

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

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

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

Programs have no memory

This was the hardest shift.

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

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

State lives in separate data accounts.

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

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

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

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

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

$ solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

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

Rent isn't rent

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

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

It's a deposit. Not monthly rent.

You already know this

A file has a name, contents, and permissions.

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

Same pattern. Different environment.

Took me a few weeks to stop overcomplicating it.

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

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

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

Wrong.

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

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

The Limit

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

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

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

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

Why I Hit the Wall

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

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

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

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

The Escape

I learned about Address Lookup Tables (ALTs).

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

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

Same concept.

What Changed

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

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

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

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

What I Learned

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

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

This forces constraints:

List every account upfront

Batch operations need ALTs

Complex DeFi requires careful design

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

Two Weeks of Solana: Familiar but Different

Mubarak Yakubu — Sun, 17 May 2026 06:35:08 +0000

I came into this with small Web3 experience. Most of the early lessons felt normal, familiar. But the "everything is an account" model on Solana took extra attention. It's not like a traditional database at all.

What surprised me: the publicity and decentralized aspects. No API keys. No permission to read. Just an RPC endpoint and an address. Compared to traditional APIs, it's easier and faster. No restrictions. No rate limits. Just query and get data.

What's next? Nothing specific I'm unsure about yet. I want to start building a real project on Solana using my Web2 expertise. Two weeks in. Ready for the next phase.

Solana Identity for Web2 Developers: You Already Understand Keypairs.

Mubarak Yakubu — Sun, 10 May 2026 00:10:42 +0000

If you've ever generated an SSH key pair, you already understand Solana identity.

ssh-keygen -t ed25519

That command gives you two things:

id_ed25519.pub (public key) → put this on servers
id_ed25519 (private key) → stays on your machine

When you SSH into a server, you prove your identity by signing a challenge with your private key. The server verifies the signature using your public key. Your private key never leaves your machine.

Solana works exactly the same way. But instead of one server, the entire network verifies your signature. Instead of just SSH access, your keypair gives you ownership over tokens, programs, and data across every app on Solana.

What a Solana address actually is
A Solana address is a 32-byte Ed25519 public key, encoded in Base58. Example:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5
Compare that to a Web2 username stored in a database. A company granted you that username. They can revoke it, change it, or lock you out. Your Solana address needs no permission from anyone. It exists because the math says it exists.

On Solana, the only person who can sign transactions for an address is the holder of the private key. No company. No admin panel. No "forgot password" flow.

This is liberating and terrifying. Liberating because no one can take your assets. Terrifying because if you lose your private key, no one can give it back.

That's why wallets exist: to manage private keys securely.

What on-chain identity enables
A keypair isn't just for logging in. Everything you do on Solana ties back to your address:

Token ownership → your address holds NFTs or fungible tokens
Program interactions → you call smart contracts
Governance → your tokens vote on DAO proposals
Reputation → other addresses see your on-chain history

And because it's cryptographic and self-custodied, it works across every application on the network without asking permission.

The mental shift

Web2 identity is borrowed. Solana identity is owned.

When you "Sign in with Google," you're asking Google to vouch for you. When you sign a transaction with your Solana wallet, you prove your identity directly to the network.

This is the shift that unlocks everything else in Web3. No intermediaries. Just math.

DEV Community: Mubarak Yakubu

My Solana Program Security Checklist

1. Account Validation

2. Authority and Signer Checks

3. Arithmetic Safety

4. CPI Safety

5. Account Lifecycle

6. Pre-Deploy Hygiene

CPIs on Solana: From Confusion to Confidence

The mental model

A real code snippet

What tripped me up

Closing

Understanding Solana PDAs: A Web2 Developer's Guide

What a PDA actually is

Anatomy of a derivation

Why the seeds matter

What the bump buys you

The full lifecycle

What I would tell past me

Resources

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

What I Learned Minting NFTs on Solana with Token Extensions

What I'd build next

The takeaway

Resources

SPL Tokens and Token Programs | Understanding Solana Tokens

You Already Understand Token Extensions.

What are Token Extensions?

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

The Basic Mint

Giving It an Identity

Adding Transfer Fees

Soulbound Tokens

What Surprised Me

What's Next

Solana Accounts for Web2 Developers (You Already Understand Files)

One model. No exceptions.

Who owns what matters

Programs have no memory

Rent isn't rent

You already know this

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

The Limit

Why I Hit the Wall

The Escape

What Changed

What I Learned

Two Weeks of Solana: Familiar but Different

Solana Identity for Web2 Developers: You Already Understand Keypairs.