DEV Community: Favour Chisom I.

What Solana Explorer Taught Me That My Code Couldn't

Favour Chisom I. — Tue, 19 May 2026 22:46:38 +0000

Four weeks into #100DaysOfSolana, I finally stopped treating Solana Explorer as "just a checker" and started using it as a learning tool. Here is what changed.

The Moment It Clicked

I had been writing scripts for days, fetching balances, decoding mint accounts byte by byte, inspecting sysvars from the CLI. I thought I understood the account model. Then I pasted one of my own devnet transaction signatures into Solana Explorer and saw everything I had been doing in code laid out visually.
The instruction logs showed exactly which programs were invoked. The accounts panel listed every account touched, including ones I had not explicitly referenced in my code. The fee was right there: 5,000 lamports. Finalized in under a second.
Reading it felt like opening DevTools and finally seeing the network tab. That feeling of "oh, so THAT is what my code was actually doing" hit me all at once.

Three Things I Noticed

1. Programs are just accounts too.
When I searched the Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA), Explorer showed it like any other account, with an owner, a balance, and a data field. The only difference was Executable: true. That one boolean is what separates a wallet from a smart contract on Solana. Reading it in docs is one thing. Seeing it sitting right there in the UI next to your own wallet is something else entirely.

2. Everything is public and that is the point.
On mainnet I searched the Token 2022 program and watched live transactions roll in. Swaps, mints, transfers, all visible, all readable, no login required. In Web2 you would need database access to see any of this. Here transparency is just the default. That shift still surprises me every time I think about it.

3. The explorer is your debugger.
When a transaction fails on Solana, the instruction logs tell you exactly which instruction failed and why. I had a failed transfer sitting in my devnet history and expanding the logs showed the exact error: insufficient lamports. The same information was in my terminal but the Explorer made it so much easier to see which account caused the problem and trace what went wrong step by step.

Which Explorer?

I have been using Solana Explorer (the official one) for most of my devnet work. It is clean, handles devnet and mainnet switching easily, and the raw transaction view is great when you are still learning how everything fits together. Solscan feels better for mainnet work because labeled accounts and token flows are easier to follow there.
If you are early in your Solana journey, bookmark Explorer and open it every single time you send a transaction. Do not just check if it succeeded. Expand everything. Click into the accounts. Read the logs. It will teach you more than staring at docs ever will.

100daysofsolana #solana #web3 #blockchain

From Zero to Transfer: Showing Off My First Solana CLI Tool

Favour Chisom I. — Mon, 11 May 2026 10:19:55 +0000

I built a small command line tool that sends SOL on devnet. I run it with a recipient address and an amount, and it loads my wallet, checks my balance, signs a transaction, and prints an Explorer link. If I try to send more than I have, it catches me before I waste any lamports. The screenshot below is a tiny SOL transfer I did today just to test it.

Before building this I didn't really understand what a blockhash was. I learned that every transaction needs a recent one that expires in about a minute, so my tool grabs a fresh one each time. The first few times I ran it I made silly mistakes with the arguments or tried to send way more than I owned, but every error taught me something. Opening the Explorer link and seeing the transfer marked FINALIZED felt like a real milestone.

What I Finally Understand About Solana Transactions (After 20 Days of Learning)

Favour Chisom I. — Sun, 10 May 2026 14:12:48 +0000

When I started #100DaysOfSolana, I didn’t even know what a keypair was. On Day 1 I ran a script, got a random address, and thought “this is my wallet?” It felt too bare. No password, no email, just a string. Then I learned that sending SOL means creating a transaction, and that’s where things got real.

A Solana transaction isn’t like a normal API call. In Web2 you hit an endpoint, the server does stuff, and maybe you get a 200 OK. Here, a transaction is a signed bundle of instructions that changes state on a public ledger that thousands of computers agree on. Every transaction needs a recent blockhash (like a freshness stamp that expires in about a minute), a list of all the accounts it will touch, and at least one signature from the person who pays the fee. If any instruction fails, the whole thing rolls back. Atomic, just like a database transaction, except everyone can see it, and you pay a tiny fee even if it fails.

