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.