DEV Community: Samuel Akoji

From npm install to Soulbound Tokens: My First 5 Days Building on Solana

Samuel Akoji — Tue, 26 May 2026 10:57:02 +0000

Solana's token system is nothing like what I expected coming from Web2 frontend dev. Here's everything I learned in 5 days from minting my first token to locking one so it can never move again.

Context: where I started

I came in with a Computer Science background, decent TypeScript skills, and a strong understanding of crypto from years of community building and education in Nigeria. But writing blockchain logic? That was new territory.

My goal was simple: understand how tokens actually work on Solana at the code level, not just the concept level. I started on Day 29 with a blank terminal and one mission mint something.

The walkthrough

Day 29–30 First mint with the Token Extensions Program

The first decision was which program to use. Solana has two: the original SPL Token Program and the newer Token Extensions Program (also called Token-2022). I chose Token Extensions from the start because it supports advanced features transfer fees, metadata, and non-transferable tokens without needing a separate program.

import { createMint } from "@solana/spl-token";

const mint = await createMint(
  connection,
  payer,           // fee payer keypair
  payer.publicKey, // mint authority
  null,            // freeze authority
  9,               // decimals
  undefined,
  undefined,
  TOKEN_2022_PROGRAM_ID // this is what makes it Token Extensions
);

The TOKEN_2022_PROGRAM_ID at the end is everything. Without it, you're on the original program and lose access to extensions entirely.

Day 31 Transfer fees and why they exist

Transfer fees let a token creator take a percentage of every transfer. The implementation is more nuanced than you'd expect fees are withheld on destination accounts, not auto-transferred. You have to harvest them manually.

await createInitializeTransferFeeConfigInstruction(
  mint,
  transferFeeConfigAuthority,
  withdrawWithheldAuthority,
  100,          // 1% (basis points — so 100 = 1%)
  BigInt(1000)  // max fee cap in token units
);

What surprised me: The fee is withheld on the recipient's account, not deducted before transfer. The sender sends the full amount, the recipient gets slightly less, and the creator must run a separate harvest instruction to collect. Very different from how payment fees work in Web2.

Day 32 Metadata directly on the token

With the original Token Program, metadata lives on a separate Metaplex account. Token Extensions lets you attach it directly to the mint name, symbol, URI, and custom key-value fields.

await tokenMetadataInitialize(
  connection,
  payer,
  mint,
  updateAuthority,
  mint,            // mint authority signs
  "MyToken",       // name
  "MTK",           // symbol
  "https://...",   // URI pointing to JSON metadata
  TOKEN_2022_PROGRAM_ID
);

You can call tokenMetadataUpdateField later to add arbitrary key-value pairs useful for attaching on-chain properties to a token after the fact.

Day 33 Non-transferable (soulbound) tokens

This was my favourite session. A non-transferable token can be minted but never moved. Once it's in a wallet, it stays there. The extension enforces this at the program level not through off-chain rules that can be bypassed.

const extensions = [ExtensionType.NonTransferable];
const mintLen = getMintLen(extensions);

const createAccountIx = SystemProgram.createAccount({
  fromPubkey: payer.publicKey,
  newAccountPubkey: mintKeypair.publicKey,
  space: mintLen,
  lamports: await connection.getMinimumBalanceForRentExemption(mintLen),
  programId: TOKEN_2022_PROGRAM_ID,
});

const initNonTransferableIx =
  createInitializeNonTransferableMintInstruction(
    mintKeypair.publicKey,
    TOKEN_2022_PROGRAM_ID
  );

Use cases: event credentials, certificates, loyalty status, proof of participation anything where you want on-chain proof of something that shouldn't be sold or transferred.

What surprised me

Extension initialization order matters. Extensions must be initialized in a specific sequence during mint creation. Getting it wrong produces cryptic transaction errors. The docs mention it, but it doesn't really land until you see the failure.

Rent-exemption is a real upfront cost. Every account on Solana must hold enough SOL to be rent-exempt. The more extensions you add, the larger the account, and the more lamports you need. You can't stack five extensions and expect the same fee as one account for this in any production setup.

What's next

Interest-bearing tokens: tokens that accrue value over time, entirely on-chain
Permanent delegate extension: assigning an authority that can always move tokens regardless of owner
Building a frontend UI to interact with these programs
Exploring real-world use cases for communities across Africa: event credentials, loyalty tokens, proof-of-participation badges

If you're also learning Solana or building in the African Web3 space, drop a comment or follow along. Building in public, one day at a time.

Solana Stores Bytes, Not JSON. Here's What That Actually Means

Samuel Akoji — Sat, 23 May 2026 22:17:18 +0000

I spent weeks reading Solana accounts through explorers and RPC calls, seeing nicely formatted data token balances, authorities, supply numbers and thinking that's what Solana stored.

It isn't. Solana stores raw bytes.

Day 24 of #100DaysOfSolana made this uncomfortably real.

The Moment It Clicked

The challenge was to fetch the Wrapped SOL mint account from mainnet and decode it three different ways: using an SPL Token decoder, manually byte by byte, and via the RPC's jsonParsed output.

When I fetched the raw account data it looked like this:

82 bytes of nothing, apparently. No field names. No labels. Just numbers.

But here's the thing those 82 bytes contain everything: the total supply of Wrapped SOL, the number of decimals, the mint authority, the freeze authority, and whether the mint has been initialized. All of it, packed tightly into a flat array.

How Programs Know What the Bytes Mean

This is the key insight: the program that owns an account defines what its bytes mean.

The Token Program knows that bytes 0–3 are a discriminator, bytes 4–35 are the mint authority option, bytes 36–43 are the supply, byte 44 is the decimal count, and so on. It's essentially a binary schema baked into the program's code.

When you decode the account three ways with the SPL codec, manually, and via jsonParsedall three produce the same output:


