Forem: Samuel Akoji

I Built a Terminal Account Explorer (Mini Solscan)

Samuel Akoji — Thu, 14 May 2026 13:00:00 +0000

Day 23 of #100DaysOfSolana

Today I stopped staring at raw terminal output and built something actually useful: a CLI tool that takes any Solana address and prints a clean summary of the account balance, owner, data size, and whether it's executable.

Think of it as your own mini Solscan, no browser required.

What I built

A Node.js script (explorer.mjs) that:

Accepts any Solana address as a CLI argument
Fetches balance via getBalance and account metadata via getAccountInfo
Converts lamports to SOL (divide by 1,000,000,000)
Maps owner addresses to friendly names (System Program, Token Program, etc.)
Truncates large data fields so your terminal doesn't explode

Stack: @solana/kit, ES Modules, devnet RPC

The core insight

Every single account on Solana — wallets, token accounts, deployed programs — is described by the same 5 fields:

Field	What it tells you
`balance`	How much SOL (in lamports)
`owner`	Which program controls this account
`data`	Custom bytes stored in the account
`executable`	Is this account a runnable program?
`rent_epoch`	When rent was last collected

The difference between a wallet and a smart contract is literally one boolean: executable.

What surprised me

Block explorers like Solscan and SolanaFM aren't doing anything special. They call the same getBalance and getAccountInfo RPC methods I used today — they just wrap the output in a web UI.

Building the raw version yourself gives you a mental model that no tutorial skips to.

Try it yourself

node explorer.mjs TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Run it against the Token Program address. You'll see executable: true and the System Program listed as owner.

Then try your own devnet wallet — executable: false, zero data, System Program owner.

Day 23 down. Still shipping daily

solana #web3 #blockchain #100daysofcode #javascript

Inspecting Raw Account Data with the Solana CLI

Samuel Akoji — Thu, 14 May 2026 10:01:23 +0000

Day 22 of #100DaysOfSolana

Today I went under the hood. No code just the Solana CLI and three account inspections that changed how I see the whole network.

Inspection 1 — My own wallet

solana account $(solana address)

Output:

Balance: 2 SOL
Owner: 11111111111111111111111111111111
Executable: false
Length: 0 bytes

Owned by the System Program. Not executable. Zero bytes of custom data. Just a balance.

Inspection 2 — The SPL Token Program

solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Executable: true
Owner: BPFLoader2111111111111111111111111111111111
Data: [compiled program bytecode]

Same five fields — completely different values. This is a runnable program, loaded by the BPF Loader, with actual bytecode in the data field.

A native built-in program. The only one on Solana that can create new accounts. Compare its fields to both above and the pattern becomes clear.

The five fields every account shares

Field	What it means
`lamports`	SOL balance in the smallest unit
`data`	Arbitrary byte array (empty for wallets)
`owner`	The program that controls this account
`executable`	Is this account runnable code?
`rentEpoch`	Legacy field, no longer actively used

The key insight

On Solana, everything is an account. Wallets, programs, token balances, NFT metadata, game state — all accounts, all with the same five fields.

The difference between a wallet and a smart contract is:

One boolean: executable
One address: what sits in owner

This is different from Ethereum, where wallets and contracts are distinct concepts. On Solana, it's accounts all the way down.

The owner field is the security model

Only the owning program can modify an account's data or deduct its lamports. That's why:

The System Program handles SOL transfers → it owns wallets
The Token Program moves tokens → it owns token accounts
Your custom program controls its state → it will own the accounts it creates

Understanding this is foundational for everything that comes next.

Same fields, machine-readable. Useful for scripting or piping into other tools.

Day 22 down.

solana #web3 #blockchain #100daysofsolana

Solana Transactions Explained for Backend Developers

Samuel Akoji — Mon, 11 May 2026 08:01:59 +0000

I've sent hundreds of HTTP requests in my career. POST to an endpoint, get a 200 back, move on. When I started building on Solana, I assumed transactions would feel similar. They don't and understanding exactly why changed how I think about on-chain programming entirely.

The Web2 mental model (and where it breaks down)

