DEV Community: Vinay

Three Token-2022 Mints in One Week: Fees, Yield, and Soul-Bound Tokens on Solana

Vinay — Sun, 28 Jun 2026 18:45:00 +0000

A Token-2022 mint is not just a number that moves around. It is a number that moves around with rules attached.

If you have ever worked with Stripe, you know the pattern. You start with a simple charge. Then you add features — subscriptions, transfer fees, metadata. Each feature is a separate API call, and wiring them together is your job.

Token-2022 (the upgraded SPL Token program at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) flips that. Instead of middleware living next to the asset, the middleware lives inside the asset. You bake rules directly into the mint at creation time, and every wallet, program, and dApp that handles your token automatically respects them.

Here are three mints I shipped this week, what each extension does, and when you would reach for one.

1. Transfer Fee Mint — Skim 1% on Every Transfer

Mint: AXdJwLSxuzh2hjLvwEtjuDSKXMhWeVwvH2ZZkfguTBJP
Explorer: https://explorer.solana.com/address/AXdJwLSxuzh2hjLvwEtjuDSKXMhWeVwvH2ZZkfguTBJP?cluster=devnet
Extension: Transfer Fee (100 basis points = 1%, max fee 1,000,000 tokens)

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

When you transfer this token, the protocol automatically splits the amount: the recipient gets 99%, and 1% goes into a withheld_amount field on the recipient's account — untouchable by the recipient. The mint authority can sweep those withheld fees at any time with a single withdraw-withheld-tokens command.

spl-token transfer --expected-fee 10 $MINT 1000 $RECIPIENT --allow-unfunded-recipient
spl-token withdraw-withheld-tokens $MY_TA $RECIPIENT_TA

When to use: Creator royalties, protocol fees on a stablecoin, a treasury skim on a community currency. The fee is enforced at the protocol level — no middleware, no webhook, no way to route around it.

2. Interest-Bearing + Transfer Fee — Yield That Compounds While You Watch

Mint: FALRuEMugKuEf4e5sD4SHL5JsXcmZqGmtBgEPWC3BUpQ
Explorer: https://explorer.solana.com/address/FALRuEMugKuEf4e5sD4SHL5JsXcmZqGmtBgEPWC3BUpQ?cluster=devnet
Extensions: Transfer Fee (100bps) + Interest-Bearing (5000bps = 50% APR)

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

Two extensions, one mint, zero conflict. I minted 1,000,000 tokens, and within seconds the displayed balance started growing — no transaction needed. The trick: interest updates the UI amount only. The raw token balance in your account never changes. The protocol computes the displayed amount on the fly from the mint's rate and the network clock.

# Check balance twice with a 30s pause — watch it grow
spl-token balance $MINT
sleep 30
spl-token balance $MINT

The transfer fee still operates on the raw amount, so both extensions compose cleanly. You get a token that charges fees when it moves and yields interest while it sits.

When to use: Savings accounts, vesting schedules, any token where time should affect value.

3. Non-Transferable Mint — A Token That Refuses to Move

Mint: 3oJBDKS7hrnTsjKQVJ9wGXZm3BVt6NnGekBXfbHRyvfP
Explorer: https://explorer.solana.com/address/3oJBDKS7hrnTsjKQVJ9wGXZm3BVt6NnGekBXfbHRyvfP?cluster=devnet
Extension: Non-Transferable (soul-bound)

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

I minted one token to myself and tried to send it to a fresh wallet. The runtime rejected me immediately:

Error: The transfer is disabled because this token is non-transferable

That error is the feature. The non-transferable extension turns a fungible token into a soul-bound badge. Once it lands in your account, it stays there forever — no wallet, marketplace, or dApp can move it.

When to use: Certificates, credentials, achievement badges, identity attestations — anything where the holder should be the permanent owner.

What Surprised Me

The biggest surprise was that none of this required a custom smart contract. In Web2, every new behavior means a new API endpoint, a new database migration, a new cron job. On Solana with Token-2022, you flip a flag at creation time and the runtime does the rest — fees, interest, transfer restrictions, all composed from the same primitive.

The second surprise was the interest extension. I kept waiting for a "mint" transaction to appear, but there never was one. The balance just... drifted upward. It is the closest thing to a bank savings account I have seen on a blockchain, and it took one flag to enable.

If I were building a real product, I would reach for the transfer fee extension for a creator-owned token where every trade pays the treasury, and the non-transferable extension for on-chain credentials that prove attendance or completion without the risk of secondary sales.

Solana NFTs Without Metaplex: A Week of Token Extensions

Vinay — Sun, 28 Jun 2026 08:26:07 +0000

An NFT on Solana is just a mint with supply 1, decimals 0, and metadata.

Before this week I thought a Solana NFT required Metaplex. Every tutorial pointed at the Metaplex Token Metadata program as the standard way to add a name, image, and collection to a token. It turns out you can mint a full NFT — with on-chain metadata, a verifiable collection membership, and live-updatable fields — using nothing but the Token Extensions program and a handful of CLI commands. No custom smart contract. No framework. Just the protocol.

Here is what I built across four days and what surprised me.

Day 1 — An NFT with on-chain metadata

The mental model first. An NFT on Solana is a token mint with three properties: supply of 1, zero decimals (so you cannot split it), and metadata that wallets can read. With Token Extensions, the metadata lives directly on the mint account itself — no separate Metaplex account, no PDA derivation, no extra lookups.

I created a vanity mint address using solana-keygen grind --starts-with nft:1, then minted the token with the metadata extension enabled:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 0 \
  ./nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt.json

Then I stamped it with a name, symbol, and a URI pointing to a JSON file on a GitHub Gist:

