A block explorer marks a transaction as successful, but the expected result is missing from an address. Execution status is only part of the check. A transaction may call a contract that performs several transfers involving different tokens and addresses. A green status or the top-level to field does not explain all of those movements.
Separate execution status from token events
The eth_getTransactionReceipt method returns an execution receipt containing status and a logs array. In a standard modern receipt, 0x1 indicates successful execution and 0x0 indicates failure. An absent receipt does not establish a single cause: a copied null value alone cannot reliably describe the state of the whole network.
An ERC-20 transfer is described by a Transfer event with sender, recipient and an integer value. The contract address emitting the log is separate from those participants. The transaction's top-level to identifies its call destination; when contracts are involved, that field need not identify the final token recipient.
A teaching example: incoming matches, the log-derived difference does not
Consider a placeholder contract T and watched address B. The expected quantity is 1,500,000 atomic units, displayed with six decimal places. Addresses in the form are synthetic and do not identify genuine USDT or another actual asset.
| Index | Contract | Sender โ recipient | Atomic units | Effect for B under T |
|---|---|---|---|---|
| 0 | T | A โ B | 1,000,000 | Incoming +1,000,000 |
| 1 | T | A โ B | 500,000 | Incoming +500,000 |
| 2 | T | A โ C | 700,000 | Unrelated address |
| 3 | Other | A โ B | 1,500,000 | Different contract |
| 4 | T | B โ C | 250,000 | Outgoing โ250,000 |
Incoming events from the selected contract total the expected 1,500,000. However, outgoing events in the same transaction total 250,000. The difference from supported logs is 1,250,000, or 1.250000 at the entered precision. Looking only at incoming amounts would miss the second action.
Why a token name does not replace its contract address
A symbol or display name is not a filter parameter here. The tool compares the exact contract address chosen by the user. An identical address string on different networks still does not establish the same asset. Establish the network and correct contract independently before inspecting the receipt; the tool does not discover them.
It also does not treat every event called Transfer as an ERC-20 amount. ERC-721 defines an event with the same type signature but different value indexing. The parser therefore requires the supported layout: three topics, two correctly padded addresses and 32 bytes of data. A different layout is flagged for review rather than interpreted as fungible tokens.
What the report counts
- Incoming
- Supported Transfer values emitted by the selected contract with the watched address as recipient.
- Outgoing
- Values from those events with the watched address as sender.
- Difference from logs
- Incoming minus outgoing. A self-transfer contributes to both totals and makes no net difference.
- Expected-value match
- An arithmetic check of supplied data, not confirmation of crediting or an actual balance.
Integer arithmetic avoids rounding token values through JavaScript Number. Precision from zero to eighteen affects display only and is not read from the contract. Event data and the expected quantity remain integer atomic units.
Data needing a separate review
Repeated logIndex values are not summed. Every entry with a conflicting index is excluded, and the report requests review. Entries marked removed=true are excluded as well. That alone does not diagnose a reorganization: a copied set cannot establish which data a node currently considers canonical.
A failed receipt is not interpreted as completed transfers even if logs have been inserted into it manually. Unsupported event structure from the selected contract prevents the final local-check flag from passing. Historical receipts without status, nonstandard tokens and balance changes without the expected Transfer events are outside this model.
Why the difference is not called a verified balance
Checking an actual balance requires trustworthy state data and knowledge of the token's behaviour. Rebasing, custom logic or an incomplete receipt copy can make these events insufficient. The form does not call balanceOf or prove the completeness or authenticity of the list.
When investigating a swap, retain the network, transaction hash, contract, expected address and current order status. KOT.CASH describes its process on How It Works; processing conditions for an individual order require separate checks. The site's receipt generator performs a different task by formatting user-entered fields into a document, while this article explains events. Neither a locally completed document nor this report substitutes for verification on the chosen network.
Inspect supported ERC-20 Transfer events in a receipt
Synthetic example. Up to 200 logs and 100000 JSON characters. Only the standard ERC-20 Transfer layout with logIndex. Addresses compare as hex without EIP-55 checks. No network access, authenticity, balance, finality or KOT.CASH crediting verification. The calculation runs on your device; nothing you enter is sent anywhere.