In a typical backend system, you call an API: you send a payload, a server processes it, and you get a response. The server holds authority. Authentication is usually a session token that the server validates against its own database.

Solana transactions have a surface-level resemblance to this you send something to the network, it gets processed, you get a result. But three things make the comparison fall apart quickly:

1.The transaction itself is the authority: There's no session. There's no server checking a database. Authority comes from a cryptographic signature attached to the transaction computed with your private key, verifiable by anyone. If the signature is valid, the instruction runs. Period.

2.** Everything is atomic**: A transaction bundles one or more instructions, and they all succeed or all fail together. This isn't just a convenience it's a security guarantee baked into the runtime.

3.It expires: A transaction is only valid for roughly 60–90 seconds, anchored to something called a recent blockhash. No stale replays. No indefinitely reusable tokens.

The anatomy of a Solana transaction

Before writing any code, I found it useful to understand what a transaction is actually made of. There are four core pieces:

Signatures
Ed25519 signatures from every required signer. The fee payer always signs. Programs can require additional signers.

Recent blockhash
A hash of a recent block. Acts as a TTL transactions referencing an expired blockhash are rejected outright.
**
Instructions**
The actual work. Each instruction targets a program, specifies accounts, and passes instruction data.

Accounts
Every account the transaction will read or write declared upfront. Validators use this to parallelize execution.

If you're coming from backend development, the hardest part of Solana isn't the syntax it's unlearning the assumption that authority lives on a server. Once you internalize that signatures are the authority, the rest of the transaction anatomy follows naturally.

Day 20 of #100DaysOfSolana.
Devnet explorer is open in a permanent tab now.

I Made my First solana transfer

Samuel Akoji — Tue, 05 May 2026 13:53:32 +0000

Made my first SOL transfer on devnet today.
Not a big moment by most standards. 0.001 SOL, sent to a temporary wallet I spun up just to have somewhere to send it. But watching it actually land — seeing the balance update, the transaction confirm — made something click that reading docs never quite did.
A few things I had to get right before it worked:

Generate a fresh keypair and save it locally
Use --allow-unfunded-recipient because the destination account didn't exist yet
Make sure I was pointed at devnet and not somewhere else entirely

That last one would have cost me real money in a different context. Glad I learned it here.

Understanding transaction anatomy

Samuel Akoji — Tue, 05 May 2026 13:31:03 +0000

Today I stopped treating a Solana transaction as a black box and looked at what's actually inside one.
Every transaction is a signed message made up of four parts:

A header that defines permission groups for all accounts involved
A list of account keys the resources the transaction touches
A recent blockhash proof of freshness and protection against replay attacks
Instructions the actual operations, each pointing into the account keys array by index

Traditional Databases vs Solana Accounts

Samuel Akoji — Tue, 05 May 2026 12:45:47 +0000

Today on my learning journey i learnt about the difference between a solana account and the traditional database.

Key Difference
Accounts do not query each other.

There is no JOIN
No server-side filtering
Programs receive accounts as inputs to instructions
If you want to "query" data:

You do it off-chain via RPC
Then assemble the results yourself

My second Week Playing Around Solana

Samuel Akoji — Mon, 04 May 2026 11:54:19 +0000

I'll be honest before I started, I think I expected blockchain data to feel exotic. Like there'd be some kind of ceremony to accessing it. What I got instead was a JSON RPC endpoint. You call it, it talks back. That was the first surprise: how boring the infrastructure felt in the best possible way. It's just a database you can ask questions to. The "public ledger" framing stopped being an abstraction the moment I ran my first solana balance call and watched a real wallet's balance show in my terminal,or even request faucet and receiving it in my wallet in real time and the balance displayed on my terminal too.

What clicked fastest was the account model. Once it landed that everything on Solana is an account programs, token balances, even program state a lot of the weirdness started resolving itself. It's almost like a filesystem. Programs live at addresses. Data lives at addresses. You're mostly just reading from addresses. That felt intuitive once I stopped trying to map it onto how I thought blockchains were supposed to work.

