An Ethereum transaction often does more than send ETH from one address to another. It may call a contract, transfer tokens, grant a spending allowance, or coordinate several actions. A wallet can summarize the result in one line, while a complete ledger needs to explain the asset movements and fees behind that summary.
The Ethereum ledger overview introduces the wider recordkeeping context. This guide focuses on four pieces of evidence: the submitted transaction, its execution receipt, relevant contract events, and the balances those events help explain. Keeping these pieces separate makes complicated activity easier to review.
A transaction requests a change in state
Ethereum maintains account and contract state. A transaction supplies instructions that the network executes according to its rules. A simple transfer can change ETH balances. A contract call can change data maintained by a program, including the balances of a token implemented by that contract.
The official Ethereum transaction documentation explains the main transaction fields and lifecycle. For recordkeeping, the crucial distinction is between the request and its outcome. A submitted transaction describes what someone authorized; the resulting receipt and state determine what actually happened.
Do not interpret every interaction with a contract as a purchase or a payment. A transaction might only update a permission or configuration. Preserve the technical action first, then add a business description when the surrounding evidence supports one.
Read the transaction fields precisely
| Field | What to look for |
|---|---|
| Transaction hash | The reference used to retrieve this transaction. |
| From | The address submitting the signed transaction. |
| To | The destination address or called contract; contract creation is a special case. |
| Value | The native ETH attached to the call, expressed in base units. |
| Input data | The encoded contract call and its arguments, when present. |
| Nonce | The submitting account's transaction sequence value. |
The value field is a frequent source of confusion. A token transfer can show zero ETH value because the token movement is represented in contract execution. Similarly, the “to” address may be a token contract or routing contract, while the final token recipient appears elsewhere in the decoded call and events.
The receipt records execution evidence
A transaction receipt supplies block information, execution status, gas used, and event logs. Read the status before classifying the intended action as completed. A failed transaction can be included in a block even though its intended contract changes did not take effect.
Failure also does not imply zero cost. Execution can consume gas before reverting. The sender may therefore have a lower ETH balance after a failed token transfer while the token balance remains unchanged. Keep the failed attempt and its fee in the history without inventing a completed transfer.
A missing receipt is a different condition. The transaction may still be pending, or the data provider may not have the requested record. Check the network, hash, and observation time. Preserve “pending” or “unresolved” as an explicit status until the evidence supports a more definite description.
Token events add the movements that ETH value omits
For a conventional ERC-20 token, Transfer events identify token movements, while Approval events relate to allowances. Each event is associated with the contract that emitted it. The contract address is essential: the event name or token symbol alone does not establish which asset you are examining.
Keep the network, emitting contract, transaction hash, and log index together. Several transfers can occur in one transaction, so a transaction hash alone is not a unique identifier for every token movement. This combination also helps prevent duplicate imports when two providers report the same event.
Token amounts are stored as integers. If a token uses six decimal places, a raw amount of 25,000,000 represents 25 displayed units. Applying eighteen decimals by habit would produce a different result. Preserve the raw quantity and the decimal convention used to display it.
Event interpretation has limits. Contracts can implement unusual mechanics, and unfamiliar contracts can emit misleadingly named events. Check actual asset identity and resulting balances before accepting a provider's label. The token contract ledger guide develops this distinction between raw event evidence and the meaning assigned to it.
Gas limits and actual charges answer different questions
Gas measures execution work. For an ordinary Ethereum execution transaction, the execution charge is gas used multiplied by the effective gas price. Gas used describes what execution consumed; the gas limit describes the permitted maximum. Treating the limit as consumption can overstate the fee.
Likewise, a maximum fee setting is a ceiling used when constructing the transaction, not necessarily the actual per-unit price paid. Use the included transaction's receipt and supported fee fields when recording the settled charge. Keep the result in ETH units before optionally attaching a separately documented currency valuation.
Some transaction types and other networks have additional fee components. A fee formula suitable for a basic Ethereum transaction should not be copied blindly into a rollup ledger. Record the network explicitly, and retain the source's breakdown when it reports more than one component.
A worked token-transfer example
Suppose a wallet starts with 1 ETH and 250 units of a hypothetical ERC-20 token named SAMPLE. It completes a transfer of 50 SAMPLE, attaching zero ETH value. Assume its receipt reports 60,000 gas used and an effective gas price of 20 gwei. These are invented teaching inputs, not current network estimates.
Since one gwei is one billionth of an ETH, the execution fee is 0.0012 ETH. With no other activity or fee components in the example, the wallet ends with 200 SAMPLE and 0.9988 ETH. The token recipient receives 50 SAMPLE under the example's conventional token behavior.
A reliable ledger links two asset entries to one transaction: the 50-token outgoing movement and the 0.0012 ETH charge. The zero in the transaction's ETH value field does not mean nothing happened. If execution had failed instead, the recorded token movement would need to follow the actual outcome, while the actual consumed fee could remain.
Permissions belong in the record without becoming transfers
An approval can authorize a spender to use tokens under the token contract's rules. That authorization is distinct from an immediate token movement. Recording an allowance amount as an outgoing transfer would make holdings appear to fall when the tokens remain in the account.
Record the token, owner, spender, transaction reference, and observed allowance change in a separate permission note or event type. Some permissions remain relevant after the transaction that created them. The wallet permissions guide explains how to keep this continuing authorization visible alongside completed asset movements.
Look beyond one explorer tab
An explorer may separate ordinary transactions, token transfers, and internal activity into different views. Internal activity commonly describes calls or value movements within execution, rather than separately signed top-level transactions. Counting each view as an independent list of payments can duplicate the same underlying event.
Group evidence by transaction, then identify the individual movements that affect your tracked accounts. For a complex call, compare the relevant before-and-after balances and use traces or decoded instructions to explain the difference. Keep an unresolved classification when the available provider data cannot explain it fully.
When comparing balance snapshots, use a consistent block boundary. A current token balance can include later activity that was absent when the transaction executed. Preserve the block number used for a historical comparison, so another review can examine the same state rather than a moving current balance.
Questions that help diagnose a mismatch
Why did my ETH decrease when I only sent tokens?
The transaction can pay its execution fee in ETH while moving a separate token. Compare the receipt's actual charge with the ETH balance change, allowing for any additional native ETH movements in the same transaction.
Does a successful receipt prove the action was desirable?
No. Success means execution completed under the network's rules. It does not prove the contract was the one you intended, that a token has value, or that the resulting permissions match your expectations.
Conclusion: connect requests, events, and balances
A clear Ethereum ledger follows execution evidence through to asset changes. Keep gas separate, identify tokens by contract, and distinguish permissions from transfers. The Ethereum recordkeeping guide provides the broader framework for applying this method across accounts and applications.
