In this track: Smart contract security foundations
advanced · 4 MIN READ
ERC-20 return value differences
Integration code must handle actual token call conventions.
LET’S PICTURE IT
Two service desks can report failure through different response formats.
SEE IT FOR YOURSELF
Follow a revert and decode its error dataStep 1 / 4
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.The contract rejects this request. State changes in the reverted call are rolled back, while work already consumed can still cost gas.A common Error(string) begins with selector 08c379a0. This example then encodes the message Not enough tokens.A decoder can recognize the supplied error shape. Identifying the true cause and source still needs the call context, code and state.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Read the standard result
The ERC-20 interface includes boolean success results and requires callers to handle false. A non-reverting call is not automatically a true return value.
Recognize deployed differences
Some deployed tokens return no boolean data or have other nonstandard behavior. An integration should use a reviewed compatibility approach rather than inventing one from a single token test.
Separate transfer amount behavior
A compatible call wrapper does not automatically make fee-on-transfer, rebasing or callback behavior fit the application’s accounting assumptions.
Test the intended asset set
Use mocks for false, empty and reverting results, then assess each supported real asset’s documented behavior. A generic interface alone is insufficient.