The first time I sent SOL from my terminal, I was nervous. I double checked the address, ran the command, and waited. It felt like hitting “send” on a bank transfer, but there’s no bank. The confirmation came back in under a second, and I could immediately look it up on Solana Explorer. Seeing my little 0.001 SOL transfer sitting on chain, with a block time and a fee, made the whole “public ledger” idea click.

Over the next few days I broke things on purpose. I tried sending more than my balance (the CLI yelled at me), sent to a brand new address without the right flag (rejected), and inspected raw transaction data with solana confirm -v SIGNATURE. That’s when I noticed the 1,232 byte size limit baked into every transaction. Coming from a world of unlimited JSON payloads, that was a shock. Now I understand why complex apps need stuff like Address Lookup Tables.

The biggest jump was building my own little transfer tool with Node.js. Instead of typing solana transfer every time, I wrote a script that loads my keypair, checks my balance, asks for confirmation, and prints a clickable Explorer link. Later I added progress tracking so I can see the status move from “processed” to “confirmed” to “finalized.” That felt like I’d turned a black box into something I actually understood.

If you’re just starting out, my advice is to send lots of tiny transfers on devnet. Break things. Read the error messages. Use the Explorer like a detective. The transaction model starts to feel natural quicker than you think, and then you realise you’ve grown from copying code to actually knowing what your code is asking the network to do.

My First SOL Transfer: No Middleman, No Waiting

Favour Chisom I. — Sun, 10 May 2026 07:23:17 +0000

I sent my first SOL transfer on devnet today and it felt oddly magical. I created a fresh wallet, typed one command, and half a SOL zipped across the network almost instantly. Watching the transaction appear on Solana Explorer made me feel like I'd just unlocked a new cheat code. No middleman, no waiting, just signed and done. #100DaysOfSolana

Two weeks of Solana: What Actually Surprised Me (and What Still Feels Weird)

Favour Chisom I. — Sat, 02 May 2026 11:16:44 +0000

I started two weeks ago not really understanding what a wallet even was. The first thing I did was generate a keypair and it just looked like a long random address. I didn't even know you could lose access if you lost the file. That felt scary and also kind of cool. Then I learned about lamports and how everything on Solana is actually in those tiny units, not SOL. I kept mixing them up but multiplying and dividing by a billion slowly started to make sense.

The best part was in Day 010 when I I built a simple web page that showed my wallet balance from devnet. It felt amazing to see my own address and some transactions right there in a browser. I still don't fully understand some things, like how same address can be queried on both devnet and mainnet, but I'm okay with that and working on figuring it out. Two weeks ago I had no idea what Solana was, and now I can write small scripts and read data from the chain. That feels like progress.

My Brain on Databases vs. Solana: A Beginner’s Reality Check

Favour Chisom I. — Thu, 30 Apr 2026 23:38:52 +0000

Day 11 of #100DaysOfSolana flipped my database instincts upside down. I spent years thinking in tables, rows, and SQL queries but Solana’s account model is a completely different beast. Every single piece of state, whether a user’s wallet or executable program code, lives as a publicly readable account on a global ledger. There are no joins, no server-side filtering, and no admin overrides. Access control is baked into the runtime: only the owning program can modify an account’s data, and only with the right signatures. Storage isn’t a monthly cloud bill; it’s an upfront, refundable deposit in lamports per byte. The biggest shock? Transparency is the default, anyone can read your account data, no login required. This exercise built a mental bridge I know I’ll cross again and again as I dive deeper into Solana development.

On Solana, Your Wallet Is Your Identity: What I Learned in My First Week (from a Complete Beginner)

Favour Chisom I. — Mon, 27 Apr 2026 18:34:36 +0000

