The Challenge
Day 26 of 100 Days of Solana is open-ended: explore Solana Explorer, find something interesting, compare it to what you've been doing in the CLI. No starter code, no guided steps. Just go look at the blockchain.
I'll be honest I wasn't sure what "interesting" meant at first. I've been writing scripts for 25 days. I know how to fetch data. But sitting down and just exploring felt different. Here's what I found.
First Stop: My Own Wallet
I started with what I knew my own devnet wallet. Pasted the address into explorer.solana.com, switched to devnet, and there it was: every transaction from the last 26 days laid out in reverse chronological order.
The most recent ones are from Arc 3 the SOL transfers I sent when building the transfer tool. Clicking through them, I could see the exact lamport amounts, the fees (consistently 5000 lamports = 0.000005 SOL), and the System Program invocations.
What struck me: I've been reading this same data through scripts for weeks. Seeing it in Explorer felt like switching from reading a map's coordinates to looking at a satellite photo of the terrain. Same information, completely different feel.
The Transaction That Surprised Me
I found a failed transaction from Day 19, the day we worked on handling transaction failures. I had forgotten about it. The error in the log:
The transaction failed, but it's still there. Still cost 5000 lamports. I remember being confused by that when it happened why do you pay for a failed transaction? Explorer made the answer visual: the validators ran the transaction, confirmed it would fail, and recorded that confirmation. The work happened. The fee was for the work.
Going Deeper: The Token Program
I searched for the SPL Token Program: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
This is the program that powers every token on Solana USDC, USDT, every NFT, everything. Its account in Explorer shows:
- Executable: true
- Owner: BPF Loader (the program loader for on-chain programs)
- Data: the compiled BPF bytecode of the program itself
This was the moment Arc 4's account model lesson clicked for me. The program is an account. The code lives in the data field of that account. When you call the TokenProgram, you're passing a message to this account, which the runtime executes as code.
Mainnet for 10 Minutes
I switched to mainnet and just watched the homepage for a few minutes. Transactions streaming in constantly. I clicked a few at random:
- A Jupiter swap: 12 accounts, 3 programs, executed in one atomic transaction
- A simple SOL transfer between two wallets: clean, 2 accounts, system program only
- An NFT mint: token program, metadata program, and associated token account program all invoked in sequence
The complexity range was wild. A simple transfer and multi-protocol DeFi interactions both look like "one transaction" from the outside. Inside, they're completely different.
CLI vs Explorer: The Real Comparison
Here's the honest comparison after spending a day in Explorer:
CLI is better for:
- Scripting and automation
- Precise control over RPC calls
- Building tools that read data programmatically
- Piping output into other commands
Explorer is better for:
- Getting a quick visual overview
- Debugging failed transactions (the log view is excellent)
- Discovering programs and accounts you didn't know existed
- Building intuition for what on-chain activity looks like
They're not competing. I'll use both. The CLI is how I build. Explorer is how I verify and understand.
What's Next
Arc 4 is taking us into the account model in depth. After spending a day in Explorer seeing accounts everywhere wallets, programs, tokens, sysvars I feel like I actually understand what "everything is an account" means now. It's not a slogan. It's literally how the whole system is organized.
If you haven't spent time in Explorer yet, do it today. Don't follow a tutorial. Just start with your own wallet and follow the threads.
Top comments (0)