An allowance record describes spending permission.
LET’S PICTURE IT
A permission slip names an owner, an authorized spender and a limit.
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.
Recognize the common declaration
Approval(address,address,uint256) commonly indexes owner and spender while leaving value in the data tuple. Its topic zero differs from the Transfer event digest.
Separate permission from movement
An Approval log is not by itself a token transfer. It relates to an allowance, while transferFrom behavior and subsequent state determine whether spending occurs.
Read the raw allowance
The value is a raw integer interpreted under the token’s units. A very large allowance can grant broad spending permission even though no balance movement is shown in that log.
Avoid treating a log as current state
Later transactions may change an allowance, and implementations can differ. A historical event is a record from that execution, not a guaranteed current allowance query.