Three Token-2022 Mints in One Week: Fees, Yield, and Soulbound

If you come from Web2, you probably think of a token as a number in a database that moves around when people transact. On Solana, the original SPL Token program is exactly that. Token-2022 is the upgrade — and it lets you bolt behaviors directly onto the mint itself, the way you would add middleware to a payment pipeline, except the middleware lives inside the asset and cannot be bypassed.

This week I shipped three different mints on Solana devnet, each

demonstrating a different Token-2022 extension. Here's what I built, the exact commands I ran, and when you'd actually reach for each one.

Mint 1: Transfer Fee (Days 50–51)

Mint address: ACvRnk4m9fDji76fq74n7Nzwo6tUcPyajmgi3jX9BY1Q

View on Solana Explorer

Extension: TransferFeeConfig

spl-token create-token \

  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \

  --decimals 6 \

  --transfer-fee-basis-points 100 \

  --transfer-fee-maximum-fee 1000000

This creates a mint where every transfer automatically withholds 1%

(100 basis points) into the recipient's account. The recipient can't spend the withheld amount — only the withdraw authority (whoever created the mint) can sweep it out.

When you'd use this: Protocol treasury fees, creator royalties on

a community token, or a skim on every transaction in a marketplace.

The fee logic is enforced by the Token-2022 program itself. No wallet, no dApp, no smart contract can route around it.

After creating the mint, I transferred 1,000 tokens to a second wallet:

spl-token transfer \

  --expected-fee 10 \

  $MINT 1000 $RECIPIENT \

  --allow-unfunded-recipient

The --expected-fee 10 flag is a safety check — the transfer aborts if the calculated fee doesn't match. Out of 1,000 tokens sent, the recipient received 990. Ten tokens sat withheld in their account until I swept them:

spl-token withdraw-withheld-tokens $MY_TOKEN_ACCOUNT $RECIPIENT_TOKEN_ACCOUNT

My final balance: 1,000,010 tokens. That extra 10 is the fee I collected.

Mint 2: Transfer Fee + Interest (Day 52)

Mint address: A2qxipYpyY4gs1BAwv45U88Uj9RuuseEwCiB3s76ZB2J

View on Solana Explorer

Extensions: TransferFeeConfig + InterestBearingConfig

spl-token create-token \

  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \

  --decimals 6 \

  --transfer-fee-basis-points 100 \

  --transfer-fee-maximum-fee 1000000 \

  --interest-rate 5000

One command. Two extensions. Both baked into the same mint account.

What the interest extension actually does — and doesn't do:

This is the part I wish someone had told me upfront. The

InterestBearingConfig extension does not mint new tokens over

time. Your raw on-chain balance never changes. What changes is the displayed (UI) amount — a formula applied on the fly using the stored rate and the network's clock:

UI Amount = raw_balance × e^(rate × elapsed_years)

It's a view, not a balance update. No transaction runs. No new tokens appear. The number you see in a wallet grows because the display formula grows — not because your account data changed.

To make the effect visible quickly I used 50% APR (5,000 basis

points). Two snapshots 30 seconds apart:

Snapshot 1: 1,000,000.069191 tokens

Snapshot 2: 1,000,000.544703 tokens

Growth:     +0.475512 tokens in 30s

No transaction ran between those two reads.

When you'd use this: Yield-bearing stablecoins, savings-style

tokens, or any token where you want the displayed value to grow as a function of time without actually minting supply on a schedule.

Mint 3: Non-Transferable / Soulbound (Day 54)

Mint address: 39eGRkFWbb52icCEdoaqSRtjH257KGHhhssZ2J3b2RdA

View on Solana Explorer

Extension: NonTransferable

spl-token create-token \

  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \

  --enable-non-transferable

This mint produces tokens that cannot be sent anywhere. Once a token lands in a wallet, it stays there. The holder is the holder forever.

I minted one token to myself, created a recipient wallet, then tried to transfer:

spl-token transfer $MINT 1 $RECIPIENT --allow-unfunded-recipient

The response:

Error 0x25: NonTransferable — token program rejected transfer

Transaction simulation failed: Error processing instruction

That error didn't come from my code. It didn't come from a smart

contract I wrote. It came from the Token-2022 program refusing the instruction. My balance was unchanged. The token was still with me.

When you'd use this: Course completion badges, KYC verification tokens, DAO membership credentials, employee IDs. Anything where the value comes from who holds it, not from being tradeable.

In Web2, you'd enforce this at the application layer — a database

constraint, an API check. Someone who talks to the database directly can bypass that. On Solana the rule is inside the program that owns the asset. There is no around.

What the Audit Taught Me

On Day 53 I ran the Solana equivalent of DESCRIBE against all three mints — reading every extension the protocol sees on each account:

spl-token display $MINT_ADDRESS

The output confirmed everything I had configured was actually there.

But the more interesting thing was the account sizes:

56 bytes more for the second extension. Those bytes cost SOL in

rent-exempt deposits. Extensions are not free. You choose them

deliberately at mint creation time — and you can't add them later.

That constraint forces upfront design in a way I actually appreciate.

What Surprised Me

The thing I expected least: extensions are completely independent.

The transfer fee operates on the raw token amount. The interest

display formula also operates on the raw amount. They don't interfere with each other at all. I kept expecting some interaction, some edge case where they'd conflict. There isn't one. Two different TLV entries in the same byte buffer, each doing its own thing, neither knowing the other exists.

The thing I'd reach for in a real product: NonTransferable +

metadata on a single mint. A credential system where the badge is

self-describing (name, issuer, URI) and permanently bound to the

wallet that earned it. No backend. No revocation list. Just a token with rules baked in.

Resources

• Token-2022 extensions overview


• Transfer Fee extension docs


• Interest-Bearing extension docs


• Non-Transferable extension docs

This post is part of *#100DaysOfSolana*. Building on devnet every day — follow along or jump in any time.