Missing SafeERC20 / Non-Standard Token Handling

SAFE-0051 Token Standards Checked automatically by the scanner

What goes wrong

Direct ERC-20 calls assume standard behavior; fee-on-transfer, rebasing, no-return, and reverting-vs-false tokens break accounting and can be exploited.

How to fix it

the pattern that is safe

using SafeERC20 for IERC20;
uint256 before = token.balanceOf(address(this));
token.safeTransferFrom(msg.sender, address(this), amt);
uint256 received = token.balanceOf(address(this)) - before; // fee-on-transfer safe

◆

Use SafeERC20 and measure actual received amounts.

Related vulnerabilities in Token Standards

SAFE-0053Unsafe / Unprotected Minting critical · 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-0208Non-Standard ERC20 Return Value Not Handled 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

← PreviousERC-20 Approval Race Condition Next →Fee-on-Transfer / Rebasing Token Accounting Mismatch

Check your own contract for this

The SaferICO scanner runs 201 detectors over your Solidity source, SAFE-0051 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