HostHostDeFi › Guides › Reading a Solana transaction
Reading a Solana transaction
Explorers label a transaction whatever the calling program says it is — 'Swap,' 'Interact,' 'Execute.' The only honest summary is the balance sheet at the bottom: who gained what, who lost what, and which programs touched it.
Every Solana transaction is a bundle of instructions executed atomically — either the whole thing lands or none of it does. When something goes wrong (a suspicious drain, a swap that didn't do what it said, a "claim" that took something), the transaction page on an explorer is the forensic record. Reading it well means ignoring the parts that are labels and going straight to the parts that are physics: balance changes and program invocations.
The anatomy that matters
Signature and status. The signature is the transaction's permanent ID — the first thing to paste anywhere someone asks "what happened." Status shows success or the specific failure (and failed transactions still cost fees).
Fee payer and signers. Who paid and who signed — the accounts that consented. In a drain investigation, the signers tell you which wallets were involved; in a swap, whether a program signed for its own accounts.
Instructions vs inner instructions. Top-level instructions are what the transaction asked for; inner instructions are what programs did in response — the cross-program calls where a "simple swap" can quietly invoke three other programs. Explorers collapse inner instructions by default. Expand them. The drain always lives there.
Pre/post token balances — the ground truth. Every explorer renders a balance-change table: each token account's balance before and after. This is the section that can't lie — programs can name a transaction anything, but they cannot hide that tokens moved. Read this table first; everything else is commentary.
The reading order that catches things
Start at the balance deltas
Whose token balance fell, whose rose, by how much. A transaction that was supposed to swap A for B shows A leaving you and B arriving — anything else in the delta (a third token moving, SOL leaving to an unexpected address, a token account being created for someone else's benefit) is the part the label didn't mention.
Expand the inner instructions
Follow which programs the top-level call invoked and what token transfers they contain. A drainer's "claim" typically shows one innocuous top-level call whose inner instructions carry transfers of your assets to their accounts — invisible until you unfold the tree.
Check for delegate and authority changes
Watch for Approve/SetAuthority-type instructions — a transaction that grants a delegate authority over your token account is a signature that keeps spending after it confirms. On Solana the delegate permission lives on the token account, which is what the revoke path clears.
Name the programs, not the transaction
"Execute," "Interact," "Claim" mean nothing — the program IDs are the truth. A known DEX program ID is a swap; an unknown program ID holding your tokens is a question to answer before doing it again.
The shapes you'll actually meet
A normal swap — token A out of your account, token B in, routed through one or two DEX programs, possibly with wrapped SOL appearing transiently in the deltas (normal — it's the routing rail, not a leak).
A drain — your balance deltas show tokens leaving to a wallet that isn't a pool, often packed into a transaction whose top-level instruction was a "message sign" or "verification." The tell is the destination: recipient accounts with no DEX identity collecting assets from many victims.
A disguised approval — a tiny transaction, no balances move, but an Approve instruction sets a delegate on your token account. Balance zero, damage pending — this is why the delta check alone isn't enough and step 3 exists.
The one-line summary: the title of a transaction is whatever the program chose to call it — the balance table and inner instructions are what it actually did. When the two disagree, the label is the costume and the deltas are the crime scene.
Pair it with the account-level read
A transaction tells you what happened; the token's contract tells you what could happen next. After a suspicious interaction, the follow-up checks are the token's authorities (can the deployer still mint/freeze), the delegates on your token accounts (who can still spend), and the token's own risk posture — the authority levers and the scan fields cover both reads. For the EVM twin of this skill — logs, approvals, transfer events — see the EVM transaction guide.
The transaction shows what happened — the scan shows what's next
Paste the token contract involved: authorities still live, delegates still granted, liquidity posture — read before the next signature, not after it.
Frequently asked
What are inner instructions?
Cross-program calls — what invoked programs did inside your transaction. Explorers collapse them by default; the drain hides one click deeper.
Most important section?
Pre/post token balances — accounts' before/after. Labels can lie; balance movement can't. Read the delta table first.
Spotting a disguised approval?
Approve/SetAuthority-type instructions with no balance movement — a delegate set on your token account, live until revoked.
Wrapped SOL in a tx?
Usually normal DEX routing (SOL↔wSOL inside the tx). Transient in the deltas — not a leak. Unexplained SOL to a foreign address is the flag.
Drained — what to look for?
Which inner instruction moved assets, the destination account, any Approve/SetAuthority leaving delegates live — then revoke and migrate.