ERC-20 approval decoder: worked examples
Call Lens decodes supported token-call shapes locally and compares the recipient, spender and atomic amount with your expectations. It distinguishes ERC-20 allowances from ERC-721 token IDs using the declared standard. It never connects a wallet or evaluates contract safety.
Three fictional scenarios, calculated by the same engine as the tool. They illustrate behavior and failure cases, not customer outcomes or measured provider performance.
Unlimited ERC-20 approval
Compare maximum uint256 allowance with an entered limit.
- Declared method
- approve(address,uint256)
- Policy flags
- 2
- Security verdict
- Not assessed
| Field | Value |
|---|---|
| Network | eip155:8453 |
| Contract | 0x2222222222222222222222222222222222222222 |
| Action | Set spender allowance |
| Recipient / spender | 0x1111111111111111111111111111111111111111 |
| Atomic amount / bool | 115792089237316195423570985008687907853269984665640564039457584007913129639935 |
| Native atomic value | 0 |
Run this scenario Input JSON Calculated report
Inspect every input
{
"network": "eip155:8453",
"tokenStandard": "ERC-20",
"to": "0x2222222222222222222222222222222222222222",
"data": "0x095ea7b30000000000000000000000001111111111111111111111111111111111111111ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"nativeValueAtomic": "0",
"expectedRecipient": "0x1111111111111111111111111111111111111111",
"maxAtomicAmount": "1000000"
}A bounded approval
Use an explicit allowance while retaining the unassessed safety state.
- Declared method
- approve(address,uint256)
- Policy flags
- 0
- Security verdict
- Not assessed
| Field | Value |
|---|---|
| Network | eip155:8453 |
| Contract | 0x2222222222222222222222222222222222222222 |
| Action | Set spender allowance |
| Recipient / spender | 0x1111111111111111111111111111111111111111 |
| Atomic amount / bool | 500000 |
| Native atomic value | 0 |
Run this scenario Input JSON Calculated report
Inspect every input
{
"network": "eip155:8453",
"tokenStandard": "ERC-20",
"to": "0x2222222222222222222222222222222222222222",
"data": "0x095ea7b30000000000000000000000001111111111111111111111111111111111111111000000000000000000000000000000000000000000000000000000000007a120",
"nativeValueAtomic": "0",
"expectedRecipient": "0x1111111111111111111111111111111111111111",
"maxAtomicAmount": "1000000"
}The same selector, an NFT
Interpret the integer as token ID 42 under declared ERC-721.
- Declared method
- approve(address,uint256)
- Policy flags
- 0
- Security verdict
- Not assessed
| Field | Value |
|---|---|
| Network | eip155:8453 |
| Contract | 0x2222222222222222222222222222222222222222 |
| Action | Approve this token ID (not a fungible-token allowance) |
| Recipient / spender | 0x1111111111111111111111111111111111111111 |
| Atomic amount / bool | 42 |
| Native atomic value | 0 |
Run this scenario Input JSON Calculated report
Inspect every input
{
"network": "eip155:8453",
"tokenStandard": "ERC-721",
"to": "0x2222222222222222222222222222222222222222",
"data": "0x095ea7b30000000000000000000000001111111111111111111111111111111111111111000000000000000000000000000000000000000000000000000000000000002a",
"nativeValueAtomic": "0",
"expectedRecipient": "0x1111111111111111111111111111111111111111",
"maxAtomicAmount": "1000000"
}A mistake worth catching
A correctly decoded call can still target a malicious contract. No flags means only that the supplied checks found no mismatch, not that signing is safe.
Use the method with your records
Decode only exact two-word transfer, approve and setApprovalForAll ABI shapes. Compare supplied recipient/spender and limit; identify broad approval and attached native value.
No chain simulation, malicious-contract detection, token identity lookup, balance inspection or safety verdict.
Read the complete method, sources and input contract. Updated 2026-09-19; by the AGI Scorecard team.