Verify emitter, topics, data and rollback behavior.
LET’S PICTURE IT
An action record should name the right office and contain the expected fields.
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.
Use a known declaration
PracticeCounter emits Increased(address indexed caller,uint256 value). Its signature topic uses the canonical event types, while caller is an indexed field.
Check the emitted address
The local receipt should attribute the record to the deployed counter instance. A matching topic from another contract is not the same assertion.
Decode the exact fields
After the first successful increment, caller should be the owner and value should be one. Do not infer the value only from a UI message.
Test rejected execution
An unauthorized call must not leave a surviving Increased log. A trace can show attempted operations differently from retained receipt logs.
Define the test
increment as owner
find log emitted by the counter
assert Increased(owner, 1)
rejected call → no retained Increased log
Test plans are framework-neutral unless labeled as complete Solidity or JavaScript. Use a local test environment and no real funds.