json
{
  "mintAuthority": null,
  "supply": "0",
  "decimals": 9,
  "isInitialized": true,
  "freezeAuthority": null
}
Three approaches. One truth. The bytes were the truth all along.
Why This Changes How You Think About On-Chain Data
Solana explorers are doing you a favour you don't see. Every time you open explorer.solana.com and see a nicely formatted token account, the explorer is decoding those raw bytes using the program's known schema and presenting the result as readable JSON.
If you're building your own indexer, your own program, or your own tooling you don't get that favour for free. You need to know the schema. You need to decode the bytes yourself.
This is why Solana programs publish IDLs (Interface Definition Languages) so that clients know how to decode the data their program writes. Without an IDL, you're reading tea leaves.
The Bigger Picture
In Web2, your database stores typed fields. VARCHAR, BIGINT, BOOLEAN the database engine enforces types, and your ORM maps them to objects automatically.
On Solana, the "database" is just bytes. The "ORM" is the program's codec. The "schema" is whatever the program's developers decided and (hopefully) documented.
That's a lot more power and a lot more responsibility.
Raw bytes go in. Structured data comes out. Understanding what's in between is what separates someone who uses Solana from someone who understands it.

Solana's System Program Accounts: A Developer's Hands-On Inspection Guide

Samuel Akoji — Fri, 22 May 2026 22:00:00 +0000

Everything Is an Account Let's Prove It

One of the first things you hear about Solana is "everything is an account." It sounds like marketing. Day 25 of 100 Days of Solana makes it concrete: you open the CLI, inspect real accounts your wallet, the System Program, native programs, sysvar accounts and see that the claim is literally true.

This is a hands-on walkthrough of exactly what to run and what you'll find.

Step 1: Inspect Your Own Wallet

Start with what you know:

solana account <YOUR_WALLET_ADDRESS> --url devnet

Output:
Public Key:
Balance: 1.247 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 0

Four fields. This is the raw account model for a wallet:

Owner: 11111111111111111111111111111111 the System Program. Every regular wallet is owned by it. This is why only the System Program can process SOL transfers from your wallet.
Executable: false your wallet is data, not code.
Data: empty wallets store no extra data, just the SOL balance tracked in lamports.
Rent Epoch: 0 means rent-exempt. Funded above the minimum threshold.

Step 2: Inspect the System Program

Now inspect the program that owns your wallet:

solana account 11111111111111111111111111111111 --url devnet

Output:
Public Key: 11111111111111111111111111111111
Balance: 1 SOL
Owner: NativeLoader1111111111111111111111111111111
Executable: true
Data Length: 14 bytes

Key differences from your wallet:

Executable: true this is a program, not a data account
Owner: NativeLoader native programs are loaded by the validator itself, not deployed via the BPF loader
Data Length: 14 bytes almost nothing. Native program code lives in the validator binary, not in account data. The account is essentially a pointer.

Same four fields as your wallet. One boolean flipped. That's the entire difference between "wallet" and "program" in Solana's account model.

Step 3: Inspect the BPF Loader

solana account BPFLoaderUpgradeab1e11111111111111111111111 --url devnet

Output:
Executable: true
Owner: NativeLoader1111111111111111111111111111111
Data Length: 36 bytes

The BPF Loader is the program that deploys and manages all user-written programs on Solana. When you deploy a program with solana program deploy, you're invoking the BPF Loader. This is the runtime stack made visible: NativeLoader owns the BPF Loader, which owns your programs.

Step 4: Inspect Sysvar Accounts

Sysvar accounts are read-only accounts the network maintains with live runtime data.

Clock sysvar current slot, epoch, and timestamp:

solana account SysvarC1ock11111111111111111111111111111111 --url devnet

Rent sysvar the current rent rate:

solana account SysvarRent111111111111111111111111111111111 --url devnet

Recent Blockhashes sysvar:

solana account SysvarRecentB1ockHashes11111111111111111111 --url devnet

All of these are just accounts same four fields, different data payloads. What makes them special is that the network writes to them every slot.

Step 5: Compare All Four

Account	Owner	Executable	Data
Your wallet	System Program	false	empty
System Program	NativeLoader	true	14 bytes
BPF Loader	NativeLoader	true	36 bytes
Clock sysvar	Sysvar program	false	40 bytes

Every row uses the same four fields. There is no special "wallet type" or "program type" in Solana's runtime just accounts with different owners, executability flags, and data payloads.

What This Teaches You

The System Program is the foundation of everything you've done in the first 25 days:

Day 1: Airdrop → System Program created your wallet account
Days 15–17: SOL transfers → System Program executed every one
Days 22–24: Account inspection → you were reading accounts the System Program owns

Every time you sent SOL, created a wallet, or funded a new account, the System Program was running the instruction. Day 25 just makes it visible.

I Inspected the System Program and It Looked Just Like My Wallet

Samuel Akoji — Fri, 22 May 2026 20:23:03 +0000

The Challenge

Day 25 of 100 Days of Solana: inspect system program accounts. Your wallet, the System Program, native programs, sysvar accounts. Use the CLI and Explorer. Understand how they differ and how they're the same.

I'd been hearing "everything is an account" for 25 days. This was the day I actually verified it.

Starting With My Wallet

solana account <MY_ADDRESS> --url devnet

Output:
Balance: 1.247 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 0

The owner field jumped out: 11111111111111111111111111111111. The System Program. My wallet isn't a special type of thing — it's an account that the System Program owns and manages. Every SOL transfer I've ever made was the System Program modifying this row.

Inspecting the System Program Itself

solana account 11111111111111111111111111111111 --url devnet

Output:
Balance: 1 SOL
Owner: NativeLoader1111111111111111111111111111111
Executable: true
Data Length: 14 bytes

The System Program the program that underlies every wallet on Solana, that has processed billions of transactions is an account with 14 bytes of data and a 1 SOL balance. The executable: true flag is the only thing that distinguishes it from my wallet structurally. Same schema. One boolean different.