What surprised me most about the SDK was how much the ecosystem leans on you knowing what you're looking for before you go looking. With a REST API, you usually get back something self-describing field names that hint at meaning, maybe some docs that walk you through a response shape. With Solana RPC, especially reading raw account data, you get back a base64-encoded blob and a polite shrug. You need the program's IDL to make sense of it. That's not a flaw exactly, it's just a different contract between the API and the developer one that assumes more context up front.

What's still fuzzy: the fee and priority fee model. I understand the mechanics loosely you attach a compute budget, you bid for inclusion but the intuition hasn't formed yet. One thing I did learn along the way: SOL isn't the smallest unit you're working with. That's lamports 1 SOL is made up of 1,000,000,000 lamports. So when amounts come back from the RPC, they're in lamports, and you have to divide by a billion to get back to SOL. It's a small thing but it catches you off guard the first time you see a balance and think someone is inexplicably wealthy. That's probably my next step.

You Already Understand Blockchain Identity (You Just Don't Know It Yet)

Samuel Akoji — Sun, 26 Apr 2026 16:32:59 +0000

If you've ever set up SSH access to a server, you already understand the core idea behind identity on Solana. You generated a keypair. You dropped the public key on the server. From that point on, you proved who you were not with a password but by signing challenges with your private key. The server trusted the math.
Solana works the same way, except instead of one server, the "server" is the entire global network, and your keypair is your identity everywhere on it at once.
The problem with Web2 identity
Think about how fragmented your identity actually is right now. You have a username on GitHub, an email address at work, a login at your bank, and an account on every SaaS tool your team uses. Each one is a separate record in someone else's database. Each one is granted to you by that company and can be revoked by them at any time. Forget a password? You depend on their reset flow. Get suspended? You're locked out entirely. Want to prove to a third party that you're the same person across two platforms? That's someone's API integration problem.
None of these identities are yours. They're access tokens that someone lends you.
A keypair is different
On Solana, your identity is a cryptographic keypair specifically, an Ed25519 keypair. That generates two things: a public key, which is your on-chain address and safe to share with anyone; and a private key, which you never share and which is the only proof of ownership the network recognizes.
Your public key looks like this: 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5
That's a 32-byte key encoded in Base58 a format chosen specifically to be human-readable. Base58 strips out visually ambiguous characters like 0 vs O and I vs l, so addresses can be read, copied, and verified without confusion. It's not a username someone assigned you. It's derived mathematically from your private key, and it exists independently of any company's database.
There is no account to create. There is no service to register with. You generate the keypair, and you have an identity.
What "ownership" actually means
In Web2, "owning" your account means a company stored your credentials and decided to give you access. They can change that decision. On Solana, ownership means something more precise: only the holder of the private key can produce a valid signature for that address. Every transaction on the network is cryptographically signed. The network checks the math. If the signature is valid, the transaction goes through. There is no admin panel, no customer support escalation, no override.
This is the tradeoff worth understanding clearly: you gain total control, and you take on total responsibility. Lose your private key or seed phrase and there is no recovery path. No one can help you. That's not a bug it's the same property that makes the ownership real.
Identity as infrastructure
Here's where it gets interesting for developers. In Web2, identity is mostly about authentication proving you're you so you can log in. On Solana, identity is the foundation for everything else.
Because your keypair is universal across the network, it's the same identity you use to hold tokens, interact with programs, participate in governance votes, and build up on-chain reputation. When you connect your wallet to a Solana app, you're not creating a new account with that app. You're presenting the same cryptographic identity you use everywhere else, and the app reads what's already associated with it on-chain.
No integrations needed. No OAuth handshakes. No, sign up with GitHub. Your identity is already there, and anyone building on the network can read it.
The mental shift
The shift from Web2 to on-chain identity is less about learning new technology and more about internalizing a different ownership model. You're used to identity being something a service grants you and can take away. On Solana, identity is something you generate, and it belongs to whoever controls the key.
That's unsettling; at first there's no help desk. But it's also the thing that makes every application on the network composable by default. Your address is the same everywhere. Your assets follow you. No one can revoke access.
It starts with a keypair. Everything else is built on top of that.

100daysofsolana #solana #web3 #blockchain and #beginners