How to read a Solana transaction on Solscan, step by step

The short answer

To read a Solana transaction, open its signature in an explorer and check four things in order: the status and fee, the balance changes, the instructions (including inner instructions), and the program logs if it failed. Balance changes show what actually happened to each account. Instructions show what programs were asked to do. The fee is 5,000 lamports per signature plus any priority fee, and it is charged even when the transaction fails.

The same fields appear on Solscan, Solana Explorer, SolanaFM and Orb, under slightly different names. Below is what each field means, where to find it, a real transaction walked through value by value, and how to read one before you sign it.

What is inside a Solana transaction?

A Solana transaction is a signed message with four parts: signatures, an account list, a recent blockhash, and one or more instructions. When the transaction is processed, the network adds a fifth part, the metadata: status, fee, compute units, balances before and after, and logs. The Solana docs on transactions describe the format in detail. Here is each field and what to look for:

Field	What it is	What to check
Signature	A 64-byte Ed25519 signature, shown as an 87 or 88 character base58 string. The first one is the transaction ID.	That it is the transaction you meant to look up.
Fee payer	The first account in the list, which signs and pays the fee.	It should be your wallet for anything you sent.
Recent blockhash	A recent block hash that makes the transaction expire after about 150 blocks.	Nothing; it only matters when a transaction expires before landing.
Accounts	Every address the transaction touches, each flagged signer and/or writable.	Which accounts were writable, because only those could change.
Instructions	Calls to programs, each with its own accounts and data bytes.	Which programs ran and in what order.
Inner instructions	Calls one program made to another during an instruction (cross-program invocations, CPIs).	Where tokens actually went inside a swap or a contract call.
Address lookup tables	In version 0 transactions, a way to reference stored address lists instead of writing every address inline.	Accounts loaded this way are still part of the transaction.
Compute units	The work the transaction used, against the limit it requested.	A failure with consumed equal to the limit means it ran out of compute.
Fee	Base fee plus priority fee, in lamports.	It is paid whether the transaction succeeds or fails.
Balance changes	SOL and token balances of every account before and after.	This is the ground truth of what happened.
Logs and status	Messages printed by programs, and Success or the error.	The last failed line names the program that stopped it.

A signer is an account whose private key signed the transaction, which lets programs act on its authority. A writable account is one the transaction is allowed to modify; a program cannot change the balance or data of an account marked read-only. Those two flags are the quickest way to see what a transaction could possibly do to your wallet.

How do you read a transaction on Solscan?

On Solscan, paste the signature into the search box and read the page from top to bottom: overview, balance changes, instruction details, then logs. As of November 2026 the layout is:

1. Overview. Signature, block and timestamp, Result (Success or the error), Signer, Fee, priority fee, compute units consumed and transaction version. If Result shows an error, the rest of the page shows what was attempted, not what happened.
2. Balance Changes. A combined view of SOL and token balance changes for every address involved, with before and after values. Start here for anything involving your money.
3. Instruction details. Each instruction with its program, the accounts it used and its decoded fields, with inner instructions nested under it. Solscan decodes common programs and labels known addresses.
4. Program logs. The raw log lines, near the bottom of the transaction page.
5. Raw data. The undecoded instructions and bytes, for when Solscan's labels are not enough.

Solscan's documentation itself suggests ordinary users can skip instruction details and logs. That is good advice for a transfer you already understand, and bad advice for a transaction you did not expect.

How do you read a transaction on Solana Explorer?

Solana Explorer, run by the Solana Foundation, shows the same data in five tabs: Summary, Accounts, Tokens, Programs and Logs. Its source code is public, which is how I checked the labels below.

• Summary. Status, confirmation, signature, Fee payer, Slot, Recent Blockhash, Fee, Transaction cost, "CUs Consumed / Limit" and Transaction Version.
• Accounts. Every account with its SOL change and badges: Fee Payer, Signer, Writable, Program and Address Table Lookup for accounts loaded from a lookup table.
• Tokens. Token balance changes.
• Programs. Each instruction, decoded where Explorer knows the program, with inner instructions.
• Logs. Program logs grouped by instruction, with the runtime error attached to the instruction that failed.

The Inspect button on the Summary opens the same transaction in the Inspector, described below. Explorer is also the most precise about flags: if you want to know exactly which accounts were writable, its Accounts tab is the clearest place to look.

What about SolanaFM and Orb?

