DEV Community: Vinay

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

Comments 1

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

Comments

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

Comments

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

Comments

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

Comments

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

Comments

3 min read

Vinay

May 6

Understanding Solana's transaction anatomy

#100daysofsolana #web3 #blockchain #solana

Comments

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.

Understanding Solana's transaction anatomy

Vinay — Wed, 06 May 2026 11:23:11 +0000

📖 Overview

For the past week, I’ve been reading data from the Solana blockchain. This project marks the shift from reading state to writing state. The goal was simple but fundamental: understand what actually happens when a transaction is sent on Solana.

🎯 Objective

Send a real transaction on Solana Devnet

Inspect it using CLI and Explorer

Understand its internal structure

Build a mental model for how state changes occur

⚙️ What I Did

1. Created a Temporary Wallet

Generated a fresh keypair to act as the recipient.

solana-keygen new --no-bip39-passphrase -o /tmp/temp-wallet.json

This generated a transaction signature, which acts as:

A receipt

The transaction ID

The first cryptographic signature

Example:

2. Sent a Transaction

solana transfer --allow-unfunded-recipient $(solana address -k /tmp/temp-wallet.json) 0.001 --url devnet

Transferred a small amount of SOL on Devnet.
This produced a transaction signature (ID).

Example:

3. Inspected the Transaction via CLI

solana confirm -v <TRANSACTION_SIGNATURE>

This revealed:

Transaction status and slot

Accounts involved

Instruction execution details

Example:

4. Analyzed in Explorer
Visualized It in Solana Explorer

Using the transaction signature, I examined:

Signatures → Authorization proof

Recent Blockhash → Freshness + anti-replay

Account Keys → All accounts involved

Instruction → System Program transfer

🧠Mental Model Upgrade

What you sent is not:

“Send 0.001 SOL to X”

It is:

“Execute instruction #2 of the System Program, using these accounts, with this encoded data, authorized by this signature.”

Sending Your First SOL Transfer (Devnet, via CLI)

Vinay — Wed, 06 May 2026 09:43:38 +0000

This walkthrough focuses on executing a SOL transfer using the Solana CLI - while understanding the underlying mechanics at each step. If you’ve used payment APIs like Stripe or PayPal, the flow is conceptually similar: authenticate, define recipient, specify amount, submit. The difference is architectural, transactions go directly to the network and finalize in sub-seconds, without intermediaries.

Environment Requirements

Terminal (macOS, Linux, or Windows WSL)

Solana CLI installed

A keypair (existing or newly generated)

1. Configure CLI to Devnet

solana config set -ud
solana config get