The 14 bytes confused me at first. After some digging: native programs have their code compiled directly into the validator binary. The account is essentially a registry entry a marker that says "this address is the System Program."

The BPF Loader

solana account BPFLoaderUpgradeab1e11111111111111111111111 --url devnet

Executable: true
Owner: NativeLoader
Data Length: 36 bytes

The ownership chain: NativeLoader → BPF Loader → my future programs. Three levels, all expressed as account ownership fields.

Sysvar Accounts

solana account SysvarC1ock11111111111111111111111111111111 --url devnet

The Clock sysvar holds the current slot, epoch, and unix timestamp. Updated every slot by the runtime. Programs that need time-based logic read this account.

What surprised me: it's just an account. executable: false, owned by the Sysvar program, 40 bytes of encoded data. The same structure as everything else.

The Mental Model I Built

Every account sits on a spectrum from "pure data" to "pure code," determined entirely by two fields:

executable is this account code or data?
owner which program has authority over this account?

Account type	executable	owner
Wallets	false	System Program
Regular programs	true	BPF Loader
Native programs	true	NativeLoader
Sysvar accounts	false	Sysvar program
Your data accounts	false	your program

No special types. No separate registries. One table, differentiated entirely by field values.

The CLI Commands Worth Bookmarking

solana account 11111111111111111111111111111111              # System Program
solana account BPFLoaderUpgradeab1e11111111111111111111111  # BPF Loader
solana account SysvarC1ock11111111111111111111111111111111  # Clock sysvar
solana account SysvarRent111111111111111111111111111111111  # Rent sysvar

One command. Any account. The entire network is readable.

SPL Tokens Explained: Mints, Token Accounts, and Why Solana Separates Them

Samuel Akoji — Thu, 21 May 2026 21:56:58 +0000

The Question Everyone Asks

When developers first create a token on Solana, they run into an immediate source of confusion: why are there two addresses? You create a token and get one address. You create an account to hold that token and get a second address. What's going on?

The answer is one of Solana's most elegant design decisions.

The Two Core Concepts: Mint vs Token Account

The Mint Account the token's definition. Stores total supply, decimal places, mint authority (who can create more), and freeze authority. There is exactly one mint account per token type. The mint address is the token's identity.

The Token Account where your balance lives. Owned by the Token Program, stores which mint it belongs to, which wallet owns it, and the current balance. Every wallet that holds a token has its own token account for that token.

Why Are They Separated?

Reason 1: The Token Program needs to own the data

On Solana, only the owner program of an account can modify that account's data. Token balances live in accounts owned by the Token Program which means only the Token Program can modify them. If balances lived in wallet accounts (owned by the System Program), the Token Program would have no authority over them.

The separation is a direct consequence of Solana's ownership model: to control data, you must own the account that stores it.

Reason 2: One program, many tokens

The Token Program manages every SPL token USDC, USDT, every project token, every NFT. It can do this because each token's mint and each wallet's token accounts are separate accounts. All SPL tokens share the same program code, making it more efficient and auditable than Ethereum's model where each ERC-20 is a separate contract.

Reason 3: Parallelism

Because each wallet's token balance is in its own account, transfers between different wallets can be processed simultaneously. This contributes to Solana's throughput.

The Associated Token Account

Given a wallet address and a mint address, there's a standard formula to compute the canonical token account address:

ATA address = PDA(wallet_address, token_program_id, mint_address)

This means any program can calculate where a wallet's balance should be without looking it up. Wallets and apps all agree on one canonical account per token per wallet.

The Full Lifecycle

# 1. Create the mint
spl-token create-token
# → MINT_ADDRESS, supply: 0

# 2. Create your token account
spl-token create-account MINT_ADDRESS
# → TOKEN_ACCOUNT_ADDRESS, balance: 0

# 3. Mint supply
spl-token mint MINT_ADDRESS 100
# → supply: 100, your balance: 100

# 4. Transfer
spl-token transfer MINT_ADDRESS 10 RECIPIENT_WALLET
# → your balance: 90, recipient balance: 10

# 5. Burn
spl-token burn TOKEN_ACCOUNT MINT_ADDRESS 50
# → your balance: 40, total supply: 50

What This Looks Like in Explorer

Look up your mint address in explorer.solana.com (devnet) you'll see supply and mint authority decoded. Look up your token account you'll see mint, owner wallet, and balance. Two accounts. One token system. The Token Program is the invisible enforcer between them.

The Bigger Picture

The mint + token account model is the foundation of everything in Epoch 2. Metadata, transfer fees, freeze authority, NFTs all of it builds on this same two-account primitive. Understanding why they're separated is the foundation for everything that follows.

I Used Solana Explorer Like Chrome DevTools Here's What I Found

Samuel Akoji — Thu, 21 May 2026 16:28:34 +0000

DevTools for the Blockchain

Every Web2 developer has a relationship with Chrome DevTools. You open it without thinking. Network tab to check API calls, Console to catch errors, Application tab to inspect localStorage. It's the lens you use to see what your app is actually doing.

Day 28 of 100 Days of Solana sent me to Solana Explorer with the same mindset: just look at the chain. No task, no script. Just explore.

Here's what I found when I treated Explorer like DevTools and what each discovery maps to in Web2 terms.

Explorer used: explorer.solana.com Devnet, then Mainnet

The Network Tab: My Transaction History

My wallet's transaction history in Explorer is every "request" my wallet has sent to the blockchain since Day 1. 27 transactions, chronological. Each shows which program was called, whether it succeeded, the fee paid, and the net SOL change.

I found a failed transaction from Day 19. In the log messages, the error was clear:

Program log: Error: insufficient lamports for instruction

The equivalent of a 400 Bad Request except permanently recorded on a public blockchain. And I paid 5,000 lamports for the privilege of failing.