SolanaFM and Orb show the same underlying data with more emphasis on plain-language summaries. SolanaFM was acquired by Jupiter in September 2024 (The Block); its transaction pages still load as of November 2026, though some ecosystem trackers describe it as lightly maintained, so I would not rely on it alone. Orb, launched by Helius in October 2025, parses transactions with Helius's own APIs and shows summaries, balances, inner instructions and raw JSON, plus an "Explain with AI" button that summarizes the instructions in plain language (Helius). An AI summary is a convenience, not a verification; check it against the balance changes.

Which Solana explorer should you use?

Use Solscan for everyday lookups, Solana Explorer when you need exact account flags, logs or a pre-signing inspection, and Orb when you want a quick plain-language summary. This is how they compare as of November 2026:

	Solscan	Solana Explorer	SolanaFM	Orb (Helius)	SOLTidy Transaction Decoder
Balance changes, SOL and tokens	Yes	Yes (Accounts, Tokens)	Yes	Yes	Yes, grouped by wallet
Signer and writable flags	Yes	Yes, as badges	Not verified	Not verified	Signers only
Inner instructions (CPIs)	Yes	Yes	Yes	Yes	Yes, nested
Program logs	Yes	Yes, grouped per instruction	Yes	Raw JSON	Yes, errors highlighted
Custom error codes explained	Raw code	Runtime error shown	Raw code	Not documented	System, SPL Token, Token-2022, Jupiter v6
Inspect an unsigned message	Separate inspector	Yes, with simulation	No	No	No
v1 transactions	Not verified	Yes	Not verified	Not verified	No
Price	Free	Free	Free	Free	Free

"Not verified" means I could not confirm it from the explorer's documentation or code, not that it is missing.

What does a real Solana transaction look like?

Here is a real mainnet transaction, fetched with the getTransaction RPC method, with the wallet, token and signature left out to keep the user private. It is one of SOLTidy's cleanup transactions: a wallet burned a leftover pump.fun token and closed the empty token account. It is small enough to read every field.

Overview. Confirmed on November 4, 2026. Version 0, with no address lookup tables used. Status Ok. One signature, so one signer.

Accounts. Seven, in this order:

#	Account	Flags	What it is
0	Wallet…	Signer, writable	The wallet, and fee payer
1	TokenAcct…	Writable	Its token account for the pump.fun token
2	Mint…pump	Writable	The token's mint, writable because burning reduces supply
3	FeeWallet…	Writable	SOLTidy's fee wallet
4	ComputeBudget1111…	Read-only	Compute Budget program
5	TokenkegQfe…5DA	Read-only	SPL Token program
6	1111…1111	Read-only	System Program

Instructions. Five, and no inner instructions:

1. Compute Budget SetComputeUnitLimit: 1,850 compute units.
2. Compute Budget SetComputeUnitPrice: 10,176 micro-lamports per compute unit.
3. SPL Token burnChecked: burn 36,983.819779 tokens (6 decimals) from account 1.
4. SPL Token closeAccount: close account 1 and send its SOL to the wallet.
5. System transfer: 101,964 lamports from the wallet to the fee wallet, which is 5% of the recovered rent.

Fee and compute. The fee was 5,019 lamports: 5,000 base for one signature plus 19 lamports of priority fee, which is 1,850 × 10,176 ÷ 1,000,000 = 18.8, rounded up. The transaction consumed 708 of its 1,850 requested compute units. The priority fee is charged on the limit requested, not the units used, which is why a tight limit matters; the priority fee tracker shows what the market rate is right now.

Balance changes. This is where the transaction makes sense:

Account	Before (lamports)	After (lamports)	Change
Wallet (fee payer)	11,655,110	13,587,407	+1,932,297
Token account	2,039,280	0	−2,039,280 (closed)
Fee wallet	503,785,278	503,887,242	+101,964

The token balance of account 1 went from 36,983.819779 to nothing. The arithmetic closes exactly: 2,039,280 lamports of rent came out of the token account, 101,964 went to the fee, 5,019 paid the network, and the wallet kept 1,932,297, about 0.00193 SOL. A token account holding 0.00203928 SOL was opened before Solana lowered rent; newer ones hold 0.00148844 SOL, as explained in how much SOL you can recover from token accounts.

Logs. Twelve lines. Each instruction appears as Program … invoke [1] and Program … success; the [1] means a top-level call, while [2] or deeper would be a CPI. The token program also reported consumed 138 of 1550 compute units for the burn and consumed 120 of 1412 compute units for the close.

How do you read a failed transaction?

For a failed transaction, read the status line for the error, confirm the only balance change is the fee leaving the fee payer, then read the logs upward from the last failed line, which names the program that raised the error. A failed transaction that landed still pays the full fee, and every other effect is rolled back. The full walkthrough is in why Solana transactions fail, and what each code means, program by program, is in the Solana error codes reference.

