How to Read a Solana Transaction Before You Trust It

Your wallet says "success." The swap screen says you got a nice round number of tokens. Then your balance looks a little off and you're not sure if it's the fee, the slippage, or something worse. The wallet popup is a summary. The transaction itself is the receipt, and learning to read a Solana transaction on an explorer is how you find out what really happened.

This is the boring skill that settles most "where did my SOL go?" questions in the trenches. I'll go through what a transaction actually contains, which parts of an explorer page to check first, a worked example straight from Solana's own docs, and where the explorer view stops being trustworthy. Everything technical links to the Solana documentation so you can check me.

What is a Solana transaction, in plain words?

A transaction is a signed bundle of instructions. Per Solana's transaction docs, it carries one or more instructions, a signature from every account that authorizes changes, and a recent blockhash that keeps it from being replayed later (that blockhash is valid for 150 slots). Each signer adds one 64-byte signature, and the first signature doubles as the transaction's ID. That long string is what you paste into an explorer.

The rule that matters most for traders: execution is atomic. Every instruction succeeds, or the whole thing reverts. A swap can't half-happen. But the docs are just as clear that fees are still charged when a transaction fails. So a failed buy didn't take your SOL for tokens, but it did cost you the fee.

What should you check first on the explorer?

Open your signature on the official Solana Explorer or whichever explorer you trust. Layouts differ, but they all read from the same underlying record, which the getTransaction RPC method lays out field by field. Start with four things:

• Result. In the raw record, err: null means success. Anything else is a failure, and it often says which instruction broke.
• Slot and time. The slot is where it landed. The block time is an estimate of when it was processed, not an exact timestamp.
• Commitment. An explorer may be showing you confirmed rather than finalized data. I covered what that difference means in Solana commitment levels explained.
• Fee. Shown in SOL or lamports (one SOL is a billion lamports).

The fee has two parts, per Solana's fee docs. The base fee is 5,000 lamports per signature, half burned and half paid to the validator. The optional priority fee is the compute-unit price times the compute-unit limit, divided by a million, and all of it goes to the validator. If your fee looks big, that's almost always the priority fee your wallet or bot set. I broke that formula down in Solana priority fees and compute units.

Which part shows what you actually got?

Balance changes. That's the part I'd tell anyone to read before anything else. The record stores every involved account's SOL balance before and after (preBalances / postBalances, in lamports) and every token account's balance before and after (preTokenBalances / postTokenBalances), each tagged with the token's mint and owner. Explorers turn this into a "balance changes" style table. The difference between before and after is what actually moved. Not the quote, not the toast.

A worked example from the docs

The getTransaction page includes a real example transaction that creates an associated token account. The paying wallet starts at 998,528,400 lamports and ends at 996,484,120. That's 2,044,280 lamports gone. It looks like an expensive fee, but the same record shows the fee was only 5,000 lamports. The other 2,039,280 lamports went into the brand-new token account as its rent deposit, which you can get back by closing the account later (more on that in Solana token accounts and rent).

That's exactly the confusion people hit on their first buy of a new token: "the fee was way more than 0.000005 SOL." Usually it wasn't. Part of it was a refundable deposit, and the balance diff shows you which part.

For a swap, the same diff tells you your real fill: how much SOL or USDC left, how much of the token arrived. Compare that with what the quote promised and you've measured your own slippage and price impact (the difference between the two is in slippage vs price impact on Solana).

What do instructions, inner instructions and logs tell you?

Once the money adds up, the instruction list tells you how it got there.

• Instructions are the top-level calls your wallet signed, each aimed at a program: a transfer through the System Program, a token-account creation, a swap through a DEX or aggregator.
• Inner instructions are calls those programs made to other programs while running. A routed swap shows its hops here. In the docs example, one "create account" instruction quietly triggers four inner ones.
• Log messages are the program's own diary: which program was invoked, how many compute units it consumed out of its budget, and whether it ended in success or an error.

When a transaction fails, the error usually points at an instruction by index (the raw form is InstructionError with the instruction number and the reason). The logs right above the failure tell you who complained. A slippage-tolerance error on a swap is a very different problem from running out of compute units, and you'd fix them differently. Read it before you spam retry.

How do you read a Solana transaction in the trenches?

Here's the routine I'd use after any buy, sell or transfer that matters:

• Start from the signature, not a screenshot. Copy it from your wallet's activity and open it yourself. Screenshots and "proof" links in a Telegram chat can be anything.
• Check the mint, not the ticker. Token balances are tagged by mint address. Anyone can name a token the same thing as a popular one; the mint is what you actually hold.
• Diff your own balances. SOL out, tokens in. That's your real entry. Write it down if you track P&L.
• Separate fee from deposit. The fee field is the fee. A one-off drop of a couple of million lamports on a first buy is usually a token-account deposit, not a fee.
• Look for anything you didn't ask for. An extra transfer out, or an SPL Token approve (which gives another address delegate rights over a token account) or setAuthority instruction you didn't expect, is a reason to stop and investigate before you sign anything else from that site.

Last one ties into Solana address poisoning: when you check a transfer, read the full destination address, not just the first and last few characters.

What an explorer can't tell you

An explorer shows what the chain recorded. It's not a judge. A few limits worth knowing:

• Labels are the explorer's, not the chain's. Names like "Raydium" or "exchange wallet" come from the explorer's own tagging. Useful, but they can be missing or wrong.
• Readable views depend on parsers. The docs note that parsed output falls back to raw accounts and data when no parser exists for a program. A new or unknown program can show up as an opaque blob.
• Success isn't safety. A perfectly successful transaction can still be a terrible trade or a buy into a rug. The record proves what happened, not whether it was smart. For that side, see how to analyze a Solana wallet before buying.
• Decimals matter. Raw token amounts are integers scaled by the mint's decimals. Most explorers handle that for you, but if you're pulling raw RPC data, use the decimal-adjusted string, not the raw number.

The takeaway

Your wallet tells you what it thinks happened. The transaction tells you what did. Check the result, split the fee from any deposit, diff your balances by mint, and read the error before retrying. Five minutes on an explorer clears up most "where did my SOL go?" moments, and it turns your own trades into data you can actually learn from. More plain-words walkthroughs live in the guides. When a trade looks off, do you open the explorer first, or do you go straight to the chart?

Still building. Still here. 🫡