DEV Community: Tobi Ayinmiro

Creating My First Token on Solana Devnet as a Web2 Developer

Tobi Ayinmiro — Mon, 25 May 2026 10:45:56 +0000

As a web developer, I’m used to building systems where currencies, rewards, and balances live inside databases controlled by the backend.

This week was my first time creating an actual on-chain token on Solana, and honestly, it changed how I think about digital assets.

Instead of storing balances in a database table, the blockchain itself handled everything — minting, transfers, metadata, and verification.

In this post, I’ll walk through how I created my first token on Solana devnet using Token-2022, added metadata to it, minted supply, and transferred tokens between wallets.

What I Needed Before Starting

Before creating the token, I needed:

Solana CLI installed
SPL Token CLI installed
A funded devnet wallet
Solana configured to devnet

First, I configured Solana to use devnet:

solana config set --url devnet

Then I requested free devnet SOL:

solana airdrop 2

Creating My First Token Mint

Unlike the older SPL Token Program, I used the newer Token-2022 Program because it supports extensions like:

Metadata
Transfer fees
Interest-bearing tokens
Non-transferable (soulbound) tokens

Here’s the command I used:

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

After running it, Solana generated a token mint address for me.

At this point, the token technically existed on-chain, but it still had no identity.

It was basically just a random string of characters.

Adding Metadata to the Token

This was one of the coolest parts for me.

I learned that Solana’s Token-2022 Program allows metadata to live directly on-chain instead of depending entirely on separate programs.

I initialized the token metadata like this:

spl-token initialize-metadata \
  <TOKEN_MINT_ADDRESS> \
  "<TOKEN_NAME>" \
  "<TOKEN_SYMBOL>" \
  "<TOKEN_METADATA_URI>"

Example placeholders:

<TOKEN_MINT_ADDRESS> → your token mint address
<TOKEN_NAME> → e.g. MyCoin
<TOKEN_SYMBOL> → e.g. MYC
<TOKEN_METADATA_URI> → public JSON metadata link

At this point, my token finally had:

a name
a symbol
metadata attached to it

That made it feel like a real digital asset instead of just raw blockchain data.

Creating a Token Account

One concept that confused me initially was token accounts.

I assumed my wallet could directly hold tokens.

That’s not exactly how Solana works.

On Solana:

the mint defines the token
token accounts hold balances for that token

So before I could receive my token, I had to create a token account:

spl-token create-account <TOKEN_MINT_ADDRESS>

This generated an associated token account tied to my wallet and token mint.

Minting My First Supply

Now came the exciting part.

I minted 1000 tokens into my token account:

spl-token mint <TOKEN_MINT_ADDRESS> 1000

Then I checked the balance:

spl-token balance <TOKEN_MINT_ADDRESS>

And seeing this:

it felt surprisingly rewarding to be honest

Creating a Second Wallet

To test transfers properly, I created a second wallet:

solana-keygen new \
  --outfile ~/second-wallet.json \
  --no-bip39-passphrase

This simulated sending tokens to another user.

Transferring Tokens

I transferred 250 tokens to the second wallet:

spl-token transfer \
  <TOKEN_MINT_ADDRESS> \
  250 \
  $(solana-keygen pubkey ~/second-wallet.json) \
  --fund-recipient \
  --allow-unfunded-recipient

The --fund-recipient flag automatically created the recipient’s token account if it didn’t already exist.

That was another thing that clicked for me:
even receiving tokens on Solana involves token accounts behind the scenes.

Verifying the Transfer

I checked both balances.

My wallet balance:

spl-token balance <TOKEN_MINT_ADDRESS>

Recipient wallet balance:

spl-token balance \
  --owner $(solana-keygen pubkey ~/second-wallet.json) \
  <TOKEN_MINT_ADDRESS>

The balances showed:

750 in my wallet
250 in the second wallet

The transfer worked successfully.

What Confused Me Initially

One of the biggest things that confused me was the difference between:

wallet addresses
token accounts
token mints

At first, I thought:

“Why can’t I just send directly to the wallet?”

But Solana separates:

the wallet owner
the token account holding balances
the token definition itself

Once that clicked, the entire token system started making much more sense.

What Surprised Me Most

The biggest surprise was realizing how much logic the blockchain itself handles.

In Web2, building something similar would require:

database tables
backend APIs
transfer validation
balance management
permission handling

On Solana:

the protocol handles balances
token programs enforce rules
transactions are verifiable on-chain

It felt like moving backend business logic directly into infrastructure.

Final Thoughts

Creating my first token on Solana made Web3 feel much less abstract.