One shortcut: programs built with Anchor usually print the error name and number in the logs themselves, in a line starting with AnchorError. When you see one, the explanation is already on the page, on any explorer.

How do you read a Solana transaction before signing it?

Read it in your wallet's approval screen, which simulates the transaction and shows the expected balance changes, and, for anything unusual, in Solana Explorer's Inspector. Reading after the fact tells you what went wrong; reading before is what protects you.

1. Read the wallet preview. Phantom, Solflare and Backpack simulate the transaction and list what leaves and enters your wallet. A swap should show one asset out and one in. Anything else leaving is a reason to reject. A failed or blank simulation on a site you do not know is also a reason to reject. The Solana wallet security checklist covers what drainer prompts look like.
2. Expect a few extra instructions. Wallets can add their own. Phantom, for example, may append Lighthouse assertion instructions that make the transaction fail if the result differs from the simulation, so the on-chain transaction can differ slightly from what the site built.
3. Use the Inspector for anything you want to check line by line. Open explorer.solana.com/tx/inspector and paste a raw base58 or base64 transaction message (or a Squads vault transaction account). It lists every account with its signer and writable flags, every decoded instruction and any lookup tables, and a Simulate button runs it and shows the logs and compute profile. Developers can print the message with tx.serializeMessage().toString("base64") in web3.js.
4. Check the token, not just the transaction. If the transaction buys a token you have never seen, the free Rug Check shows its mint and freeze authority, Token-2022 extensions and top holders. The rug pull checklist explains what each red flag means.

On a hardware wallet, a Ledger often cannot display the full details of complex transactions, which is called blind signing. Keep blind signing for apps you already trust.

How does SOLTidy's Transaction Decoder work?

I built the Transaction Decoder to put the useful parts of an explorer page into plain English on one screen. It is free, needs no wallet, and accepts a bare signature or a Solscan, Solana Explorer or SolanaFM link; it pulls the 64-byte signature out of the URL. It fetches the transaction from mainnet with getParsedTransaction and decodes it in the browser. Here is what it actually does, from the code:

• Plain-English instructions for the System Program, SPL Token, Token-2022, Associated Token Account and Stake programs, such as "Close token account … and send its rent to …". Compute Budget instructions are decoded from their raw bytes, because RPC nodes do not parse them, and Memo text is shown as is.
• Labels for other programs. Jupiter v6, Raydium AMM v4, CLMM and CPMM, Orca Whirlpool, Meteora DLMM, Pump.fun, PumpSwap, Phoenix, OpenBook v2, Metaplex, Magic Eden v2, Tensor and others are named, with their data shown raw, because decoding them needs each program's interface definition.
• Balance changes grouped by wallet. Token changes are summed per owner and mint, so a swap reads as one wallet losing one token and gaining another. The fee payer's SOL change is shown both with and without the fee.
• A fee split into base fee (5,000 lamports per signature) and priority fee, and compute units consumed against the limit requested.
• Error decoding. It translates built-in errors such as InsufficientFundsForRent, and custom error codes for the System, SPL Token, Token-2022 and Jupiter v6 programs. It reads the logs to find which program actually raised a custom error, since that is often an inner program rather than the one you called.

Its limits, honestly:

• No v1 transactions. Solana activated v1 transactions on mainnet at epoch 1035 in September 2026 (Chainstack). The decoder runs on @solana/web3.js 1.98.4 and asks the RPC for transaction version 0 at most, and support for reading v1 in web3.js only arrived in 1.99.0. For a v1 transaction the RPC returns an error, and the decoder shows a generic "The RPC request failed" message instead of saying why. Use Solana Explorer for those until I update it.
• Lookup table accounts are not marked. Accounts loaded from a lookup table appear in the account list, but the decoder does not say which ones came from a table.
• Mainnet only, and only landed transactions. A dropped transaction has no on-chain record anywhere. Very old transactions may be outside the RPC's history even when an archive-backed explorer still has them.
• Error translations cover four programs. For anything else it shows the code in decimal and hex, and you look it up in that program's error list.

Bottom line

Every Solana transaction has the same anatomy: signatures, a fee payer, a recent blockhash, a flagged account list and instructions, plus the metadata the network adds: status, fee, compute units, balance changes and logs. Read them in the order status, balance changes, instructions, logs, and you can follow any transaction on Solscan, Solana Explorer, SolanaFM or Orb. Read the wallet's preview before you sign, and use Solana Explorer's Inspector when you want to see every account and instruction first. To get a signature explained in plain English without connecting a wallet, paste it into the free Transaction Decoder.