Skip to content
high Token Standards SWC-134 CWE-682

Fee-on-Transfer / Rebasing Token Mis-Accounting

SAFE-0107 Token Standards Checked automatically by the scanner
1

What goes wrong

The contract credits the *requested* transferFrom amount rather than the *actual* balance delta received. With a fee-on-transfer or rebasing token the contract receives less than it records, so later withdrawals overdraw the pool and the last users cannot exit.

2

The vulnerable pattern

proof of concept — how it is exploited
// token takes a 2% transfer fee
// deposit(1000): contract receives 980 but credits 1000
// enough users do this and the pool is 2% short -> final withdraw reverts.
3

How to fix it

the pattern that is safe
uint256 before = token.balanceOf(address(this));
token.safeTransferFrom(msg.sender, address(this), amount);
uint256 received = token.balanceOf(address(this)) - before;
balances[msg.sender] += received;   // credit what actually arrived
◆
Credit balance deltas, not the passed amount.
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-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
← PreviousSwap Deadline Set to block.timestamp
Check your own contract for this

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