Key point:
You are selecting the cluster (network). Devnet is a sandbox environment with no real economic cost. The RPC endpoint (https://api.devnet.solana.com) acts as your interface to the validator network.

Why it matters:

All subsequent commands - balance queries, transfers, account creation are executed against this network.

Example:

2. Check Balance and Fund Wallet

solana balance
solana airdrop 2

Key point:

Transactions require:

Sufficient balance for the transfer amount
A small fee for network processing

Airdrop behavior:

Devnet validators mint SOL for testing
Requests are capped (typically 5 SOL)

If airdrop fails:
You can fund your wallet using the Solana Faucet as an alternative.

Why it matters:
Without sufficient balance, the transaction cannot be constructed or submitted.

Example:

3. Generate a Recipient Keypair

solana-keygen new --outfile ~/recipient-keypair.json --no-bip39-passphrase

Key point:
You are creating a cryptographic identity:

Private key → signs transactions
Public key → acts as the address

Important nuance:
This account does not yet exist on-chain - it becomes a real account only after being funded.

Why it matters:
Solana distinguishes between:

Off-chain keypairs (identity)

On-chain accounts (state containers)

Example:

4. Execute the Transfer

solana transfer <RECIPIENT_PUBLIC_KEY> 0.5 --allow-unfunded-recipient

Key point:
This command:

Constructs a transaction with a System Program transfer instruction

Signs it with your private key

Submits it to a validator via RPC

Flag explanation:

--allow-unfunded-recipient allows the network to create the recipient account implicitly

Why it matters:
On Solana, accounts must be explicitly created and funded. This step combines:

Account creation
Value transfer into a single atomic transaction.

Example:

5. Verify State Changes

solana balance
solana balance <RECIPIENT_PUBLIC_KEY>

Key point:
You are querying on-chain state post-finalization.

Expected outcome:

Sender balance decreases (transfer + fee)

Recipient balance increases

Recipient account now exists on-chain

Why it matters:
This confirms the transaction was validated, executed, and finalized by the network.

Example:

6. Inspect the Transaction

Open your transaction using the signature in Solana Explorer:

Key point:
You are viewing the transaction as recorded in the ledger.

Details include:

Accounts involved
Instruction data
Fees
Slot (block inclusion)
Confirmation status

Why it matters:
The explorer reflects canonical on-chain data - this is the definitive record of execution.

Example:

View above transaction in solana explorer

Full Command Flow

solana config set -ud
solana airdrop 2
solana-keygen new --outfile ~/recipient-keypair.json --no-bip39-passphrase
solana transfer <RECIPIENT_PUBLIC_KEY> 0.5 --allow-unfunded-recipient
solana balance
solana balance <RECIPIENT_PUBLIC_KEY>

What This Demonstrates

Direct transaction submission to a decentralized validator network

Atomic state transitions (account creation + transfer)

Explicit account model requiring funding for existence

At a systems level, you:

Defined network context (devnet RPC)

Generated identities

Authored and signed a transaction

Submitted it to the network

Observed deterministic state changes

This is the foundational workflow for interacting with Solana.

A few early takeaways from learning Solana

Vinay — Sun, 03 May 2026 17:42:17 +0000

I’ve been exploring Solana for the past few days and a few things stood out pretty quickly

No traditional database everything revolves around accounts
Reads happen through RPC calls not queries
Writes are transactions not simple updates
Access control is handled by signatures not roles or middleware

The biggest shift so far has been adjusting to the accounts model. Coming from a typical backend mindset it forces you to think differently about how data is stored who owns it and how state changes over time

I also built a small dashboard in the browser to fetch wallet balance and recent transactions. Moving from scripts to something visual made the flow of data much clearer

Had a session with Solana DevRel as well where we discussed Anchor validators and PDAs. That helped connect some of the concepts around how programs actually manage data on chain

Still early but things are starting to click. Planning to go deeper into Anchor and understand how to structure programs better

Two weeks with Solana - Personal experience

Vinay — Sun, 03 May 2026 17:18:05 +0000

Been spending the last ~10 days getting hands-on with Solana as part of a hackathon. Went in expecting things to feel completely different from what I’m used to.

It wasn’t as far off as I thought.

What I’ve Done So Far

Generated a keypair + airdropped devnet SOL
Created a wallet and checked balance programmatically
Understood SOL vs lamports
Connected a browser wallet
Read on-chain data (accounts, transactions)
Fetched recent transactions
Built a small browser dashboard
Compared devnet vs mainnet data
Tried mapping accounts vs traditional databases

What Took a Bit to Understand

Fetching data wasn’t the hard part - it’s pretty similar to calling APIs.

The shift was in how things are structured:

Accounts aren’t users, they’re just data containers
There’s no backend I control
Data is public, transactions update state

The point where it clicked was pulling transaction history for a wallet and realizing there’s no access layer in between. You just query it.

Building in the Browser

Moving from scripts to a simple dashboard helped a lot.

Showing balances, listing transactions, switching networks - it made things feel more real than just running CLI scripts.

MLH Session

Also attended an MLH session with Brianna (Solana Developer Relations). where she briefed on:

Anchor Framework
Validators
PDAs
Program structure on Solana

I haven’t used these hands-on yet, but it gave me a better picture of what’s happening under the hood.

Still Figuring Out

Program design
Handling storage (accounts + rent)
Better ways to query data beyond basic RPC

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

Vinay — Mon, 27 Apr 2026 09:34:20 +0000

Last week, I built a small Solana wallet script where I could create, export, save, and reload a keypair.

Here's the link of the script for reference: Github

It all started with this line:

const wallet = await generateKeyPairSigner({ extractable: true });

When I tried exporting the private key:

await crypto.subtle.exportKey("pkcs8", wallet.keyPair.privateKey);

I learned two important things:

1. Why `extractable: true` is required

If the key is not extractable:

exportKey simply fails
The private key stays locked inside the crypto subsystem
You cannot save or reuse the wallet

So without extractable: true, the wallet is temporary (in-memory only).

2. Why "pkcs8" and not "raw"?

This part was subtle but important.

"pkcs8" is the standard format for exporting private keys
It wraps the key with metadata (algorithm, structure, etc.)
The Web Crypto API only allows private keys to be exported in PKCS#8 format

If you try:

crypto.subtle.exportKey("raw", wallet.keyPair.privateKey);

It will fail.

Because:

"raw" format is only valid for public keys
Private keys require a structured, secure encoding → hence PKCS#8

🧩 What I Did Next

After exporting in PKCS#8, I extracted the actual 32-byte private key:

const privateKeyBytes = new Uint8Array(pkcs8Buffer.slice(-32));

Then combined it with the public key:

`const keyPairBytes = new Uint8Array(64);
keyPairBytes.set(privateKeyBytes, 0);
keyPairBytes.set(publicKeyBytes, 32);`

This gave me the standard 64-byte Solana keypair, which I could:

Save to a file
Reload later

⚖️ Big Takeaway

This small detail clarified a bigger concept for me:

extractable: true → enables portability (save, backup, restore)
"pkcs8" → the only valid way to export private keys
"raw" → only works for public keys

🔑 From Usernames to Keypairs: Understanding Identity on Solana

Vinay — Sat, 25 Apr 2026 12:10:32 +0000

A few days ago, if you asked me what “identity” means in tech, I’d give you a very Web2 answer:

Email + password = identity

Every platform I used - GitHub, banking apps, social media - had its own login system. Different usernames, different passwords, all controlled by the companies behind them.

Then I started learning Solana.

And my understanding of identity completely changed.

🏨 Web2 vs Web3: A Simple Analogy

Web2 identity is like staying in a hotel.

You get a key card, but the hotel can deactivate it anytime.

Solana identity is like owning your own house.

You hold the only key. No one can lock you out… but if you lose it, you're stuck outside.

This shift from platform-controlled access to user-controlled ownership is the core idea behind on-chain identity.

🔑 Identity = Keypair

On Solana, your identity starts with a cryptographic keypair:

Public Key → your address (safe to share)
Private Key → your proof of ownership (must stay secret)

If you’ve used SSH before, this will feel familiar.

No signup. No email. Just keys.

🤯 One Keypair = My Identity

In Web2, my identity is scattered. Each service (Google, Social Media, Github, etc..) manages its own version of "me".

But on Solana, everything connects to one thing:

That’s when it clicked:

My public key isn’t just an address — it’s my identity across the entire network.

👀 The Weird Part: No Username?

In Web2, we all know how a username looks like..
I expected something like that.
Instead, I got this 😵‍💫:

14grJpemFaf88c8tiVb77W7T...

Not exactly memorable 😅

But then I learned, On Solana, your identity is your public key:

It’s mathematically generated
It uses Base58 encoding, avoiding confusing characters like 0, O, I, and l
Not controlled by any company

🔐 “Logging In” Doesn’t Exist

This is a subtle but important shift.

You’re not logging in. You’re proving ownership cryptographically.

No passwords. No sessions. Just signatures.

🏁 Final Thought

I started this journey thinking I was just learning how wallets and transactions work.

Instead, I ended up rethinking what “identity” even means.

And honestly, once that clicks — everything else in Web3 starts to make a lot more sense.

DEV Community: Vinay

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

Step 1: Create a Basic Mint

Step 2: Add On-Chain Metadata

Step 3: Attach a Transfer Fee

Step 4: Full Lifecycle in One Session

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

What Surprised Me

What's Next

Resources

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

The analogy that rewired my brain - The Filing Cabinet

💡 What This Explains

📋 The Four Fields

💰 Rent Exemption

🔑 Three Things That Suddenly Make Sense

🎯 Why This Matters

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

🧠 The Analogy

⚡ The Part That Surprised Me

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

⚙️ What This Changes

Understanding Solana's transaction anatomy

Sending Your First SOL Transfer (Devnet, via CLI)

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

🧠 What a Wallet Actually Does

🔑 From Usernames to Keypairs: Understanding Identity on Solana

⚠️ What You Lose

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

💻 The Code Difference

🎯 Why This Matters

📊Solana Is a Public Spreadsheet — Not Your Private Database

🧠 The Analogy

⚙️ What This Changes

🔥 The Hardest Adjustment

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

Sending Your First SOL Transfer (Devnet, via CLI)

Understanding Solana's transaction anatomy

Understanding Solana's transaction anatomy

📖 Overview

🎯 Objective

⚙️ What I Did

🧠Mental Model Upgrade

Sending Your First SOL Transfer (Devnet, via CLI)

Environment Requirements

1. Configure CLI to Devnet

2. Check Balance and Fund Wallet

3. Generate a Recipient Keypair

4. Execute the Transfer

5. Verify State Changes

6. Inspect the Transaction

Full Command Flow

What This Demonstrates

A few early takeaways from learning Solana

I’ve been exploring Solana for the past few days and a few things stood out pretty quickly

Two weeks with Solana - Personal experience

What Took a Bit to Understand

Building in the Browser

MLH Session

Still Figuring Out

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

1. Why extractable: true is required

2. Why "pkcs8" and not "raw"?

🧩 What I Did Next

⚖️ Big Takeaway

🔑 From Usernames to Keypairs: Understanding Identity on Solana

🏨 Web2 vs Web3: A Simple Analogy

🔑 Identity = Keypair

🤯 One Keypair = My Identity

🔐 “Logging In” Doesn’t Exist

🏁 Final Thought

1. Why `extractable: true` is required