I have spent the last week diving into Solana development, and I want to share what each day felt like as a complete beginner. Because honestly, nothing clicked until I did it myself.

Day 1: My First Keypair

I created a new project folder and installed @solana/kit. Then I wrote a tiny script that called generateKeyPairSigner() and printed the wallet address. When I ran it, a long string of letters and numbers appeared. That string, I learned, was my public key like an account number I could safely share. The private key stayed hidden inside the wallet object, never printed. It felt strange not seeing it. I copied the address, opened faucet.solana.com, selected Devnet, and requested an airdrop. I actually encountered an error because I didn't connect my github account to it. A few seconds after connecting my github, free test SOL landed at my address. I updated the script to check the balance and saw 2.5 SOL in the terminal. I also realized that running the script again gave me a completely new wallet each time. It was like printing a new bank account slip and throwing it away.

Day 2: Making the Wallet Stick

The goal was to create a wallet, save it to a file, and load it later. I wrote a function that first tried to read a wallet.json file. If the file existed, it would reconstruct the keypair from its bytes. If not, it would generate a new one, save it, and carry on. My first attempt failed with an error:

"key is not extractable."
The generateKeyPairSigner() function creates keys that can't be exported for security. That stumped me. After digging, I switched to using createKeyPairSignerFromPrivateKeyBytes() and generated my own 32 random bytes using Node's crypto.randomBytes(32). I saved those bytes (just the private key) into a JSON file as an array of numbers. When I ran the script again, it loaded the same address and showed the balance I’d funded earlier. For the first time, I had a wallet I could reuse.

Day 3: SOL and Lamports, the Smallest Unit

I installed the Solana CLI and generated a fresh keypair (solana-keygen new). Then I used solana balance --url devnet to see my balance in SOL, and --lamports to see it in lamports. The conversion: 1 SOL = 1,000,000,000 lamports. Integers only, no decimals. This explained why earlier my script showed 2000000000 when I expected 2. It’s like working with cents in payment APIs. I also checked a transaction fee 5000 lamports, or 0.000005 SOL by inspecting the transaction history. I finally understood why blockchain code never uses float numbers. Everything is exact.

Day 4: Connecting a Real Browser Wallet

This was the big leap: building a web app that talks to a browser extension. I created a Vite project, installed @solana/kit and @wallet-standard/app. The JavaScript detected installed wallets (like Phantom) using getWallets(), filtered for Solana chains, and showed buttons for each. Clicking one triggered connect(), which opened a popup asking permission. Once I approved, the page displayed my address and devnet balance fetched via RPC. I didn’t touch a private key at all the wallet handled it. Seeing it work in the browser felt like building something real. The Wallet Standard meant my app would work with any compliant wallet, not just Phantom. That’s elegant.

Day 5: Comparing Wallet Types

I stepped back to compare the three wallets I now had: the CLI wallet (plaintext JSON file), the browser extension (password-encrypted, with seed phrase), and a mobile wallet I installed fresh. Each generated a keypair, but the experience differed. The CLI was lightning-fast for scripting. The browser wallet added a confirmation layer every signature required a popup. The mobile wallet used biometrics and felt the most secure day-to-day. I sent 0.01 SOL from my phone to my CLI address and verified it arrived. All of them held the same kind of keypair, but security and convenience varied wildly. That’s when it hit me: identity on Solana is a private key, and wallets are just different containers for it.

What It All Means

After five days, the concept clicked. On Solana, you don’t have a username or email; you have a keypair. Your address is your public key, and you prove ownership by signing with your private key. No company can revoke that, reset a password, or lock you out. It’s like SSH keys for the entire internet. That’s both empowering and terrifying because if you lose the key, nobody can help you. But it also means you truly own your identity, assets, and interactions across every app on the network. That shift in mindset is the biggest lesson I’ve taken away.

I’m still getting used to double-checking backups, but I can’t unsee it now: my wallet is my identity on Solana. And that’s a good thing.