How to read a Solana transaction, and what each part tells you

Published September 4, 20263 min readTools

A walkthrough of a Solana transaction in an explorer, which fields matter, how to tell a real swap from a suspicious one, and how to read failures.

Every claim about what happened on Solana resolves to a transaction, and every transaction is public. Learning to read one takes about 20 minutes and it replaces a lot of guessing.

Open any signature in Solscan and work through it with me.

The header

Top of the page gives you five things: status, block, timestamp, fee paid, and the signer.

Status is binary. Success means every instruction executed. Failed means one didn't, and the whole transaction rolled back, though you still paid the fee for the attempt.

Fee is worth glancing at. A base fee on Solana is tiny. If you see something much larger, that's a priority fee, and it tells you the sender was competing to get included during congestion.

Account inputs

Below the header, a list of every account the transaction touched, each marked as signer, writable, or read-only.

Two things to notice. The signer is who authorised this, which is the wallet that pays the fee and grants permission. Writable accounts are the ones whose state changed, which on a swap means the token accounts and the pool.

Read-only accounts are usually programs and configuration. They matter less for diagnosis but they tell you which systems were involved.

Instructions

This is the substance. Every transaction is a list of instructions, executed in order, all or nothing.

One instruction against the System Program is a plain SOL transfer. A swap on a Pump.fun coin has several: maybe a compute budget instruction, a token account creation if the buyer doesn't have one yet, then the actual swap against the bonding curve program.

Reading the program names tells you what happened without needing to decode anything. See the Pump.fun program? That's a curve trade. See an AMM program instead? The coin has graduated and this is a pool swap.

Balance changes

Scroll to the balance section and you get the outcome in plain numbers: which accounts gained, which lost, and how much.

For a buy, the buyer's SOL goes down and their token balance goes up, while the curve account moves the other way. Numbers that don't match that shape are worth a second look.

This section is also how you verify a payment. Somebody claims they sent 4 SOL to an address? The balance change either shows it or doesn't, and no amount of screenshot editing changes what the chain recorded.

Logs

At the bottom, program logs. Raw and verbose, and the place failures explain themselves.

Common messages worth recognising: slippage tolerance exceeded means the price moved past what the sender authorised. Insufficient funds means exactly that, and often includes rent for a token account nobody accounted for. Compute units exceeded means the transaction needed more computation than it asked for.

Reading a failed transaction maps the common errors to fixes.

Telling a real swap from a suspicious one

Now the part that matters for a creator checking activity on their own coin.

Open several transactions from your mint's transfer list and ask: do the signers differ, or is one address doing everything? Do the amounts vary, or is it 0.4 SOL forty times? Do the signers have history before your coin, or does each one appear from nowhere, buy once, and go quiet?

Real activity has variety in it. Sizes differ, timings scatter, addresses have pasts. Show me a tape where every transaction is the same size at the same interval, from addresses funded 10 minutes earlier by one wallet, and I'll show you a script that reads as a script to anybody who spends 2 minutes looking at it. How a fleet gets funded covers why that pattern is harder to avoid than it sounds.

A 5-minute exercise

Best way to learn this is on your own coin.

  1. Open your mint in Solscan and click the most recent swap
  2. Identify the signer and whether it's a wallet you recognise
  3. Find the program that executed the trade
  4. Read the balance changes and confirm they match a buy or a sell
  5. Click the signer's address and look at what else it has done

Do that 5 times and you'll read transactions faster than most people who talk about them confidently. How to use Solscan covers the rest of the explorer.

If what you find is 8 transactions from 3 addresses, that's a distribution problem rather than a data problem, and the console prices sustained activity against a specific window with the full cost shown before anything is signed.

Frequently asked

What is a signature?

The unique identifier for a transaction, a long base58 string. Paste one into any explorer and you get the full record. If somebody claims something happened on chain, the signature is the proof.

Why did I pay a fee on a failed transaction?

Because it reached a validator and consumed resources before failing. Transactions that never land at all cost nothing, which is a different situation with a different fix.

What does compute units exceeded mean?

The transaction needed more computation than it requested. Common on complex swaps through several programs, and usually fixed by requesting a higher compute limit or simplifying the route.

How to check this yourself

Everything in this guide describes mechanics that settle on Solana mainnet, so you can check any of it yourself. Mint addresses, swap signatures, curve progress and wallet counts are all public, and an explorer will disagree with us if we are wrong.

Curvegrad sells a volume service, and guides that touch on what a campaign does say so in the text rather than in a footnote.

what this is based on
  • Solana mainnet transaction history, read through the standard RPC methods
  • Pump.fun bonding curve and PumpSwap pool accounts as they appear on-chain
  • Public block explorers, where every claim here can be verified against a real mint
  • Campaigns run through our own engine, which is where the operational detail comes from