Web2 parallel: Failed API calls don't charge you. Failed Solana transactions do. The fee covers the computational work validators did to process the transaction, even if the result was rejection.

The Console: Log Messages

On Solana, programs emit log messages using msg!() and those messages surface in Explorer under Log Messages for any transaction.

For a complex interaction on mainnet:

Program log: Instruction: Swap
Program log: Swap: in_amount=1000000, out_amount=997234
Program log: Fee collected: 2766 lamports
Program JUP6... success

Web2 parallel: Imagine if every API call your app made logged its internal execution to a public server that anyone could read forever. That's exactly what on-chain program logs are.

The Application Tab: Account Data

In Explorer, clicking any account shows its decoded data. I clicked a token account in my wallet and Explorer decoded it: mint address, owner wallet, balance. All decoded from a binary blob by Explorer knowing the Token Program's schema.

Web2 parallel: Inspecting a localStorage entry and finding {"userId": "abc123", "balance": 1000000, "currency": "USDC"} except this lives on a blockchain, not your browser.

The Elements Tab: The System Program

I searched for 11111111111111111111111111111111. Balance: 1 SOL. Executable: Yes. Data: 14 bytes. Transaction count: millions.

This is the program behind every SOL transfer I've ever made. It has a 1 SOL balance and almost no on-chain data because native programs live in the validator binary.

Web2 parallel: The System Program is like the Node.js runtime the foundational layer everything builds on. You rarely think about it directly, but everything goes through it.

Going Live: Mainnet in Real Time

I watched the Explorer homepage for five minutes. Simple SOL transfers: 2 accounts, 5000 lamport fee. DEX swaps: 10-14 accounts, 3-4 programs, still 5000 lamport base fee.

Web2 parallel: Watching your server access logs in real time except it's a public server processing millions of requests per second and every request is globally visible forever.

What This Changed for Me

Explorer made the chain feel real in a way devnet never quite does. Devnet is practice. Mainnet is the game. Explorer shows you both.

Solana's Account Types Are Just Database Rows With Different Flags

Samuel Akoji — Wed, 20 May 2026 15:00:00 +0000

The Surprise of Day 25

When I got to Day 25 of 100 Days of Solana and inspected the System Program account for the first time, I expected something special. Some distinct "program" structure, different from the wallet accounts I'd been working with.

Instead I got the same four fields I'd already seen a hundred times: balance, owner, executable, data. The only difference was executable: true.

That was the moment "everything is an account" stopped being a tagline and became something I actually understood. This post explains what I found and what it means if you're coming from a Web2 background.

The Web2 Mental Model You Need to Drop

In Web2, different things have different types. A user account is a database row. Application code is a file on a server. Configuration data is an environment variable or a config service. They're stored differently, accessed differently, and reasoned about differently.

Solana collapses all of this into one primitive. Everything your wallet, the code that processes transfers, the network's current timestamp is a row in the same global table with the same four columns.

The Schema

CREATE TABLE accounts (
  address    VARCHAR PRIMARY KEY,
  lamports   BIGINT,        -- SOL balance
  owner      VARCHAR,       -- which program controls this row
  data       BYTEA,         -- arbitrary payload
  executable BOOLEAN        -- is this row code or data?
);

That's it. Every account on Solana billions of them fits this schema. What varies is the values.

Row Type 1: Your Wallet

address: YOUR_WALLET_ADDRESS
lamports: 1,247,000,000 (1.247 SOL)
owner: 11111111111111111111111111111111 (System Program)
data: empty
executable: false

Your wallet is the simplest possible row. No data payload, not executable, owned by the system program. The SOL balance is all that matters, and it lives in lamports.

Web2 equivalent: A user record with just a balance field. No special logic is attached. The application server (system program) handles all operations on it.

Row Type 2: The System Program

address: 11111111111111111111111111111111
lamports: 1,000,000,000 (1 SOL)
owner: NativeLoader
data: 14 bytes
executable: true

Same schema, completely different purpose. executable: true means the runtime treats the data field as code to execute, not state to store. When you call the System Program, the runtime looks up this row and runs its bytecode.

Web2 equivalent: A stored procedure in your database. It lives in the same storage system as your data rows, but the database engine knows to execute it rather than return it as data.

Row Type 3: Sysvar Accounts

address: SysvarC1ock11111111111111111111111111111111
lamports: 1,169,280
owner: Sysvar1111111111111111111111111111111111111
data: 40 bytes (current slot, epoch, timestamp)
executable: false

Sysvar accounts are read-only rows that the network itself writes to every slot. Programs read them to access runtime information: what slot is it? What's the current rent rate? What are the recent block hashes?

Web2 equivalent: A system configuration table that your application server updates automatically like a system_config table with current_time, maintenance_mode, and version columns. Your application code reads it but doesn't write it.

The Flag That Changes Everything

The entire distinction between "code" and "data" in Solana comes down to one boolean: executable.

In Web2, code and data are fundamentally different things stored in different places one on your filesystem, one in your database. You never confuse them. In Solana, they're the same thing stored the same way. The flag is the only boundary.

This has a profound implication: programs are inspectable the same way data is. You can look up any program's account in a block explorer, see its bytecode, check its upgrade authority, read its transaction history. There's no separation between "application layer" and "data layer" it's all one public table.

What Sat Underneath Everything I Built

Looking back at 25 days of challenges through this lens:

Every airdrop I received → System Program created or credited my wallet row.
Every SOL transfer I sent → System Program debited my row and credited the recipient's.
Every account I created for a new keypair → System Program inserted a new row.
Every script that read account data → fetched rows from this global table.

The System Program has been the invisible application server behind every operation. Day 25 was the first time I looked at it directly as an account and saw that it's just another row, with executable: true and the NativeLoader as its owner.

Same table. Same schema. Different flags.

Sysvar Accounts: Solana's Live System Data, Explained for Developers

