DEV Community: Mubarak Yakubu

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.