Before this, tokens felt like mysterious blockchain concepts.

Now I understand that they’re actually programmable digital assets with rules enforced directly by the protocol.

This was my first step into Solana development, and it definitely won’t be the last.

Next, I want to explore:

transfer fee extensions
soulbound tokens
Solana programs with Rust
building full-stack dApps

If you’re coming from Web2 development, my advice is simple:

Start building.

Things make much more sense once you actually create something yourself.

link to the token: https://explorer.solana.com/address/vXRh8HHmjeFvpQgt19EEqf6iaAQxqM8NtCdTwCAqozu?cluster=devnet

Understanding Solana’s Account Model as a Web2 Developer

Tobi Ayinmiro — Mon, 18 May 2026 08:56:42 +0000

Understanding Solana’s Account Model as a Web2 Developer

When I started learning Solana, I expected wallets and smart contracts to work like Ethereum. Instead, I discovered something very different:

On Solana, everything is an account.

At first, that sounded simple. But it completely changed how I thought about blockchain architecture.

As a Web2 developer, I’m used to systems that look like this:

Frontend → Backend API → Database

The backend stores logic
The database stores state

Solana works differently — but underneath it all is a surprisingly familiar mental model.

The easiest way to understand Solana’s account model is to think of it like a filesystem or operating system:

Accounts = files
Programs = executable applications
Data accounts = databases/documents
The System Program = operating system kernel

Once this clicks, the rest of Solana becomes much easier to understand.

Everything on Solana Is an Account

Unlike Ethereum, which separates:

externally owned accounts (wallets)
contract accounts (smart contracts)

Solana uses a unified account model for everything.

On Solana:

wallets are accounts
programs are accounts
tokens are accounts
NFT metadata lives in accounts

Everything exists inside one giant flat key-value store.

key   = public address
value = account data

Or, if you’re thinking like a backend developer:

Map<PublicKey, Account>

That simplicity is one of the reasons Solana can process transactions efficiently.

Every Solana Account Has the Same Structure

Every account contains the same core fields:

Field	Purpose
`lamports`	SOL balance
`data`	Raw bytes storing state
`owner`	Program allowed to control the account
`executable`	Whether the account contains executable code
`rent_epoch`	Deprecated rent-related field

Let’s break them down.

1. Lamports

Lamports are the smallest unit of SOL.

1 SOL = 1,000,000,000 lamports

Similar to:

dollars → cents
bitcoin → satoshis

Example:

500000000 lamports = 0.5 SOL

Lamports are used for:

transaction fees
storing accounts
transferring SOL

2. Data

The data field stores arbitrary bytes.

This is where programs save state, including:

token balances
NFT metadata
usernames
protocol configuration
DeFi positions

Unlike traditional databases, Solana does not store JSON directly.

Everything is serialized into bytes.

For Web2 developers, this feels more like:

binary storage
buffers
low-level database records

3. Owner

The owner field is one of the most important concepts in Solana.

It defines which program controls an account.

Example:

Owner: Token Program

That means only the Token Program can:

modify the account’s data
debit lamports from the account

This is the foundation of Solana’s security model.

Ownership Rules

Solana follows a surprisingly simple set of rules:

Only the owner program can:

modify account data
remove lamports from the account

But anyone can:

send lamports to a writable account

Without ownership rules, any program could edit any account’s data.

Imagine random APIs directly modifying your production database tables.

That would be chaos.

Solana prevents this through program ownership.

4. Executable

The executable field is simply a boolean.

true  = account contains program code
false = account stores data

If executable = true, the account contains compiled program code.

Otherwise, it’s just a data account.

5. Rent Epoch

This field is mostly deprecated today.

Historically, it related to Solana’s rent system.

Now it’s typically set to a maximum value and ignored in most cases.

The Biggest Mindset Shift: Programs Don’t Store Their Own State

This was the concept that confused me the most.

On Solana:

Programs are stateless.

Smart contracts do not permanently store their own internal state.

Instead:

program accounts store executable code
separate accounts store persistent data

This is very different from Ethereum.

The Web2 Analogy That Made It Click

Think of a Solana program like a Node.js backend service.

The backend server:

contains logic
processes requests
validates data

But it does not permanently store all user data in memory.

Instead, it reads from and writes to a database.

Solana works the same way:

Program Account = Backend Server
Data Accounts   = Database Records

Programs execute logic.

Accounts store persistent state.

Example: A Todo App on Solana

Imagine building a Todo app.

Program Account

Contains logic like:

createTodo()
updateTodo()
deleteTodo()

Data Accounts

Store actual user data:

- todo text
- completed status
- owner wallet

