How to Read a Transaction on Solscan: A Field-by-Field Guide

When you open a transaction, check three things first: Result (success or failure), Signer (who submitted it), and how balances changed. These answer most questions: did the transaction take effect, who did it, and where did the SOL and tokens go. Instructions and logs are for telling transaction types apart. Expand them when you need to.

The sections below follow the page from top to bottom. Field names follow the Solscan documentation (checked October 2026). Positions may shift after a redesign.

What the fields at the top of the transaction page mean

A transaction’s signature (Signature) is its ID. Paste a signature into the Solscan search box to open its transaction page.

Result is the first thing to check. A transaction that looks like a “buy” may well have failed, with no tokens ever arriving.

Where the money and tokens went

In the Solscan documentation, Main Actions breaks a transaction into one or more transfers, such as “an address sent X SOL to an account” or “an account sent out X tokens”. For most readers, this section is enough to see the overall direction.

The page usually also lists each account’s SOL and token balance changes before and after the transaction. Exact label names follow whatever page you see. Two things to keep in mind when reading balance changes:

• Not all of the signer’s lost SOL was spent. If this is your first time holding a token, the transaction includes a Create Associated Account step. It means the program opened a new account for you to hold that token, which requires a small SOL deposit.
• Identify tokens by contract address (mint), not by name. Anyone can give a token the same name and logo. Only the mint address is unique.

For a more visual view, click the TX Map button on the transaction page. It draws the transaction’s flows as a diagram. Tick “show token accounts” to see the token accounts actually involved and how they changed.

Instructions: which program is actually doing the work

The Solscan documentation suggests that ordinary users keep Instruction Details and Program Log collapsed. But to tell whether a transaction is a launch, a buy or a migration, the instructions are exactly what you need.

Think of an instruction as “which program was called, and what it was asked to do”. Instruction details contain:

• Program address: which program was called. Recognize it and you know which platform the action happened on.
• Instruction Data: encoded parameters. When Solscan can decode them, it shows the instruction name.
• Input Accounts: which accounts this instruction read or wrote.
• Inner Instructions: other programs that a program called while it was running.

Addresses of a few common programs, taken from each one’s official documentation:

For orders placed through a trading bot or aggregator, the top-level call is usually the bot’s or aggregator’s own program, with pump.fun’s program tucked away in the inner instructions. So not seeing the Pump program at the top level doesn’t mean the transaction has nothing to do with pump.fun. Look in the inner instructions.

How to recognize a launch, a buy, a sell and a graduation migration

Read balance changes and instructions together, and most pump.fun transactions can be identified like this:

On-chain, a pump.fun graduation is a migration transaction. According to pump.fun’s program documentation, anyone can call the migration instruction, so the signer of this transaction is not necessarily pump.fun; the fee page says migration is usually executed by a pump.fun account. The PumpSwap LP tokens received at migration are burned, and the migration fee of 0.015 SOL is deducted from the curve for SOL-paired tokens.

One more detail: the buy that takes the last tokens off the curve and the migration are not the same thing. In the “synthetic migration” the documentation describes, this buy completes the curve first, and the excess is filled at the price of the pool about to be created; migration then creates the pool as a separate step. Between these two steps, all buys and sells on the curve fail.

The most common misreadings

Treating Fee as the trading fee. Fee is only the network fee. The 1.25% trading fee on each pump.fun curve trade is deducted by the program from the trade amount, and you see it in the balance changes.

Treating the signer as the token’s owner. The signer is just the address that submitted the transaction. Anyone can submit a migration transaction, so the signer may have nothing to do with the token’s creator or holders.

Identifying tokens by name alone. Anyone can give a token the same name, ticker and logo. Checking the mint address is the only reliable way.

Treating labels as certification. According to the Solscan documentation, quantitative labels rank wallets by on-chain behavior, such as which tier a wallet’s transaction count reaches across the network. They describe activity, not trustworthiness.

Assuming a failed transaction cost you your money. Trades in a failed transaction don’t take effect, and usually only the network fee is charged. Conversely, when you see a successful transaction, still check that the tokens actually arrived at your address.

The “graduations” in our figures count tokens whose curve completed, the step just before migration, not the migration transactions described above. How each metric is calculated is set out in a table on the Methodology page.

References

• Solscan transaction details: Transaction Details
• Solscan TX Map: TX MAP
• Solscan address labels: Labeling
• pump.fun program documentation: PUMP_PROGRAM_README, PUMP_SWAP_README, SYNTHETIC_MIGRATION
• pump.fun fees: pump.fun/docs/fees
• Raydium program addresses: Program addresses