spl-token initialize-metadata nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt \
  "First Light" "LIGHT" \
  "https://gist.githubusercontent.com/bl4ck4t/e0899c5a417f0d40cf72fd48201ab11f/raw/metadata.json"

spl-token mint nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt 1
spl-token authorize nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt mint --disable

The --enable-metadata flag reserves space for both the metadata pointer and the metadata fields at creation time. You cannot add this later — the account size is fixed when the mint is born.

Day 2 — Grouping NFTs into an on-chain collection

A collection on Solana is just another mint with a group extension. Individual NFTs link back to it with a member extension. Together they replace what would be a collections table joined to an nfts table in Web2.

Created a collection mint:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 --enable-metadata --enable-group

spl-token initialize-metadata 2MEg3Vqbaiy1gNRciiy8f33eqVrenLXj26NDjHPbr7kB \
  "Solana Sketchbook" "SKTCH" \
  "https://gist.githubusercontent.com/janvinsha/b477ebe4dda46b0ef03895c4ea930a46/raw/f29222bcaff0d4979fe7ebb610a00bb97a8418ec/collection.json"

spl-token initialize-group 2MEg3Vqbaiy1gNRciiy8f33eqVrenLXj26NDjHPbr7kB 3

Then created two member NFTs that point back to it:

# Member #1
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 --enable-metadata --enable-member

spl-token initialize-metadata 9QiJaKzNRUuzw1jowpoQzYWW6KuEcgfZrzrpu7DKWMym \
  "Sketch #1" "SK1" \
  "https://gist.githubusercontent.com/janvinsha/3412c5d4e92b6de9a2ed82337ecafc44/raw/99359fc62ffd0480b6a52ee1ad4048ecba4ae61c/nft.json"
spl-token initialize-member 9QiJaKzNRUuzw1jowpoQzYWW6KuEcgfZrzrpu7DKWMym 2MEg3Vqbaiy1gNRciiy8f33eqVrenLXj26NDjHPbr7kB

# Member #2
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 --enable-metadata --enable-member

spl-token initialize-metadata 32KYgijQ8cQmAko7PDBo63BpCG4nby8XLksGKrehXSsy \
  "Sketch #2" "SK2" \
  "https://gist.githubusercontent.com/janvinsha/3412c5d4e92b6de9a2ed82337ecafc44/raw/99359fc62ffd0480b6a52ee1ad4048ecba4ae61c/nft.json"
spl-token initialize-member 32KYgijQ8cQmAko7PDBo63BpCG4nby8XLksGKrehXSsy 2MEg3Vqbaiy1gNRciiy8f33eqVrenLXj26NDjHPbr7kB

The initialize-member command writes the collection address into the member mint's extension data. Wallets and explorers walk that pointer the same way a SQL query follows a foreign key.

Day 3 — Auditing everything on chain

After building, I read everything back using spl-token display:

spl-token display nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt
spl-token display 2MEg3Vqbaiy1gNRciiy8f33eqVrenLXj26NDjHPbr7kB

The output shows every extension as a separate block — metadata, group, member — all parsed from raw account bytes. No off-chain index required.

I also confirmed the parent reference. The Group address field on each member mint matched the collection mint address byte-for-byte. That is what "verifiable provenance" means — two byte arrays comparing equal.

Day 4 — Mutating metadata live on devnet

Since I held the update authority, I renamed the NFT, added a custom field, then removed it:

spl-token update-metadata nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt name "Field Notes"
spl-token update-metadata nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt rarity legendary
spl-token update-metadata nftChe7XoDvsFDkQmavkhQhPv1T9n3pfxKm2A48E9dt rarity --remove

Each command is a single transaction. The name and URI move instantly on-chain. The image those bytes point at (off-chain) is cached aggressively by wallets — a good lesson in the asymmetry between the two layers.

What surprised me

Extensions are permanent. Every extension you want must be declared at mint creation. There is no ALTER TABLE on Solana. If you forget --enable-metadata, you start over with a new mint. This feels restrictive coming from Web2, but it guarantees that any wallet can trust the account layout without additional verification.

Rent scales with extensions. A simple frozen mint is 171 bytes (~0.002 SOL rent). My multi-extension mint with metadata + group + member was 599 bytes (~0.005 SOL). Features cost bytes, and bytes cost SOL.

The update authority is powerful. Whoever holds the metadata update authority can rename, re-URI, and rewrite any field at any time. On mainnet, this should be a multisig or a revoked key for immutable NFTs.

Where to go deeper

The official documentation covers every extension I used:

If you are coming from Web2 and learning Solana, start by minting a single NFT with metadata. Then add a collection. Then mutate something. Each step builds the mental model that an NFT is not magic — it is just a mint with supply 1, decimals 0, and the right extensions.

Soulbound Credentials on Solana: Combining Non-Transferable and Permanent Delegate Extensions

Vinay — Sun, 28 Jun 2026 07:48:01 +0000

A certification you cannot sell, but an authority can revoke.

In Web2, credentials follow a specific lifecycle. A coding bootcamp issues you a certificate of completion. You cannot sell it or give it to someone else — it belongs to you. But the issuing institution retains the right to revoke it if they discover fraud or if the credential expires. Professional licenses, employee badges, verified status markers on social platforms — they all work the same way. They are yours to hold, but someone else controls whether they remain valid.

Solana's Token Extensions Program lets you encode this exact pattern at the protocol level using two extensions: non-transferable and permanent delegate.

How it works

The non-transferable extension locks tokens in place. Once minted to a wallet, they cannot be moved, sold, or traded. The permanent delegate extension gives your authority keypair the ability to burn tokens from any holder's account without their signature. Combined, they create a credential that is soulbound to the holder but revocable by the issuer.

Building it

Here is the exact sequence I ran:

# Step 1: Create the mint with all three extensions
# --enable-non-transferable locks tokens in place
# --enable-permanent-delegate lets the authority burn from anywhere
# --enable-metadata reserves space for the credential name
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  create-token \
  --decimals 0 \
  --enable-non-transferable \
  --enable-permanent-delegate \
  --enable-metadata

# Step 2: Give the credential a name and symbol
spl-token initialize-metadata [MINT_ADDRESS] \
  "Solana Dev Credential" "CRED" \
  "https://example.com/credential.json" \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

# Step 3: Create a recipient account and mint 1 credential
RECIPIENT=$(solana-keygen pubkey ~/recipient-wallet.json)
spl-token create-account [MINT_ADDRESS] --owner $RECIPIENT \
  --fee-payer ~/.config/solana/id.json \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
spl-token mint [MINT_ADDRESS] 1 --recipient-owner $RECIPIENT \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

# Step 4: Try to transfer — this FAILS (soulbound enforced)
spl-token transfer [MINT_ADDRESS] 1 [THIRD_PARTY] \
  --owner ~/recipient-wallet.json \
  --fee-payer ~/.config/solana/id.json \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
# Error: "Transfer is disabled for this mint"

# Step 5: Revoke the credential using permanent delegate
spl-token burn [RECIPIENT_TOKEN_ACCOUNT] 1 \
  --owner ~/.config/solana/id.json \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

# Step 6: Verify balance is now 0
spl-token balance [MINT_ADDRESS] --owner $RECIPIENT \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
# Output: 0

The critical moment is Step 4. The CLI returns:

Transfer is disabled for this mint

This is the non-transferable extension enforcing the soulbound constraint. No smart contract code was written. No custom program was deployed. It is a protocol-level rule that the Solana runtime applies to every transfer involving this mint.

Then in Step 5, I burned the token from the recipient's account using only my authority signature — not the recipient's. This is the permanent delegate extension in action.

Inspecting the final mint

spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The output shows all three extensions:

Extensions
  Permanent delegate: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164
  Non-transferable
  Metadata Pointer: ...
  Metadata:
    Name: Solana Dev Credential
    Symbol: CRED

What surprised me

The permanent delegate cannot be changed. Once you enable it, that authority is locked for the life of the mint. You cannot transfer it to a multisig later, you cannot revoke it, you cannot rotate the key. If the permanent delegate key is compromised, the attacker can burn every token in existence. This is the most dangerous extension in the Token Extensions suite — use it deliberately and secure the key.

The combination maps perfectly to real-world credentials. The non-transferable extension prevents secondary markets (no selling certifications). The permanent delegate enables revocation (no lifetime credentials). The metadata makes the credential self-describing (anyone can inspect what it represents without an external database).

Where to go deeper

This pattern is immediately useful for DAOs issuing membership badges, protocols granting contributor status, or education platforms distributing certificates:

If you are building a credential system on Solana, this combination of extensions is the closest thing to a "standard" pattern the protocol offers. Use it. But protect that permanent delegate key like a root password.

Three Token Extension Combinations I Tried This Week (and What Each Is Good For)

Vinay — Sun, 28 Jun 2026 07:27:57 +0000

One bare token, one feature-rich, one compliance-gated — here is what I learned.

Last week I knew how to mint a basic SPL token. This week I learned that Solana's Token Extensions Program lets you build tokens with protocol-level features — transfer fees, interest accrual, metadata, frozen accounts, soulbound restrictions, and revocable credentials — without writing a single line of on-chain code.

I spent three days building three different tokens, each with a different combination of extensions. Here is what I built, what each combination is good for, and what surprised me.

Combination 1: Interest-Bearing Token (Savings Accounts)

Extensions used: Interest-bearing (500 basis points = 5%)

The simplest extension: continuous compounding interest stored as a rate and timestamp. No new tokens are minted. Instead, wallets and applications calculate an adjusted display balance based on elapsed time.

# Create a token with 5% annual interest
spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --interest-rate 500