The program modifies data accounts whenever users interact with the app.

Why Solana Separates Code From State

At first, this architecture feels inconvenient.

But it enables several powerful features:

parallel transaction execution
better scalability
clearer ownership rules
flexible storage patterns

Because accounts are separate from programs, Solana can determine which transactions touch which accounts.

That allows many transactions to execute simultaneously.

This is one of the major reasons Solana is fast.

Rent Exemption Explained

Every account on Solana must maintain a minimum balance to stay on-chain.

This is called:

rent exemption

The required amount depends on the account’s data size.

More data requires:

more storage
more lamports

For a tiny account with no additional data, the requirement is roughly:

~0.00089 SOL

You can check rent requirements with:

solana rent 0

Or via RPC:

getMinimumBalanceForRentExemption()

Why Rent Exists

In Web2 systems:

servers have storage limits
databases cost money

Solana validators also store account data permanently.

Without rent requirements, attackers could spam the network with millions of useless accounts.

Rent helps prevent storage abuse.

Reading a Real Solana Account

Using the CLI:

solana account <ACCOUNT_ADDRESS>

You might see:

Public Key: 7xKXtg2CW...
Balance: 0.002 SOL
Owner: System Program
Executable: false
Rent Epoch: 18446744073709551615
Data Length: 0

Here’s how to interpret it:

Field	Meaning
Public Key	Account address
Balance	SOL stored in the account
Owner	Program controlling the account
Executable	Whether it stores code
Data Length	Amount of stored data
Rent Epoch	Deprecated field

Once you understand these fields, Solana Explorer becomes much easier to read.

Example of an account detail

The System Program

One program you’ll constantly encounter is the System Program.

Think of it like the operating system kernel.

It handles:

account creation
SOL transfers
ownership assignment
storage allocation

Almost every Solana application interacts with it.

Comparing Solana to Ethereum

Ethereum

contracts store their own state
different account types exist
code and storage are tightly coupled

Solana

everything is an account
programs are stateless
state lives in separate accounts
unified account architecture

This is one of the biggest conceptual shifts for Web2 developers entering Solana.

Final Mental Model

Here’s the simplest way I now think about Solana:

Accounts       = Files
Programs       = Executable apps
Data Accounts  = Databases/documents
System Program = Operating system

Once the account model clicks, many other Solana concepts become easier to understand:

tokens
NFTs
staking
DeFi protocols
DAOs

They all build on the same foundation:

accounts
ownership
programs
data storage

And honestly, that unified design is one of the things that makes Solana so interesting to learn as a developer.

Solana Transactions Explained for Backend Developers

Tobi Ayinmiro — Sat, 09 May 2026 15:17:33 +0000

Learning Solana transactions completely changed how I think about backend systems.

At first, I treated transactions like normal API requests:

client → server → database → response.

But Solana transactions are different.

They’re signed, temporary, atomic state changes sent to a decentralized network. Instead of “calling a server,” you prepare instructions that validators execute on-chain.

The biggest shift for me was understanding:

recent blockhashes
signatures
atomic execution
compute limits

One thing that made it click for me was actually building and sending transactions with "@solana/kit".

import {
  createSolanaRpc,
  devnet,
  generateKeyPairSigner,
  airdropFactory,
} from "@solana/kit";

const rpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));

const signer = await generateKeyPairSigner();

const airdrop = airdropFactory({ rpc });

await airdrop({
  recipientAddress: signer.address,
  lamports: 1_000_000_000n,
});

console.log("Airdrop complete");

Oddly enough, failed transactions taught me the most.

Breaking transactions on devnet helped me understand how Solana programs actually execute internally.

Web3 development feels very different once you stop thinking in request/response patterns.

Solana transfer

Tobi Ayinmiro — Tue, 05 May 2026 10:36:40 +0000

Hey guys i just sent my first solana and we can all see it. blockchain = transparency

Understand transaction anatomy

Tobi Ayinmiro — Tue, 05 May 2026 09:48:17 +0000

Ever wondered what’s inside a Solana transaction? 👀
Just drop the signature into the explorer:https://explorer.solana.com/ and unlock everything status, wallets, tokens, and logs. Blockchain = open books.

From Confusion to Clarity: My Second Week with Solana

Tobi Ayinmiro — Sat, 02 May 2026 16:41:29 +0000

