Read the structured notes that contracts leave during execution.
LET’S PICTURE IT
A contract updates its notebook and can also print a receipt. The receipt helps apps notice what happened.
SEE IT FOR YOURSELF
From an emitted Transfer event to a receipt logStep 1 / 4
A token implementation may update balances and emit its standard Transfer event. State and the emitted record are related but distinct.
A token implementation may update balances and emit its standard Transfer event. State and the emitted record are related but distinct.A non-anonymous Transfer event uses the full thirty-two-byte Keccak-256 signature digest as topic zero, not a four-byte function selector.In the common ERC-20 shape, from and to occupy topics one and two. The raw value is a thirty-two-byte data word. Other standards can index fields differently.An application can decode receipt logs under the correct ABI. A matching signature does not establish that an unknown emitter is an honest token.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
State and logs have different jobs
An event emits a log during transaction execution. Apps can search logs to build histories or update their interface. Logs are not a replacement for contract state, and contracts cannot directly read historical logs through ordinary EVM operations.
The first topic identifies the event shape
For a non-anonymous Transfer(address,address,uint256) event, topic 0 is the full Keccak-256 hash of that signature. Unlike a function selector, it uses all 32 bytes. Parameter names and the indexed keyword are not included in that signature.
Indexed fields become topics
In the common ERC-20 Transfer event, from and to are indexed address fields, so they appear in topics 1 and 2. The value is encoded in the data field. Indexed dynamic or complex values use a hash representation, so the original content cannot generally be recovered from the topic alone.
Try a receipt locally
The event decoder accepts topics and data and decodes the standard ERC-20 Transfer shape. These are example bytes, not a fetched receipt. A matching event signature does not prove the emitter is a trustworthy token contract.