Samuel Akoji — Wed, 20 May 2026 12:01:58 +0000

The Accounts Nobody Talks About

If you ask a Solana developer what accounts are, they'll tell you about wallets and programs. If you ask them about sysvar accounts, there's a good chance they pause.

Sysvars are the third category of accounts on Solana and one of the most useful once you're building programs that need to know anything about the current state of the network. This post explains what they are, how they work, and why they exist as accounts rather than as function calls.

What Is a Sysvar?

A sysvar is a special on-chain account that the Solana runtime maintains automatically. Every slot, the network updates these accounts with current chain data: the current time, recent blockhashes, the rent rate, stake history, and more.

Programs can read sysvar accounts as inputs to their instructions. Instead of having a get_current_time() syscall, Solana gives you a Clock account. Instead of a get_rent_rate() function, there's a Rent account.

The design choice is intentional: by making system data available as accounts, programs access it the same way they access any other on-chain data by having the account passed as an input to the instruction.

The Core Sysvar Accounts

Clock SysvarC1ock11111111111111111111111111111111

Contains the current network time:

slot the current slot number (~400ms per slot)
epoch the current epoch (~2–3 days per epoch)
unix_timestamp unix timestamp, updated approximately once per slot
epoch_start_timestamp when the current epoch began
leader_schedule_epoch used for validator leader scheduling

Programs use Clock when they need time-based logic: vesting schedules, time-locked accounts, auction deadlines. It's the on-chain equivalent of Date.now().

Rent SysvarRent111111111111111111111111111111111

Contains the current rent parameters:

lamports_per_byte_year the base rent rate
exemption_threshold how many years of rent an account needs to hold to be rent-exempt
burn_percent what percentage of collected rent is burned

Programs use Rent when creating new accounts they need to calculate the rent-exempt minimum to fund the account correctly. Without reading Rent, a program would have to hardcode the exemption amount, which can change via governance.

RecentBlockhashes SysvarRecentB1ockHashes11111111111111111111

Contains the ~150 most recent block hashes. Transactions must include a recent blockhash as a validity window transactions referencing a blockhash older than ~150 slots are rejected as expired.

This is the mechanism that prevents transaction replay attacks: you can't rebroadcast an old signed transaction because its blockhash will eventually expire.

EpochSchedule SysvarEpochSchedu1e111111111111111111111111

Contains the parameters that define epoch length and how slot counts ramp up during the warmup period. Programs that need to reason about epoch boundaries can use this.

StakeHistory SysvarStakeHistory11111111111111111111111111

A record of total stake activating and deactivating per epoch. Used by the staking program to calculate how quickly stake delegations activate.

Instructions Sysvar1nstructions1111111111111111111111111

A special sysvar that contains the serialized instructions of the current transaction. Programs use this to inspect other instructions in the same transaction, useful for enforcing that certain instructions appear together.

How to Inspect Sysvars

You can read any sysvar account directly from the CLI:

# Clock
solana account SysvarC1ock11111111111111111111111111111111 --url devnet

# Rent  
solana account SysvarRent111111111111111111111111111111111 --url devnet

# Recent blockhashes
solana account SysvarRecentB1ockHashes11111111111111111111 --url devnet

The raw output is binary-encoded data. To see decoded values, use a JSON RPC call:

curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getAccountInfo",
  "params": [
    "SysvarC1ock11111111111111111111111111111111",
    {"encoding": "jsonParsed"}
  ]
}'

The jsonParsed encoding tells the RPC to decode the known sysvar format into readable fields.

Why Accounts Instead of Syscalls?

Other blockchains implement system data differently. Ethereum has block.timestamp and block.number as built-in variables accessible inside smart contract code no account required.

Solana's account-based approach has a specific advantage: it fits the transaction model. Solana transactions must declare every account they'll read upfront. By making sysvars accounts, a program that reads the clock must include the Clock sysvar in its account inputs making it statically visible which system data each instruction accesses before execution.

This supports Solana's parallel execution model. The scheduler can see exactly which accounts (including sysvars) a transaction will read, and run non-conflicting transactions simultaneously.

Sysvar Addresses Never Change

One useful property: sysvar addresses are fixed constants, known at compile time. The Clock sysvar has always been SysvarC1ock11111111111111111111111111111111 and always will be. Programs hardcode these addresses as known constants rather than looking them up dynamically.

In the Solana SDK:

use solana_program::sysvar::clock::ID as CLOCK_SYSVAR;
// CLOCK_SYSVAR == SysvarC1ock11111111111111111111111111111111

The Full Picture

Sysvar accounts complete the "everything is an account" model:

Wallet accounts user-owned data, managed by the System Program
Program accounts executable bytecode, managed by the BPF Loader
Data accounts program-owned state, managed by user programs
Sysvar accounts network-owned runtime data, managed by the Solana runtime itself

Four types. One storage model. Every category fits the same four-field account structure just with different owners, executability flags, and data payloads.

Sysvars are the part of that model that gives programs a window into the live state of the network they're running on.

Creating a Solana Token Is Like Building a Rewards System Except You Don't Write the Backend

Samuel Akoji — Tue, 19 May 2026 15:00:00 +0000

Every App Has a Credits System

Loyalty points. In-game currency. Reward tokens. Internal credits. If you've built any kind of consumer Web2 app, you've probably built some version of this: users accumulate a balance of something, they can spend it, and your database is the authoritative ledger.

Day 29 of 100 Days of Solana is about building the exact same thing except on Solana, you don't write the backend. It already exists. You just configure it and plug in.

Let me show you how the concepts map.

The Web2 Version

In a typical Web2 rewards system, you'd have something like:

-- The currency definition
CREATE TABLE token_types (
  id UUID PRIMARY KEY,
  name VARCHAR,
  symbol VARCHAR,
  decimals INT,
  total_supply BIGINT,
  issuer_id UUID REFERENCES users(id)
);