Week one felt like learning new vocabulary. Week two with Solana felt like trying to form actual sentences.
At first, nothing made sense accounts, lamports, RPC calls. But then something clicked: blockchain isn’t magic. It’s just a different way of organizing and accessing data.
The turning point for me was building a simple dashboard that reads on-chain data. Seeing real values update made everything feel tangible.
Compared to traditional APIs, working with RPC feels more raw and direct. There’s no middle layer simplifying things you’re responsible for understanding what the data means.
What surprised me most is how much responsibility is pushed to the developer. There’s power in that, but also complexity.
I’m still figuring out how to design systems properly in this environment, but I’m starting to see the bigger picture and I'm excited for what's to come.

100DaysOfSolana

Traditional Database vs Solana Accounts

Tobi Ayinmiro — Thu, 30 Apr 2026 13:33:47 +0000

Hey guys, i did a comparison of traditional database and solana account

Exploring web3

Tobi Ayinmiro — Sun, 26 Apr 2026 15:58:21 +0000

Day 7 of #100DaysOfSolana

I created my Solana devnet wallet and checked my balance for the first time. Seeing the transaction appear on-chain made Web3 feel real everything is verified publicly.

Next, I’m excited to build something that interacts with the blockchain using my wallet.

From Usernames to Keypairs: Understanding Identity on Solana (for Web2 Developers)

Tobi Ayinmiro — Sat, 25 Apr 2026 17:03:15 +0000

If you’ve spent most of your time building in Web2, “identity” probably feels familiar and straightforward. It’s your email, your username, maybe an OAuth login through Google or GitHub. But under the hood, that identity is fragmented and controlled by the platforms you use. Each service owns your credentials, stores your data, and ultimately decides whether you can access your account.
Solana and blockchains in general flip that model on its head.
Identity Starts with a Keypair
On Solana, your identity is not a username or an email. It’s a cryptographic keypair.
A keypair consists of:

A public key (your address, safe to share)
A private key (your secret, never to be shared)
If you’ve ever used SSH, this should feel familiar. You generate a keypair, put the public key on a server, and prove your identity by using your private key. Solana works in a very similar way but instead of logging into a single server, you’re interacting with an entire decentralized network.
Your public key becomes your universal identity across all Solana apps. There’s no signup form, no password, no “forgot password” flow. If you have the private key, you are the identity. If you lose it, there’s no recovery.
Public Keys vs Usernames
In Web2, usernames are human-readable and stored in centralized databases. Someone owns that database—and they can change, restrict, or delete your account.
On Solana, your identity looks more like this:
14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5
It’s a Base58-encoded public key derived from cryptography, not chosen by you. It’s not memorable, but it’s globally unique and doesn’t rely on any central authority.
This difference is important:
A username exists because a company says it does
A public key exists because math proves it does
There’s no central registry controlling identities. The network simply verifies that any action tied to a public key has been signed by the corresponding private key.
Ownership Without Permission
In Web2, you don’t truly “own” your account. You’re granted access by a platform. That platform can suspend you, lock you out, or change the rules at any time.
On Solana, ownership is purely cryptographic.
If you control the private key:
You can sign transactions
You can move tokens
You can interact with
programs
If you don’t, you can’t. There is no admin override.
This removes an entire layer of trust. You’re no longer trusting a company to manage your identity you’re trusting the underlying cryptography.
But it also introduces responsibility. There’s no “reset password” button. Wallets help manage keys, but ultimately, the security of your identity is in your hands.
One Identity, Many Applications
Here’s where things get powerful.
In Web2, your identity is siloed. Your GitHub account doesn’t automatically connect to your banking app or your Twitter profile unless integrations are built.
On Solana, your public key works everywhere by default.
That same identity can:
Hold tokens (like assets in your wallet)
Interact with decentralized applications (dApps)
Vote in governance systems
Build a reputation tied to on-chain activity
No app needs to “create” your account. They just read from the blockchain and verify your signature.
This creates a shared identity layer across the entire ecosystem.
Identity as a Foundation
On-chain identity isn’t just a replacement for usernames it’s the foundation for everything else.
Because your identity is:

Self-custodied (you control it)
Permissionless (no one can block you)
Portable (works across all apps) it enables entirely new patterns which includes: Owning assets without intermediaries Participating in decentralized governance Building verifiable reputation systems Instead of identity being fragmented and controlled, it becomes unified and user-owned. Final Thoughts The shift from Web2 to Solana identity can feel uncomfortable at first. Losing password resets and human-readable usernames seems like a step backward. But it’s actually a shift in power. In Web2, identity is something you borrow. In Solana, identity is something you own. Once that clicks, everything else: wallets, tokens, dApps starts to make a lot more sense. And that’s the real goal of understanding on-chain identity: realizing that the keypair in your wallet isn’t just a tool it’s you on the network. 100daysofsolana, solana, web3, blockchain, and beginners