DEV Community: Mubarak Yakubu

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.