-- User balances
CREATE TABLE token_accounts (
  id UUID PRIMARY KEY,
  token_type_id UUID REFERENCES token_types(id),
  user_id UUID REFERENCES users(id),
  balance BIGINT
);

Your application server handles all the logic: validating that the issuer is authorized to mint, checking that balances don't go negative on transfers, enforcing the rules you define.

The Solana Version

On Solana, the same structure exists but it's all on-chain:

token_types → Token Mint Account

The mint account is your token definition. It stores:

Total supply
Decimal places
Mint authority (who can create more tokens)
Freeze authority (who can freeze accounts)

Create it with one CLI command:

spl-token create-token
# Returns: your mint address (the "id" of your token type)

token_accounts → Token Account

Each user's balance lives in a separate token account one per token type per wallet. It stores:

Which mint it belongs to
Which wallet owns it
The current balance

spl-token create-account <MINT_ADDRESS>
# Returns: your token account address

Your application server → The SPL Token Program

This is the key shift. In Web2, you write the business logic. On Solana, the Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) is a shared, audited, already-deployed program that handles all of it:

Only the mint authority can mint new tokens ✓
Balances can't go negative ✓
Only the account owner can transfer tokens ✓
Frozen accounts can't be transferred ✓

You don't write any of this. You invoke the Token Program's instructions, and it enforces the rules.

Minting Is Just a Database Insert

In Web2:

await db.query(
  'UPDATE token_accounts SET balance = balance + $1 WHERE id = $2',
  [100, tokenAccountId]
);
await db.query(
  'UPDATE token_types SET total_supply = total_supply + $1 WHERE id = $2',
  [100, tokenTypeId]
);

On Solana:

spl-token mint <MINT_ADDRESS> 100

One command. The Token Program handles both the balance update and the supply update atomically just like your database transaction would.

The difference: your Web2 database trusts your application server. Solana's on-chain accounts trust the Token Program. And the Token Program checks that whoever sent this transaction is actually the mint authority before allowing it.

The Separation That Changes Everything

The biggest mental shift from Web2 to Solana tokens is the separation between the token definition and the token balance.

In Web2, you might store both in the same table, or at least in the same database under the same access control. A user's "account" and their "balance" are tightly coupled.

On Solana, they're always separate:

The mint defines the token (one account, exists once)
Token accounts hold balances (one per wallet per token type)

This means:

The mint's rules can change (if you update the authority) without touching any user balances
User balances are visible to anyone the blockchain is public
Closing an empty token account returns the rent deposit to the user (about 0.002 SOL)

Why This Model Wins for Public Digital Assets

In Web2, your credits system is only as trustworthy as you are. Users have to trust that you won't manipulate the database, arbitrarily inflate supply, or freeze their accounts without notice.

On Solana, the rules are enforced by code that anyone can read and verify. If you renounce your mint authority (set it to null), no new tokens can ever be created and this is verifiable by anyone looking at the mint account in a block explorer. The supply is permanently capped by cryptographic enforcement, not by your promise.

For internal company credits, this might not matter. For a public token that real users hold real value in, it matters enormously.

What You Build in One CLI Session

# Create the token definition
spl-token create-token
# → returns MINT_ADDRESS

# Create your balance account  
spl-token create-account MINT_ADDRESS
# → returns TOKEN_ACCOUNT_ADDRESS

# Mint 100 tokens to yourself
spl-token mint MINT_ADDRESS 100

# Verify
spl-token balance MINT_ADDRESS
# → 100

Four commands. You now have a functioning token on a live blockchain. No smart contract written, no backend deployed, no database configured.

The infrastructure was already there. You just used it.

How to Create Your First Token on Solana Devnet (SPL Token CLI Walkthrough)

Samuel Akoji — Tue, 19 May 2026 13:39:05 +0000

Welcome to Epoch 2

If you've been following 100 Days of Solana, you've spent the first 28 days learning how Solana stores and reads data wallets, accounts, transactions, and explorers. Epoch 2 shifts gears from reading to creating. And it starts with the most fundamental creative act on Solana: making a token.

This is a complete walkthrough of Day 29's challenge: create a token on devnet using the SPL Token CLI, mint 100 units, and understand what you actually built.

Prerequisites

Make sure you have the Solana CLI installed and configured for devnet:

solana config set --url devnet
solana airdrop 2

Then install the SPL Token CLI:

cargo install spl-token-cli

Verify it's working:

spl-token --version

Step 1: Create a Token Mint

A token mint is the on-chain account that defines your token its total supply, how many decimal places it has, and who has authority to create more. Think of it as the "factory" for your token, not the token balance itself.

spl-token create-token

Output:
Creating token 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU
Address: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU
Decimals: 9
Signature: 5wTgYNMBRULKGSfRQkFsgSbxwFAq3QQtHbdxiR3LYLU5t3sGRD4ETFZHDvFBRTHxgfEjS5c1s6GfmFE8bqjyJwH

Save that token address you'll need it for every subsequent step. The address is the mint account's public key on-chain. Anyone who knows this address can look it up in Explorer and see everything about your token: total supply, decimals, mint authority.

What just happened: The SPL Token CLI sent a transaction that created a new account on devnet, owned by the Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA). That account is your mint. It currently has 0 supply and you are the mint authority.

Step 2: Create a Token Account

Here's where Solana's design becomes visible: your wallet doesn't hold tokens directly. You need a separate token account an account owned by the Token Program that holds your balance of a specific token.

spl-token create-account 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU

Output:

Creating account 8uFLaHUJnqFhDxdKWV3TvMSRbsF3Y6gUpUMfzM9JqwbA
Signature: 4QhmnBkNKoK8JXpSv9NXhLJzuRSN9fGPgZ3JpKvwWMTe...

This new address (8uFLaHUJ...) is your token account the account that will hold your balance of your new token. It's a separate account from your wallet, owned by the Token Program, and linked to both your mint and your wallet address.

