As a Web2 developer, I naturally compare new technologies to tools I've already used.

After spending a week exploring Solana's Token-2022 program, I realized the best analogy is middleware.

Instead of wrapping requests, you're wrapping assets.

With Token-2022 extensions, behaviors that would normally require custom smart contracts can be attached directly to a token mint. Over the past few days, I created three different Token-2022 mints on devnet and experimented with transfer fees, interest accrual, and non-transferability.

Day 50–51: Transfer Fee Token

Mint Address

2Ak24WKZZrvjE4KGWr8YMovGBsWB5bptcQekFycn5jpd

Create Token

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
 create-token \
 --transfer-fee-basis-points 100 \
 --transfer-fee-maximum-fee 1000000 \
 --decimals 6

Test Transfers

export MINT=2Ak24WKZZrvjE4KGWr8YMovGBsWB5bptcQekFycn5jpd

spl-token mint $MINT 1000000

spl-token transfer \
 --expected-fee 10 \
 $MINT 1000 $RECIPIENT \
 --allow-unfunded-recipient

Harvest Collected Fees

spl-token withdraw-withheld-tokens \
 $MY_TA \
 $RECIPIENT_TA

The Transfer Fee extension automatically withholds a percentage of every transfer. In a traditional Web2 application, implementing this would typically require backend logic, payment processing, and accounting systems. With Token-2022, the rule is enforced directly by the token itself.

Potential use cases include protocol fees, creator royalties, treasury funding, and community currencies.

Day 52: Interest-Bearing Token

Mint Address

86D7eecNMkJMofFabFq9GMFPPUVYrwLbLx3KA6vnAyee

Create Token

spl-token create-token \
 --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
 --decimals 6 \
 --transfer-fee-basis-points 100 \
 --transfer-fee-maximum-fee 1000000 \
 --interest-rate 5000

Observe Interest Accrual

spl-token accounts $MINT --verbose

sleep 30

spl-token accounts $MINT --verbose

This extension surprised me the most.

Unlike traditional interest-bearing assets, the underlying token balance does not increase over time. Instead, Token-2022 adjusts the displayed UI amount to reflect accrued interest.

The result is a token that appears to grow while maintaining the same underlying balance. This allows applications to represent yield without continuously minting new tokens.

Day 54: Non-Transferable Token

Mint Address

Ek7ViTTtLeMCXGgBBuxUcnbxNweN58EJhTAkzcfkKi8k

Create Token

spl-token create-token \
 --program-2022 \
 --enable-non-transferable

Attempt a Transfer

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

Actual Result

The transfer failed exactly as expected.

Transfer 1 tokens
 Sender: AUVDPscnF5YwhSd5oKKVFiASVLJvzix9v9rT6SFiUaTk
 Recipient: A8MAafu4XrCxetfZhMWtSoSMXarzUBeXX5yUrcHqdCxq
 Recipient associated token account: 4BkZZy8r1uaraL4PRu6CgNAvA8HhBEhcBMcmPgexB46C

Error: Client(Error {
 request: Some(SendTransaction),
 kind: RpcError(RpcResponseError {
 code: -32002,
 message: "Transaction simulation failed:
 Error processing Instruction 0:
 custom program error: 0x25",
 data: SendTransactionPreflightFailure(
 RpcSimulateTransactionResult {
 err: Some(
 UiTransactionError(
 InstructionError(0, Custom(37))
 )
 ),
 logs: [
 "Program log: Instruction: TransferChecked",
 "Program log: Transfer is disabled for this mint"
 ]
 }
 )
 })
})

The important part of the error is:

Program log: Transfer is disabled for this mint

This confirms that the Non-Transferable extension was functioning exactly as designed. The Token-2022 program prevented the asset from being transferred between wallets, enforcing the restriction at the protocol level rather than relying on application logic.

Unlike standard SPL tokens, these assets are intended to remain attached to the wallet that receives them.

Potential use cases include:

• Educational certificates
• Membership badges
• Event attendance proofs
• Reputation systems
• Identity credentials
• Soul-bound tokens

Rather than functioning as currency, these tokens act as verifiable digital records tied to a specific wallet.

Why This Matters

What stood out to me throughout this exercise was how much functionality can be configured without writing a custom Solana program.

In a typical Web2 architecture, implementing these features would likely require:

• APIs
• Databases
• Background jobs
• Access-control logic
• Payment processing systems

With Token-2022, many of these behaviors can be embedded directly into the asset itself.

A transfer fee becomes part of the token.

Interest accrual becomes part of the token.

Transfer restrictions become part of the token.

The asset carries the logic.

Final Thoughts

Token-2022 has changed how I think about digital assets on Solana.

Instead of building applications around tokens, developers can increasingly build behavior into the tokens themselves.

Over the course of these experiments, I created:

• A token that collects fees
• A token that accrues interest
• A token that cannot be transferred

All without deploying a custom smart contract.

For a Web2 developer, the closest analogy remains middleware—but middleware for money.

The most interesting lesson from this week was seeing how different token behaviors can be achieved through configuration alone. Features that would traditionally require custom contracts, backend services, or application-level enforcement can be attached directly to the asset at mint creation.

That's a powerful shift in how we think about designing digital assets.