# Create an account and mint tokens
spl-token create-account [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
spl-token mint [MINT_ADDRESS] 1000 \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

# Inspect the interest-bearing configuration
spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The spl-token display output shows a Current rate: 500bps and a Rate authority. The raw balance stays 1000, but the UI amount ticks upward over time using A = P * e^(rt).

Good for: Yield-bearing tokens, savings accounts, staking receipts. Any situation where the balance should grow over time without a background job minting every second.

Combination 2: Multi-Extension Token (Transfer Fees + Interest + Metadata)

Extensions used: Transfer fees (100bps, max 5 tokens), Interest-bearing (5bps), Metadata, Metadata Pointer

This is the Swiss Army knife. One token that charges fees on transfers, displays interest-adjusted balances, and carries its own name and symbol on-chain.

# Create the mint with all 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

# Initialize metadata
spl-token initialize-metadata [MINT_ADDRESS] \
  "ArcCoin" "ARC" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/CompressedCoil/metadata.json" \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

# Mint and transfer to see the fee
spl-token create-account [MINT_ADDRESS]
spl-token mint [MINT_ADDRESS] 1000
spl-token transfer [MINT_ADDRESS] 100 [RECIPIENT] --expected-fee 1

When I transferred 100 tokens, the recipient received 99. The 1-token fee was withheld in a special balance that the mint authority can harvest later.

Good for: Revenue-generating tokens, ecosystem currencies, branded tokens that need on-chain identity. The extension model means all features work independently without conflicting.

Combination 3: Compliance-Gated Token (Default Frozen)

Extensions used: Default Account State (Frozen), Freeze authority

Every token account starts frozen. No one can send, receive, or burn until the freeze authority explicitly thaws them. This is protocol-level access control — no frontend bug can bypass it.

# Create a mint where all accounts start frozen
spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-freeze \
  --default-account-state frozen

# Try to mint — this FAILS because the default account is frozen
spl-token mint [MINT_ADDRESS] 100
# Error: Account is frozen

# Thaw the account, then mint succeeds
spl-token thaw [YOUR_TOKEN_ACCOUNT]
spl-token mint [MINT_ADDRESS] 100  # succeeds

# Try to send to a frozen account — FAILS
spl-token transfer [MINT_ADDRESS] 50 [FROZEN_ACCOUNT]
# Error: destination account is frozen

Both the sender and the recipient must be thawed. This creates a fully permissioned system.

Good for: Regulated assets, stablecoins with compliance requirements, security tokens, loyalty programs where accounts need approval before activation.

What surprised me

Extensions cost real SOL. Each extension adds bytes to the mint account. My interest-bearing mint was 222 bytes (0.002436 SOL rent). The multi-extension mint was 599 bytes (0.005060 SOL). The simple frozen mint was 171 bytes (0.002081 SOL). The difference between the simplest and the most complex was 2.4x in rent cost. When designing a token, every extension is a deliberate tradeoff between features and cost.

You cannot add extensions after minting. This was the hardest mental shift from Web2. In Stripe, you can add a new product feature anytime. On Solana, the account size is fixed at creation. If you forgot to enable metadata, you cannot add it later — you have to create a new mint and migrate.

Where to go deeper

The official documentation covers every extension with implementation details:

Token Extensions Overview

Try combining extensions that fit your use case. The most powerful pattern I found was frozen-by-default + transfer fees + metadata — a token that enforces compliance, generates revenue, and identifies itself, all without a single line of smart contract code.

Reading a Token Mint: How I Learned to Inspect On-Chain Configuration

Vinay — Sun, 28 Jun 2026 07:06:49 +0000

In Web2 you read config files. On Solana you read accounts.

When you join a new team in Web2, your first task is reading configuration files. You open package.json, environment variables, database schemas. You do not start changing things until you understand what is already there. Reading and interpreting existing configuration is a core skill that separates developers who break things from developers who improve things.

On Solana, that same skill applies to on-chain accounts. Every token mint stores its configuration as public account data. The spl-token display command is your cat package.json — it decodes raw bytes into human-readable configuration.

The command

spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb flag tells the CLI to read from the Token Extensions program (Token-2022), not the original SPL Token program.

What the output tells you

Here is the output from an interest-bearing mint I created:

SPL Token Mint
  Address: 7CjQNSGCiXuYAZu6UNn2xGXPEa5wxc1oxLQoj198jFdy
  Program: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
  Supply: 0
  Decimals: 9
  Mint authority: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164
Extensions
  Interest-bearing:
    Current rate: 500bps
    Average rate: 500bps
    Rate authority: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164

Each extension occupies its own block. The Interest-bearing block tells me:

The current rate is 500 basis points (5%)
The rate authority is a specific wallet address

Here is the output from a multi-extension mint (transfer fees + interest + metadata):

Extensions
  Interest-bearing:
    Current rate: 5bps
    Rate authority: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164
  Transfer fees:
    Current fee: 100bps
    Current maximum: 50000
    Config authority: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164
    Withdrawal authority: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164
  Metadata Pointer:
    Authority: 2Cd1SqwosBfgoo8UrxBDBFquZRTt11Cmh1bcPDemn164
  Metadata:
    Name: ArcCoin
    Symbol: ARC
    URI: https://raw.githubusercontent.com/...

How to compare account sizes

Extensions are not free. Each one adds bytes to the account. You can measure this directly:

# Get the data size of any mint
solana account [MINT_ADDRESS] --output json | grep -o '"space":[ ]*[0-9]*' | grep -o '[0-9]*$'

# Calculate the rent cost
solana rent [DATA_SIZE]

I compared three mints and got this:

Mint Type	Size	Rent Cost
Default-frozen (1 extension)	171 bytes	0.002081 SOL
Interest-bearing (1 extension)	222 bytes	0.002436 SOL
Multi-extension (3 extensions)	599 bytes	0.005060 SOL

The multi-extension mint costs more than double the rent of the simplest. This is not a bug — it is a design tradeoff. More features mean more data, and more data means more SOL to keep the account rent-exempt.

What surprised me

You can see every authority. The display command shows who controls what — mint authority, freeze authority, rate authority, transfer fee config authority, metadata update authority. Some of these cannot be changed after creation. Reading the configuration before deploying to mainnet is how you avoid painting yourself into a corner.

Extensions are stored sequentially as TLV entries. Each extension uses a type-length-value format. The CLI parses them one by one and displays them as blocks. The order in the output matches the order in the raw account data.

Where to go deeper

Being able to read on-chain state is as important as being able to create it. The official docs explain the data model:

Token-2022 Reference

Next time you encounter an unfamiliar token on devnet, run spl-token display on it. You will learn more from reading one real configuration than from ten tutorials.

What Token Extensions Are and Why a Web2 Developer Should Care

Vinay — Fri, 26 Jun 2026 06:43:28 +0000

You already understand tokens. Extensions are just middleware for your money.

If you have ever worked with Stripe, you know the pattern. You start with a simple charge: send money from point A to point B. Then you add features — subscriptions, transfer fees, metadata on invoices, compliance checks. Each feature is a separate Stripe product or API call, and wiring them together is your job.

Solana's Token Extensions Program is the same idea, but at the blockchain protocol level. Instead of bolting features on top of a basic token after creation (which Solana does not allow), you declare every capability upfront, and the runtime enforces it automatically. No smart contract to write. No backend service to maintain. Just configuration flags at creation time.

What is a token extension?

A token extension is an optional feature you enable when you create a token mint. Under the hood, each extension reserves extra bytes in the mint's on-chain account. Those bytes store configuration — an interest rate, a fee percentage, a metadata URI — and the Solana runtime reads them during every transaction.

The original SPL Token Program is simple. It stores supply, decimals, and authorities. The Token Extensions Program (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) is a superset. It stores everything the original does, plus additional data for each extension you enable.

Extensions map directly to Web2 concepts

Extension	Web2 Analogy	What It Does
Transfer Fees	Payment processor fee	Deducts a % on every transfer
Interest-Bearing	Savings account APY	Displays time-adjusted balance
Metadata	Product catalog entry	Stores name, symbol, URI on-chain
Default Account State	KYC gating	All accounts start frozen; you thaw approved users
Non-Transferable	Professional license	Tokens cannot be sold or transferred
Permanent Delegate	Admin revoke power	Issuer can burn tokens from any holder

A concrete example

Here is the exact command I ran to create a token with transfer fees, interest-bearing, and metadata — all in one line:

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 single command does what would take three separate services in Web2:

Transfer fees (like Stripe taking 1%): 100 basis points = 1%, capped at 5 tokens
Interest-bearing (like a savings account): 5% continuous compounding
Metadata (like a product database entry): space reserved for name, symbol, and URI

After creating the mint, I added the metadata:

spl-token initialize-metadata [MINT_ADDRESS] \
  "ArcCoin" "ARC" \
  "https://example.com/metadata.json" \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Then I inspected everything with:

spl-token display [MINT_ADDRESS] \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

The output showed each extension as a separate block — TransferFeeConfig, Interest-bearing, Metadata Pointer, Metadata — all living in the same on-chain account.

What surprised me

Extensions are additive in cost. Each one adds bytes to the mint account, and bytes require SOL for rent-exempt status. My bare mint (default-frozen only) was 171 bytes. Adding interest-bearing bumped it to 222 bytes. The multi-extension mint with transfer fees + metadata + interest was 599 bytes — costing over 2x the rent.

In Web2 terms: extensions are like choosing between a lightweight microservice and a feature-rich monolith. Both have their place, but you should make the choice deliberately.

Where to go deeper

The official Solana documentation covers every extension in detail:

Token Extensions Overview

If you are a Web2 developer curious about Solana, start with the extensions that map to problems you already solve — transfer fees, metadata, access control. You will recognize every one of them.

Transfer Fees, Metadata, and Soulbound Tokens: A Tour of Solana Token Extensions

Vinay — Sun, 24 May 2026 13:48:00 +0000

If you are a Web2 developer and the phrase "on-chain token" sounds like something you need a PhD to build, this post is for you. I went from zero to creating tokens with metadata, transfer fees, and non-transferable locks using nothing more than CLI commands. Here is exactly how I did it and what surprised me along the way.

Before starting this challenge, I had never created a token on any blockchain. I understood the basics of Solana — sending SOL, reading balances, using the CLI — but the idea of creating my own digital asset felt like advanced territory. The goal was simple: learn what Solana tokens can do by building them, one step at a time.

Step 1: Create a Basic Mint

spl-token create-token

This creates a Mint account — the on-chain definition of your token. It stores supply, decimals, and authority. The mint holds no tokens by itself. To hold a balance you need a token account:

spl-token create-account YOUR_MINT_ADDRESS
spl-token mint YOUR_MINT_ADDRESS 100

The mint is the global token definition. Each token account is a wallet's balance for that specific token. In Web2 terms, the mint is your currency definition and each token account is a user's balance row. The SPL Token Program handles all the hard parts for you.

Step 2: Add On-Chain Metadata

A mint address with no name is just a string. The original SPL Token Program does not support on-chain metadata. The Token Extensions Program (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) stores metadata — name, symbol, URI — directly on the mint account, so everything is in one place instead of requiring a separate lookup:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 6

spl-token initialize-metadata YOUR_MINT_ADDRESS \
  "100DaysCoin" "HUNDO" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json"

The --enable-metadata flag activates the metadata extension at mint creation. The initialize-metadata command writes the name, symbol, and URI. The URI points to a JSON file with additional details like description and image.

Step 3: Attach a Transfer Fee

Instead of building middleware to collect fees on every transfer, the transfer fee extension enforces collection at the program level:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 5000

100 basis points = 1%. Every transfer of this token automatically withholds 1% in the recipient's token account. The recipient cannot spend withheld tokens. Only the withdraw withheld authority (the wallet that created the mint) can collect them:

spl-token transfer YOUR_MINT_ADDRESS 100 RECIPIENT --expected-fee 1
spl-token withdraw-withheld-tokens YOUR_ACCOUNT RECIPIENT_ACCOUNT

The --expected-fee flag is a safety check — the transfer only succeeds if the calculated fee matches what you specified. The withheld tokens accumulate in the recipient's account until the authority sweeps them out.

Step 4: Full Lifecycle in One Session

Combining multiple extensions on a single mint works in one flow:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 200 \
  --transfer-fee-maximum-fee 5000 \
  --enable-metadata \
  --decimals 9

spl-token initialize-metadata YOUR_MINT_ADDRESS \
  "ReinforceCoin" "RFC" \
  "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/CompressedCoil/metadata.json"

spl-token create-account YOUR_MINT_ADDRESS
spl-token mint YOUR_MINT_ADDRESS 1000
spl-token transfer --fund-recipient YOUR_MINT_ADDRESS 100 RECIPIENT --expected-fee 2 --allow-unfunded-recipient
spl-token withdraw-withheld-tokens YOUR_ACCOUNT RECIPIENT_ACCOUNT

Two extensions (metadata + transfer fee) configured on the same mint. No smart contract needed.

Step 5: Create a Non-Transferable (Soulbound) Token

Some tokens should never be transferred — verified badges, course certificates, KYC credentials. The non-transferable extension blocks all transfers at the protocol level:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-non-transferable

After minting, attempting a transfer returns an error:

spl-token transfer YOUR_MINT_ADDRESS 5 RECIPIENT \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --allow-unfunded-recipient

Program log: Transfer is disabled for this mint
Program TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb failed: custom program error: 0x25

The token program itself rejects the instruction. No client or program can override it. Burning still works — the holder can destroy tokens they own:

spl-token burn YOUR_TOKEN_ACCOUNT 3 --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Non-transferable does not mean non-destructible. The holder controls their own account but cannot move tokens to another wallet.

What Surprised Me

Two things did not work the way I expected.

First, extensions must be configured when the mint is first created. You cannot add a transfer fee or metadata extension later. You have to decide how your token behaves before it exists, which is the opposite of how I would approach it in Web2.

Second, the non-transferable failure was more satisfying than I expected. I ran the transfer command fully expecting tokens to move. Instead, the blockchain returned Transfer is disabled for this mint. The error was clear and no flag or workaround could bypass it. That is when it clicked: this is a protocol-level lock, not a convention.

What's Next

I plan to build a token with real utility — combining metadata and transfer fees into something that could serve as a community reward token. If you are following the #100DaysOfSolana challenge or exploring Solana tokens on your own, start with the basic mint, then add one extension at a time. The CLI makes it easy to experiment without writing any smart contract code.

Resources

🗄️Solana Accounts Are Just Files — and Programs Are Just People Who Can Read Them

Vinay — Tue, 19 May 2026 11:43:48 +0000

The analogy that rewired my brain - The Filing Cabinet

Imagine a room filled with filing cabinets. Each drawer has a random label. Inside each drawer is a folder.

On the front of the folder is written:

Owner — who can open and change the contents
Executable — is this a set of instructions or just data?
Data — the actual contents (a number, JSON, raw bytes)

Anyone can walk up to any drawer and read the label. Only the Owner can modify what's inside.

This room is Solana. The drawers are accounts. The folders are account data. The owners are programs.

💡 What This Explains

There is no "users table." Your wallet is a file owned by the System Program. The data inside is one number — your SOL balance. "Sending SOL" means authorizing the System Program to decrease the number in your file and increase it in someone else's.

You can't modify every account. Only the owning program can. This isn't a restriction — it's the entire security model. If anyone could modify any account, the network would be chaos. The runtime enforces ownership at the validator level, not in application code.

Programs are stateless. A program is like a person who knows how to read specific file formats. The System Program reads simple balance files. The Token Program reads mint metadata and token balances. Your custom program reads whatever format you define. The program itself stores nothing — state lives in separate accounts it owns. Think of it like a web server (the program) that reads and writes to a database (data accounts) rather than keeping everything in memory.

📋 The Four Fields

Every account on Solana has the same structure:

Field	What it is
Lamports	The SOL balance (always in lamports — 1 SOL = 1,000,000,000)
Data	Raw bytes — file contents, whatever the owner program decides
Owner	The program address that controls this account
Executable	Is this file a program (code) or just data?

Here's what they look like in practice:

$ solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Public Key: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Balance: 0.00028296 SOL
Owner: BPFLoaderUpgradeab1e11111111111111111111111
Executable: true
Data: (compiled program bytecode)

A wallet, a token program, a sysvar — all use the same four fields. Different values. That's the entire state model.

💰 Rent Exemption

Keeping a file on-chain costs storage space. Solana charges rent — a small deposit proportional to your account's data size. Deposit enough (~2 years worth) and your account is "rent-exempt" — it stays forever.

solana rent 0     # 0.00089088 SOL (basic account)
solana rent 100   # cost for 100 bytes of data

For a basic wallet with no extra data, it's roughly 0.00089 SOL. This deposit is refundable when you close the account. Not a bug — it's the price of storing data in a globally replicated system.

🔑 Three Things That Suddenly Make Sense

1. Ownership rules. Only the owner program can modify an account's data or deduct lamports. Anyone can credit lamports to any writable account. Simple, powerful, enforced by every validator.

2. PDAs. Sometimes a program needs a file it controls but no private key can sign for it. Program-Derived Addresses are deterministic drawer labels — computed from program ID + seeds — that only the program can authorize. Like a combination lock where only the program knows the combination.

3. Composability. Every file declares its owner. Anyone can read. Only the owner can write. Programs chain together: Program A reads a Token account to check your balance, then asks the System Program to move SOL. All in one atomic transaction. That's composability.

🎯 Why This Matters

Before this analogy clicked, every Solana concept felt like learning a new language from scratch. After it clicked, the documentation became readable. Error messages became decipherable. I stopped asking "what is an account?" and started asking "what kind of file is this, and who owns it?"

If you're coming from Web2 and struggling with Solana's account model, try the filing cabinet. You'll know it clicked when you stop thinking about tables and start thinking about drawers.

This is the final post in a 4-part series on unlearning Web2 mental models for Solana:

This is a submission for the 100 Days of Solana Writing Challenge, running from 15 May to 22 May.

✍️ A Solana Transaction Is a Signed Check — Not an API Request

Vinay — Tue, 19 May 2026 11:24:11 +0000

When I started writing code that sends SOL, I treated transactions like API calls. Construct a payload, POST it to the network, wait for a 200 OK. That mental model worked — until it didn't.

Then I realized: a Solana transaction isn't a request. It's a signed check.

🧠 The Analogy

Think of writing a physical check. You fill in who gets paid and how much. You sign it. Someone deposits it. The bank processes it — either the money moves or the check bounces.

A Solana transaction works the same way:

You write the instruction — "Pay 0.1 SOL from my account to this address"
You sign it — with your private key (like signing the check)
You submit it — to the network (like depositing the check)
The network processes it — atomically, all or nothing

The check analogy breaks down in one important way though: in Solana, you pay the processing fee even if the check bounces.

⚡ The Part That Surprised Me

I crafted a transaction sending 500 SOL from a wallet that only had 2. I disabled preflight simulation so it would reach the network. It failed, obviously. But the 5,000 lamport fee was still deducted.

This is fundamentally different from Web2. A failed HTTP request costs you nothing — the server returns an error and you move on. On Solana, validators executed your instruction, ran your program, determined the outcome, and included the result in a block. That work consumed compute resources, and validators get paid regardless of the outcome.

I covered the technical details — building a transfer tool with commitment tracking, polling for confirmation, forcing failures — in -

Vinay

May 10

⚓My Deep Dive into Solana Transactions: Shifting the Web2 Perspective

#100daysofsolana #web3 #blockchain #solana

2 min read

But the economic lesson is what stuck with me:

Every transaction is an economic event. It consumes network resources. It has a cost. You pay for execution, not just success.

⚙️ What This Changes

Simulate before you send. The skipPreflight flag exists for edge cases, not everyday development. Most failures can be caught locally — insufficient balance, wrong account ownership, expired blockhash. Check everything before you submit.

Failed transactions are learning tools. The program logs in a failed tx show you exactly where execution stopped, how much compute was consumed, and what error the program returned. I've learned more from forced failures than from successful transfers.

Atomicity is built in, not bolted on. If a transaction has three instructions and instruction 2 fails, instructions 1 and 3 are rolled back too. The fee is still charged. In Web2, you'd write try/catch blocks and compensation logic. On Solana, the runtime guarantees atomicity — but you pay either way.

I wrote about the transaction anatomy -

Vinay

May 6

Understanding Solana's transaction anatomy

#100daysofsolana #web3 #blockchain #solana

2 min read

— signatures, blockhashes, account keys, compiled instructions — and walked through a CLI transfer -

Vinay

May 6

Sending Your First SOL Transfer (Devnet, via CLI)

#100daysofsolana #web3 #blockchain #solana

3 min read

step by step in earlier posts. But the mental model upgrade is simpler than any of those details:

Don't think of a transaction as a request you send. Think of it as a check you sign.

Next: The Filing Cabinet — why Solana accounts are just files and programs are just people who can read them.

This is a submission for the 100 Days of Solana Writing Challenge, running from 15 May to 22 May.

🔌 The "Connect Wallet" Button Replaced My Entire Auth System

Vinay — Tue, 19 May 2026 11:13:42 +0000

Here's something I didn't expect when I started building on Solana: I never wrote a signup form.

No username field. No password validation. No "confirm your email" flow. No "forgot password" page. Every piece of auth infrastructure I'd built dozens of times in Web2 — gone.

In its place: one button. "Connect Wallet."

🧠 What a Wallet Actually Does

If you're new to Solana, I wrote about the conceptual shift — from usernames to keypairs — in a previous post -

Vinay

Apr 25

🔑 From Usernames to Keypairs: Understanding Identity on Solana

#100daysofsolana #solana #web3 #blockchain

2 min read

The short version: your identity is a cryptographic keypair, not a database row.

But for a developer, the practical implication matters more than the theory. Here's what changes:

You don't manage authentication. The wallet does. When a user clicks "Connect Wallet," their browser extension (Phantom, Solflare, etc.) pops up a confirmation. They approve. Your app gets their public key. You never see the private key. You never store a password hash. You never issue a session token.

You don't build onboarding flows. In Web2, every step of signup is a drop-off point. Email entry, email verification, profile setup, terms acceptance. On Solana, the user already has an identity before they visit your app. Your job is just to detect it.

"Logging in" is just signing a message. Your app sends a message, the wallet signs it, you verify the signature on your backend. No session cookie. No JWT. The signature is the proof.

⚠️ What You Lose

This isn't strictly better. There are tradeoffs:

No password reset. If a user loses their private key, they lose access. There's no admin tool to restore their account.
No account recovery. In Web2, you can email a reset link. On Solana, the keypair is the only identity. Lose it, and everything associated with that address — tokens, NFTs, program state — is inaccessible.
No gradual onboarding. In Web2, you can let users browse before requiring login. On Solana, the user's address is their identity from the first interaction. There's no "anonymous session" that converts to a registered account later.

I covered the technical details of keypair generation and storage — why extractable: true matters, how PKCS8 works — in another post -

Vinay

Apr 27

Why My Solana Wallet Broke Without "extractable: true" — And What PKCS8 Taught Me About Private Keys

#100daysofsolana #web3 #blockchain #solana

2 min read

But the developer workflow shift is what I had to actually rebuild in my head.

💻 The Code Difference

In Web2, auth looks like this:

// Signup
app.post("/signup", async (req, res) => {
  const hash = await bcrypt.hash(req.body.password, 10);
  await db.users.create({ email: req.body.email, passwordHash: hash });
  req.session.userId = user.id;
});

// Login
app.post("/login", async (req, res) => {
  const user = await db.users.findByEmail(req.body.email);
  if (!user || !(await bcrypt.compare(req.body.password, user.passwordHash))) {
    return res.status(401).send("Invalid credentials");
  }
  req.session.userId = user.id;
});

On Solana, auth looks like this:

// Connect wallet (browser side)
const { accounts } = await wallet.features["standard:connect"].connect();
const userAddress = accounts[0].address;

// That's it. The user is now "authenticated."

No password hashing. No session management. No database lookups. The wallet handles the cryptographic proof. Your app just reads the public key.

🎯 Why This Matters

The "Connect Wallet" pattern isn't just a UI trend. It represents a fundamental shift in how identity works. In Web2, you build auth into your app. In Solana, auth is infrastructure — it lives in the wallet, not in your codebase.

That means as a developer, you don't need to worry about password storage, session hijacking, or email verification. But you also can't rely on support tickets or account recovery when something goes wrong.

Once I understood this tradeoff — less code, more responsibility — the "Connect Wallet" button stopped looking like a simplification and started looking like a completely different approach to identity.

Next: Transactions aren't HTTP requests. They're signed checks — and failed ones still cost you.

This is a submission for the 100 Days of Solana Writing Challenge, running from 15 May to 22 May.

📊Solana Is a Public Spreadsheet — Not Your Private Database

Vinay — Tue, 19 May 2026 10:56:17 +0000

If you're coming from Web2, here's the first mental model you need to rewrite: Solana is not a database you control. It's a public spreadsheet that everyone can see and no one fully owns.

🧠 The Analogy

Think of a Google Sheet shared with the entire internet. Anyone can open it and read any cell. But only specific people (programs) have permission to edit specific rows.

Your wallet is a row in that sheet. The columns are:

Lamports — your SOL balance
Data — any extra info attached to your row
Owner — which program is allowed to edit this row

Anyone can look up your row. Only the owner program can change it. And the owner program can only make changes when you prove you're you — by signing with your private key.

In Web2, your database has a wall around it. Users authenticate with passwords, and your server decides who sees what. On Solana, there's no wall. The security comes from cryptographic signatures, not login gates.

⚙️ What This Changes

You can't hide data. Every balance, every transaction, every interaction with any program is publicly visible forever. If you're building on Solana, don't store private info in account data. It's not private.

There's no "backend" to build. You don't need to design a database schema, set up authentication middleware, or deploy an API server. Solana is the backend. Your program (smart contract) defines the rules, and users interact with it directly through transactions.

Ownership is enforced by the network, not your code. In Web2, you write if (user.isAdmin) checks to control access. On Solana, the runtime itself prevents unauthorized writes. If your program doesn't own an account, it simply cannot modify it — no matter what your code tries to do.

🔥 The Hardest Adjustment

The first time I queried someone else's wallet balance, I felt like I was doing something wrong. Coming from web development, I never once displayed another user's financial data without permission. But on Solana, that's not just allowed — it's the entire point.

Transparency isn't a design flaw. It's the feature that makes everything else possible. Composability, auditability, trustlessness — all of it starts with the fact that every piece of state is public.

Once I stopped thinking of Solana as "someone else's database I'm borrowing" and started seeing it as "a shared public spreadsheet," the rest of the model started clicking.

Next: The "Connect Wallet" button replaced my entire auth system.

This is a submission for the 100 Days of Solana Writing Challenge, running from 15 May to 22 May.

⚓My Deep Dive into Solana Transactions: Shifting the Web2 Perspective

Vinay — Sun, 10 May 2026 15:14:24 +0000

Over the last few days, I’ve been learning how Solana transactions actually work. At first, I approached them like I would approach API requests in Web2: you send something to the network, wait for a response, and either it succeeds or fails.
But after building transfer tools, tracking confirmations, and intentionally forcing failed transactions, I realized Solana transactions are much closer to atomic state transitions in a distributed system than traditional request/response workflows.

🏗️ The Foundation

Before this post, I documented two earlier parts of the journey:

Vinay

May 6

Sending Your First SOL Transfer (Devnet, via CLI)

#100daysofsolana #web3 #blockchain #solana

3 min read

Vinay

May 6

Understanding Solana's transaction anatomy

#100daysofsolana #web3 #blockchain #solana

2 min read

Those experiments helped me understand the structure underneath every transaction before I started building tooling around them.

🔍 Deconstructing the Transaction Anatomy

The first thing that stood out to me was how much information exists inside a transaction. Once I started inspecting transactions in Solana Explorer and using solana confirm -v, I stopped seeing transfers as simple wallet operations.

A single transaction includes:

Signatures
Instructions
Account keys
Recent blockhashes
Fee payer information
Execution logs

🧠The Mental Model Shift:
A Solana transaction is not just a request. It’s a signed set of instructions that tells the network how on-chain state should change.

🛠️ Building the Tooling

After getting comfortable with CLI transfers, I built a reusable transfer tool instead of manually typing commands every time.

The tool eventually handled:

Recipient and amount validation
Balance checks before sending
Explorer link generation
Confirmation tracking
Transaction failure handling

The balance checks were especially interesting because failed transactions on Solana still cost fees. That’s very different from most backend systems I’m used to. In Web2, failed requests are usually just errors. On Solana, even failed execution still consumes validator compute resources.

⛓️ Understanding the Lifecycle of Confirmation

One of the most useful things I learned was how confirmation actually works. At first, I thought transactions were either pending or complete.

But Solana has multiple commitment levels:

Processed: Received by a validator.

Confirmed: Voted on by the network supermajority.

Finalized: Effectively irreversible after additional confirmed blocks.

Watching transactions move through those stages made the network feel much more real. Instead of treating blockchain confirmation like a black box, I could actually observe the lifecycle happening in real time.

⚠️ Learning Through Failure

The most valuable part of the process, though, was intentionally breaking transactions.

I created empty wallets. I forced failed transfers. I inspected logs and Explorer traces. I compared local CLI validation with actual on-chain failures. That ended up teaching me more than successful transactions did.

Seeing compute usage, log messages, and failure metadata made the debugging side of Solana feel surprisingly similar to debugging distributed backend systems—except here, every mistake has an economic cost attached to it.

🧠 Key Takeaways

The biggest takeaway from this journey is that understanding transactions is really about understanding how Solana itself thinks.

Once I stopped comparing transactions directly to REST API calls, concepts like signatures, blockhash expiration, commitment levels, and transaction simulation started making much more sense. Intentionally exploring failed transactions was the point where everything finally clicked for me.