Cost note: Creating a token account requires a rent-exempt deposit of approximately 0.00203928 SOL. This SOL is returned to you if you ever close the account. This is why receiving a new token sometimes costs a small amount the token account deposit.

Step 3: Mint Some Supply

Now you can actually create tokens. Since you're the mint authority, you control how many tokens come into existence:

spl-token mint 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU 100

Output:
Minting 100 tokens
Token: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU
Recipient: 8uFLaHUJnqFhDxdKWV3TvMSRbsF3Y6gUpUMfzM9JqwbA
Signature: 2XkR7...

100 tokens now exist. They live in your token account. The mint's total supply is now 100.

Step 4: Inspect What You Built

Check your balance:

spl-token balance 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU

Output: 100

Check the mint's supply:

spl-token supply 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU

Output: 100

List all your token accounts:

spl-token accounts

You'll see a table showing your token mint address, your token account address, and your balance.

Step 5: Verify in Explorer

Paste your mint address into explorer.solana.com (switch to devnet). You'll see:

Token Supply: 100
Decimals: 9
Mint Authority: your wallet address
Freeze Authority: None (you didn't set one)

Now paste your token account address. You'll see:

Mint: your token mint address
Owner: your wallet address
Token Balance: 100

Two separate accounts, both visible on-chain, both part of the same token system.

What You Actually Built

In Web2 terms, you just built a custom credits system:

The mint = your database schema + business rules ("this currency has 9 decimal places, only I can create more")
The token account = a row in your ledger ("this user holds 100 credits")
The Token Program = the application server that enforces all the rules

The difference from Web2: you didn't build any of the application server. The Token Program already exists on Solana and handles all the logic. You just created the data accounts and invoked its instructions.

This is the core insight of Epoch 2: Solana's shared programs let you launch digital assets without writing any program code yourself. The infrastructure already exists. You're using it.

What's Next in Epoch 2

Now that you have a token, Epoch 2 will cover:

Adding metadata (name, symbol, image) so your token appears properly in wallets
Transfer rules and fees
Freeze authorities
Eventually: NFTs, which are just tokens with supply of 1 and 0 decimals

The foundation you built today mint + token account + SPL Token Program is the same foundation that every token on Solana is built on, from small devnet experiments to billion-dollar DeFi protocols.

How to Read a Solana Transaction in Explorer: A Developer's Field Guide

Samuel Akoji — Mon, 18 May 2026 15:00:00 +0000

The Transaction Is the Unit of Work

Everything that happens on Solana happens inside a transaction. Account balances change, tokens move, programs execute all of it is packaged into transactions, confirmed by validators, and recorded permanently on-chain.

Solana Explorer makes every transaction readable. But if you're new to Solana, the transaction detail page has a lot of information and it's not immediately obvious what to focus on.

This is a field guide to reading a Solana transaction in Explorer. By the end you'll know what every section means, what to look at first, and how to use transactions to debug your own programs.

Explorer used: explorer.solana.com

How to Find a Transaction

You need a transaction signature the long base58 string that every sendTransaction() call returns. If you've been doing 100 Days of Solana, you've logged hundreds of these to your console and probably never looked at them again.

Go back to any script you've run and grab a signature. Paste it into the Explorer search bar. You'll land on the transaction detail page.

Alternatively: search your wallet address, go to Transaction History, and click any entry.

Section 1: The Header

The first thing you see is the result banner green for success, red for failure. This is the single most important piece of information on the page.

Below that:

Signature The unique identifier for this transaction. This is what you'd share if you wanted someone else to look at the same transaction. Think of it like a receipt number.

Block The slot (Solana's equivalent of a block number) when this transaction was confirmed. Solana produces a new slot roughly every 400ms.

Timestamp When the slot was confirmed. The gap between when you submitted the transaction and this timestamp is your actual confirmation time.

Fee Almost always 5,000 lamports (0.000005 SOL) for standard transactions. This is the base fee. Transactions that consume more compute units may pay higher fees, but for most operations you'll see this flat amount.

Fee Payer The wallet that paid the fee. Usually the transaction signer, but can be a different account if you're building apps that sponsor fees for users.

Section 2: Account Inputs

This section lists every account the transaction touched, with flags showing how each was used.

Writable This account's data or balance was modified by the transaction. If you're transferring SOL, both the sender and recipient are writable.

Signer This account signed the transaction, authorizing it. The fee payer is always a signer. In most user transactions, your wallet is the only signer.

Program This account is a program that was invoked during the transaction. It's not modified by the transaction; it's the code that processed it.

Reading the account inputs list tells you: who authorized this transaction, what accounts were changed, and which programs handled the execution. This is the "cast of characters" for everything that follows.

What to look for: If a transaction failed and you're debugging, check that the accounts you expected to be writable are actually marked writable. A common mistake is forgetting to mark an account as writable when constructing the transaction the runtime will reject it.

Section 3: Instructions

Each instruction in a transaction maps to one program invocation. A simple SOL transfer has one instruction. A DEX swap might have five.

For each instruction you'll see:

Which program handled it
The accounts passed to that instruction
The raw instruction data (usually encoded, but Explorer decodes it for standard programs)

For the System Program's transfer instruction, Explorer shows you the decoded fields: from, to, and lamports. For custom programs without a known IDL, you'll see raw bytes.

What to look for: If a transaction involves multiple instructions and one failed, the instruction breakdown shows you which one. The error will trace back to a specific program invocation, which narrows down where the problem is.

Section 4: Log Messages

This is the most useful section for developers. Every msg!() call from every program invoked in the transaction appears here, in execution order.

A successful simple transfer:

Program 11111111111111111111111111111111 invoke [1]
Program 11111111111111111111111111111111 success

A failed transaction with a custom program:

Program YourProgram1111111111111111111111111111111 invoke [1]
Program log: Checking account ownership
Program log: Error: account not owned by this program
Program YourProgram1111111111111111111111111111111 failed: custom program error: 0x0

The log messages tell you the story of execution. What was checked, what was found, where it went wrong. For any non-trivial program, this is your primary debugging tool.

What to look for: The error message at the end of a failed program invocation. Cross-reference it with the program's source code to find the msg!() or return Err() call that produced it.

Section 5: Token Balances (if applicable)

If the transaction involved SPL tokens, Explorer shows a before/after table for every token account that changed.

This is invaluable for verifying token transfers: you can see the exact amount that moved, from which account, to which account, and confirm it matches what your code intended.

Putting It Together: A Debugging Workflow

When one of your transactions fails:

Grab the signature from your console output
Open it in Explorer (switch to devnet if needed)
Check the result banner failure confirmed
Read the log messages section from top to bottom
Find the failed: line and the error message above it
Trace that error back to your program code
Check the account inputs are all writable accounts marked writable? Is the right wallet signing?
Fix, redeploy or re-run, and paste the new signature back into Explorer to verify

This workflow has saved me more debugging time than any other single practice in the challenge. Explorer isn't optional infrastructure it's a core part of the development loop.

I Used Solana Explorer Like Chrome DevTools. Here's What I Found

Samuel Akoji — Mon, 18 May 2026 11:00:00 +0000

DevTools for the Blockchain

Day 28 of 100 Days of Solana sent me to Solana Explorer with the same mindset: just look at the chain. No task, no script. Just explore.

Here's what I found when I treated Explorer like DevTools and what each discovery maps to in Web2 terms.

Explorer used: explorer.solana.com Devnet, then Mainnet

The Network Tab: My Transaction History

In DevTools, the Network tab is the first place I go when something isn't working. It shows every request, every response, every status code.

My wallet's transaction history in Explorer is exactly that every "request" my wallet has sent to the blockchain since Day 1 of the challenge. 27 transactions, laid out chronologically. Each one shows:

Which program was called (the "endpoint")
Whether it succeeded or failed (the "status code")
The fee paid (the "cost")
The net SOL change (the "response payload")

I found a failed transaction from Day 19 that I'd half-forgotten about. In the log messages, the error was clear:

Program log: Error: insufficient lamports for instruction

The equivalent of a 400 Bad Request except this one is permanently recorded on a public blockchain and I paid 5,000 lamports for the privilege of failing.

Web2 parallel: Failed API calls don't charge you. Failed Solana transactions do. The fee covers the computational work validators did to process the transaction, even if the result was rejection.

The Console: Log Messages

In Web2, console.log() is how you peek inside running code. In Solana programs, msg!() is the equivalent and those messages surface in Explorer under the Log Messages section of any transaction.

For my successful SOL transfer from Day 16:
Program 11111111111111111111111111111111 invoke [1]
Program 11111111111111111111111111111111 success

For a more complex interaction I found on mainnet:

Program log: Instruction: Swap
Program log: Swap: in_amount=1000000, out_amount=997234
Program log: Fee collected: 2,766 lamports
Program JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 success

The program logged its own business logic input amount, output amount, and fee. Developers chose to surface this information, and now it's permanently readable by anyone.

Web2 parallel: Imagine if every API call your app made logged its internal execution to a public server that anyone could read forever. That's exactly what on-chain program logs are. Design your logs accordingly.

The Application Tab: Account Data

In DevTools, the Application tab shows you what your app is storing localStorage, sessionStorage, cookies. It's the state layer.

On Solana, every account's data field is the equivalent. In Explorer, clicking any account shows you its stored bytes and for well-known programs, Explorer decodes them into readable fields.

I clicked on a token account in my wallet. Explorer decoded it to show:

Mint: the USDC devnet mint address
Owner: my wallet address
Amount: my token balance, in the token's smallest unit
State: Initialized

Four fields, decoded from a binary blob. The Token Program defined the schema; Explorer knows the schema because the Token Program is a standard.

Web2 parallel: It's like inspecting a localStorage entry and finding {"userId": "abc123", "balance": 1000000, "currency": "USDC"} except this entry lives on a blockchain instead of your browser, and the schema is defined by a deployed program instead of your frontend code.

The Elements Tab: The System Program

In DevTools, the Elements tab lets you inspect the DOM the structure of the page itself, not just the content.

The System Program is the structure of Solana itself. I searched for it in Explorer: 11111111111111111111111111111111.

What I saw was surprisingly minimal:

Balance: 1 SOL
Executable: Yes
Data: a small number of bytes
Transaction count: millions

This is the program that handles every SOL transfer, every account creation, every airdrop. It's been invoked hundreds of millions of times. It has a 1 SOL balance and almost no on-chain data because, as a native program, its code lives in the validator binary rather than in account data.

Web2 parallel: The System Program is like the Node.js runtime or the browser's fetch API the foundational layer that higher-level code builds on. You rarely think about it directly, but everything you do goes through it.

Going Live: Mainnet in Real Time

I switched to mainnet and watched the Explorer homepage for five minutes. Transactions coming in constantly. Some I recognized:

Simple SOL transfers: 2 accounts, System Program, 5000 lamport fee
Token transfers: 3-4 accounts, Token Program, 5000 lamport fee
DEX swaps: 10-14 accounts, 3-4 programs, 5000 lamport fee

Web2 parallel: It's like watching your server access logs in real time except it's a public server that processes millions of requests per second, every request is globally visible, and you can click into any one to see the full execution trace.

What This Changed for Me

I've been building on devnet for 28 days. Switching to mainnet Explorer and watching real transactions was a reminder that this infrastructure is live, processing billions in value daily, and every pattern I'm learning right now applies to that real environment.

Explorer made the chain feel real in a way that devnet never quite does. Devnet is practice. Mainnet is the game. Explorer shows you both.