DEV Community

Cover image for I Used Solana Explorer Like Chrome DevTools. Here's What I Found
Samuel Akoji
Samuel Akoji

Posted on

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

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 beneath the surface.

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.

Top comments (0)