Skip to content
high Token Standards SWC-104 CWE-252

Non-Standard ERC20 Return Value Not Handled

SAFE-0208 Token Standards Checked automatically by the scanner
1

What goes wrong

transfer/transferFrom/approve are called on a plain IERC20 and the boolean result is neither checked nor routed through SafeERC20. Tokens that return false on failure (or nothing at all, like USDT) break the contract's assumptions — a failed transfer looks like success, or a compliant require reverts on USDT.

2

The vulnerable pattern

proof of concept — how it is exploited
// token.transfer(user, amt); // USDT returns no bool -> some compilers
// treat as success even if it failed; or require(token.transfer(...))
// reverts against USDT which returns void. Either way funds/logic break.
3

How to fix it

the pattern that is safe
using SafeERC20 for IERC20;
token.safeTransfer(to, amount);
token.safeTransferFrom(from, to, amount);
◆
Use OpenZeppelin SafeERC20 for all token movements.
4

Related vulnerabilities in Token Standards

SAFE-0053Unsafe / Unprotected Minting critical · Token Standards SAFE-0051Missing SafeERC20 / Non-Standard Token Handling high · Token Standards SAFE-0052Fee-on-Transfer / Rebasing Token Accounting Mismatch high · Token Standards SAFE-0055Burn Authorization / Burn-From Missing Checks high · Token Standards SAFE-0107Fee-on-Transfer / Rebasing Token Mis-Accounting high · Token Standards SAFE-0050ERC-20 Approval Race Condition medium · Token Standards SAFE-0054ERC-721/1155 Missing Receiver Validation (Safe Transfer) medium · Token Standards SAFE-0056EIP-2612 Permit Misuse / Front-Running medium · Token Standards
← Previouspermit() Front-Running Griefing (DoS on Deposit)
Check your own contract for this

The SaferICO scanner runs 201 detectors over your Solidity source, SAFE-0208 among them. Paste an address or the source itself — a small per-scan fee, shown before you sign, or unlimited on any plan.

Run the scanner See how it is attacked Read the docs