HostNexFlow › Guides › Reading an EVM transaction
Reading an EVM transaction
On EVM chains the transaction's label is decoration — the event logs are the ledger. Reading them is the difference between 'I clicked swap' and 'I know exactly what moved and who can still move it.'
Every EVM transaction calls one contract — but that contract can call others, mint events, move tokens, and grant permissions that outlive the transaction itself. The explorer's default view shows you the envelope: from, to, value, fee. The audit lives one tab deeper, in the logs and internal transactions — where a "simple swap" can reveal itself to have also granted a stranger permission over your tokens.
The anatomy worth learning
From / To / Value. Who sent it, which contract executed, and how much native token (ETH/BNB/etc.) moved with the call. A "swap" sending value to an address that isn't a router is already a flag.
Input data. The encoded function call — which method ran and with what arguments. Explorers decode common calls; a hex blob on a transaction that was supposed to be simple is worth pausing on.
Internal transactions. The contract-to-contract calls inside yours — where a single "claim" can fan out into transfers across your assets. Collapsed by default; expand them.
Event logs — the ground truth. Contracts emit events as they execute: Transfer (token moved A→B), Approval (spender granted allowance), Swap, Mint. The token-transfers tab aggregates these into "what left you, what arrived" — the section that cannot lie about movement, whatever the UI claimed the button did.
The reading order
Token transfers first
Which tokens left your address, which arrived, and the destinations. A transaction meant to swap X for Y shows X out and Y in — anything else moving (a third token leaving, a transfer to an unknown EOA) is the part the dApp didn't mention.
Then approvals — the sleeper permission
Approval events show who you authorized to spend which token, and the amount. The dangerous pattern: an approval for unlimited (the max-uint256 figure) granted to a contract you didn't mean to trust forever. The balance didn't move today — the permission just armed a future transfer. The revoke path →
Internal calls for the hidden fan-out
One top-level call can invoke a dozen contracts. A drainer's signature typically looks like one innocuous call whose internals carry your tokens outward — the event log makes the destination visible even when the contract names are obfuscated.
Check contract labels, not transaction labels
Explorers label known contracts (routers, token contracts, known drainers sometimes flagged). An unlabeled contract holding an approval over your assets is a question to answer — through the contract's code and its history, not the dApp's branding.
The signatures that keep spending
Two EVM patterns outlive their transaction. Approvals — a granted allowance lets the spender move that token until it's revoked or exhausted; drainers farm these because one signature pays forever. And permits/signatures — gasless approvals you sign as a message, which settle the allowance in a transaction you may not even recognize as yours. Both mean: a "transaction that did nothing" can still have done everything. The post-interaction habit is checking your allowance state, not your balance — revokers and explorers both show outstanding approvals per spender.
The one-line summary: on EVM, what the transaction is called is whatever the dApp felt like naming it — the Transfer and Approval events are what it actually did. When they disagree, the events are the truth and the label is the costume.
Pair it with the contract-level read
A transaction tells you what happened; the token's contract tells you what could happen — mint functions, blacklist logic, hidden taxes, upgradeable proxies that can change the rules after you buy. After any suspicious interaction: check outstanding approvals, then read the token's own risk posture. Upgradeable proxies — the contract that can change → · for the Solana twin of this skill, the Solana transaction guide →.
The log shows what happened — the scan shows what's possible
Paste the contract: authorities, taxes, proxies, liquidity, and holder spread — the whole posture behind the transaction.
Frequently asked
What are event logs?
Records contracts emit during execution — Transfer, Approval, Swap, Mint. The token-transfers view aggregates them into what actually moved.
Spotting a dangerous approval?
Approval events granting a spender allowance — the flag is unlimited (max-uint256) to an untrusted contract. Balance stays today; permission pays later.
What are internal transactions?
Contract-to-contract calls inside yours — one 'claim' can fan out into transfers of your assets. Collapsed by default; expand them.
Can a do-nothing tx be dangerous?
Yes — approvals and signed permits arm future transfers without moving balances. Check outstanding allowances, not just balance.
EVM vs Solana reading?
EVM: one contract fans out via logs/internal calls — read Transfer/Approval events. Solana: bundled instructions — read balance deltas and inner instructions.