The Moment the CLI Became Visual
For the first 25 days of 100 Days of Solana, I read the blockchain through scripts and terminal output. JSON blobs, Lamport values, and base58 addresses. I understood the data, but I was reading it the way you read a spreadsheet: accurately, but without texture.
Day 26 changed that. I opened Solana Explorer and looked at the same data I'd been working with for weeks. This post is a walkthrough of exactly what I found and what it taught me that the CLI hadn't.
Explorer used: explorer.solana.com switched to Devnet
Stop 1: My Own Devnet Wallet
The first thing I searched was my own wallet address, the key pair I generated on Day 1.
What I saw on screen:
The balance was displayed prominently at the top: a SOL amount, with the lamport equivalent shown in smaller text underneath. Below that, two tabs: Tokens and Transaction History.
I clicked on Transaction History. There were 27 entries one for almost every day of the challenge. The oldest was an airdrop from Day 1. The most recent was the account inspection script I'd run the night before.
What I noticed: The transaction list shows the net SOL change per transaction with a +/- indicator. My airdrop showed +2 SOL. My transfers showed small negative amounts the sum of what I sent plus the 0.000005 SOL fee per transaction. Seeing the fees accumulate across 27 transactions made the economics of on-chain activity tangible in a way that reading individual fee fields never had.
Stop 2: Clicking Into a Transaction
I picked a transaction from Day 16 the first time I successfully sent SOL programmatically.
The transaction detail page showed:
- Signature: a long base58 string the unique ID I'd been logging to console and immediately forgetting
- Result: Success (in green)
- Timestamp: the exact second the transaction was finalized
- Fee: 5,000 lamports
- Block: the slot number when this was confirmed
Scrolling down to Account Inputs, I could see two rows: my wallet (marked as Fee Payer, Writable, Signer) and the recipient wallet (marked as Writable). The system program was listed as the program invoked.
What I noticed: The "Writable" flag next to accounts. I'd read about this in the documentation: Solana transactions must declare upfront which accounts they'll write to, enabling parallel execution. Seeing it displayed per-account in Explorer made it concrete. My wallet is writable because its balance decreases. The recipient is writable because its balance increases. The system program itself is not writable it's just the code being executed.
Stop 3: The Log Messages Section
This was the most useful discovery of the day.
At the bottom of the same transaction, there's a Log Messages section. For my simple SOL transfer, it showed the following:
Program 11111111111111111111111111111111 invoke [1]
Program 11111111111111111111111111111111 success
Two lines. The System Program was invoked, it succeeded, done.
I then found a more complex transaction one where I'd called a script that failed. The logs told the full story:
Program log: Instruction: Transfer
Program log: Error: insufficient lamports
Program 11111111111111111111111111111111 failed: custom program error: 0x1
What I noticed: The log messages are the console.log() of on-chain execution. Every msg!() call in a Solana program surfaces here. For debugging failed transactions, this is the first place to look not your local terminal, not your script output. The on-chain log is the ground truth.
Stop 4: The System Program Account
I searched for 11111111111111111111111111111111 the System Program.
What I saw:
- Balance: 1 SOL (the rent-exempt minimum)
- Executable: Yes
- Owner: Native Loader
- Data: A small amount of bytes not the program code itself (native programs live in the validator), just enough metadata
What I noticed: The System Program's transaction count in its history is enormous — millions of transactions. Every SOL transfer, every account creation, every airdrop flows through this account. It's the most-used program on Solana by a significant margin, and it sits there quietly with a 1 SOL balance and almost no visible data.
Seeing it as just another account with the same four fields as my wallet made the account model feel real. There's no special "system contract" type. It's an account with executable: true. That's it.
Stop 5: Watching Mainnet Live
I switched to mainnet and sat on the Explorer homepage for five minutes.
Transactions streamed in constantly. The validator vote transactions were the most frequent the network's heartbeat, validators confirming each other's blocks. Mixed in were user transactions: token swaps, NFT mints, DeFi interactions.
I clicked a Jupiter aggregator swap at random. It had:
- 14 accounts in the account inputs list
- 4 programs invoked (Jupiter, Token Program, Associated Token Account Program, System Program)
- Log messages 40 lines long
- Total fee: 5,000 lamports the same as my simple transfer
What I noticed: The fee is flat regardless of complexity. A 14-account, 4-program DeFi swap costs the same base fee as a 2-account SOL transfer. The computational complexity shows up in compute units consumed (also visible in Explorer), but the base fee structure is simple and predictable.
What Explorer Taught Me That the CLI Didn't
The CLI gives you data. Explorer gives you the data plus context.
Seeing my 27 transactions as a timeline with amounts, fees, and success/failure status all visible at once gave me a sense of my own on-chain history that individual RPC calls never had. Seeing the system program's transaction count in the millions gave me a sense of Solana's scale that throughput numbers alone don't convey.
Use Explorer to verify, debug, and build intuition. Use the CLI to build. They're reading the same chain but they feel completely different.
Top comments (0)