How to read a transaction on a block explorer: Solscan, Basescan and BscScan step by step

Why read a transaction on an explorer[11]

Your wallet and the app show you their interpretation of a transaction. An explorer shows what was actually recorded on chain. On Solana the usual choice is Solscan, on Base it is Basescan and on BNB Chain BscScan. Etherscan's API documentation lists Base (chain ID 8453) and BNB Smart Chain (chain ID 56) among its supported networks, and Basescan and BscScan pages are laid out much like Etherscan.

Always start with the right network. The same hash or contract address pasted into another network's explorer finds nothing or shows something else entirely.

Solscan: the fields on a Solana transaction page[1][4]

The Solscan docs describe the transaction header like this: Signature is the transaction ID (hash), Block is the slot number of the block that contains it, Result shows Success or Failure and whether the transaction is Finalized. Signer is the sender address and Fee is the transaction fee.

Below are Main Actions, a breakdown into transfers, and Instruction Details. According to the Solana docs a transaction contains one or more instructions and executes atomically: all succeed or all revert. Each instruction names a program, its data and the accounts it reads or writes. Inner instructions are calls into other programs during execution, and the Program log records events from the programs.

If the transaction includes Create Associated Account, a program created a new token account. Solscan then shows the Authority (owner wallet), the Associated Account (the new account) and the Token Address (the mint).

Fees on Solana: base fee and priority fee[1][2]

According to the Solana docs the base fee is 5,000 lamports per signature: 50% is burned and 50% goes to the validator. The priority fee is ceil(compute unit price × compute unit limit / 1,000,000) lamports, because the price is set in micro-lamports per compute unit. The priority fee goes entirely to the validator.

The Fee field on the explorer is the total of these fees. It does not include deposits for new accounts: those show up as a separate drop in the SOL balance. A transaction's recent blockhash is valid for 150 slots, so an old, unsent transaction expires on its own.

Basescan and BscScan: EVM transaction fields[10][8][6]

The Etherscan docs describe the data behind a transaction page as details by hash (from, to, value and gas), a success or failure status, internal transactions and event logs. The status comes from the receipt: under EIP-658, 1 means success and 0 means failure, a revert of the transaction or its top-level call.

On a swap the To field is usually the DEX router contract, not the token recipient. Value is the native currency (ETH on Base, BNB on BNB Chain) sent along with the call. ERC-20 tokens appear in the token transfers section, which the explorer builds from Transfer events: the ERC-20 standard requires that event on every transfer, including zero-value ones.

Gas on EVM networks: what the numbers mean[7][8]

Since EIP-1559 the sender sets a max fee per gas and a max priority fee per gas. The protocol takes the priority fee as the smaller of the max priority fee and the max fee minus the block's base fee. The effective gas price is the base fee plus that priority fee. The base fee is burned, the priority fee goes to the block producer, and unused gas (gas limit minus gas used) is refunded to the sender.

The transaction fee on the explorer is therefore gas used × effective gas price. A high gas limit alone does not mean a high fee. A transaction with status 0 did not execute the swap, but you paid for the gas it used.

How to verify a swap[3][6]

Check a swap by its effects, not its description. On Solana, compare balances before and after: the getTransaction RPC response includes preBalances and postBalances as well as preTokenBalances and postTokenBalances. On EVM networks, look at the token transfers: how much left your address, how much came back and from which contract.

Compare the result with the amount the app showed before you signed. A shortfall beyond your slippage setting should not happen, because the transaction should then fail. Also make sure the token you received has the right contract address, not just the right ticker.

• Status Success on Solana or 1 on EVM
• The Signer or From is your wallet
• The amount spent matches what you approved
• The token received has the right contract address
• The fee is close to what the wallet showed

How to spot an approve for a wallet drainer[6][9][5]

The ERC-20 standard defines approve as letting a spender withdraw from your account multiple times, up to a set amount. A new approve overwrites the previous one. The spender then calls transferFrom and moves the tokens without another signature from the owner. Every successful approve emits an Approval event, visible in the transaction logs.

EIP-2612 adds permit: changing the allowance with a signed message instead of a transaction. Any address can call permit, so a signature in your wallet alone, without sending a transaction, is enough for someone else to set the allowance. On Solana the equivalent is a delegate: approve lets another address transfer or burn tokens up to a limit.

Red flags are an approve or permit for an address you do not know that is not a DEX router, a very large allowance, an Approval in a transaction that was supposed to be an airdrop “claim”, and later transferFrom calls from your address that you did not start. If you see this, revoke the permission: on EVM with a new approve set to 0, on Solana with a revoke instruction.

A worked example: figures from the docs and a hypothetical swap

The first example comes from the sample getTransaction response in the Solana docs. The second is hypothetical and only shows the arithmetic.