Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Token integrations fail when accounting assumes the requested transfer amount always equals the balance change. Fee-on-transfer tokens deduct value during transfer. Rebasing tokens can change account balances without an ordinary transfer. These are different behaviors, but either can invalidate a protocol that records nominal amounts as assets received or owed.
The ERC-20 interface defines transfer functions and events, but real tokens add fees, rebases, hooks, blocklists, pauses, and unusual return behavior. If a vault credits 100 units after transferFrom while its balance rises by only 98, internal liabilities exceed assets. Whether that mismatch is exploitable depends on withdrawal and share pricing: it may create an immediate extraction path or distribute a deficit to later users.
Outgoing transfers also need review. A recipient may receive less than the protocol debits, or the token may charge the sender above the nominal amount. Rebases can make cached balances stale in either direction. Share-based accounting can accommodate some rebases, but only if every conversion and liability uses the same model.
Balancer's protocol-authored 2020 incident update records that deflationary assets created unintended behavior and that the team had underestimated the feasibility of a single-transaction pool drain. The lesson is broader than one token: adversarial tests must cover supported behavior, not only the interface signature.
For every inbound and outbound token movement, compare the nominal amount, sender delta, recipient delta, and accounting update. Trace those values through deposits, swaps, repayments, liquidations, fee collection, withdrawals, and emergency recovery.
Test transfer fees from zero through extreme values, fees that change over time, positive and negative rebases, missing or false return values, paused transfers, blocklisted recipients, callbacks, and tokens whose sender loses more than the recipient gains. Include repeated deposits and withdrawals to expose cumulative drift.
Define support explicitly. If arbitrary tokens are accepted, a simple allowlist is not enough unless governance reviews upgrades and behavior changes in the token contracts.
For inbound fee-on-transfer tokens, credit a measured balance increase when that measurement is sound. Pass the measured amount into downstream accounting rather than the user's requested input. This does not by itself handle a rebase or callback occurring during the operation, and it may be incompatible with protocols that require exact amounts.
OpenZeppelin's SafeERC20 documentation explains that the library normalizes Boolean and no-return transfer behavior. SafeERC20 does not guarantee how many tokens arrived and does not make rebasing accounting correct.
Reject unsupported token types, or implement and test a complete accounting policy for each supported behavior. Add minimum-output checks for users and reconciliation invariants between internal liabilities and token holdings.
Repository analysis can flag nominal crediting, unchecked returns, and cached balances. It cannot infer every token's runtime behavior from IERC20, predict upgradeable-token changes, or prove solvency without configured assets and stateful tests.
Is balance-after minus balance-before always safe?
No. It is useful for ordinary inbound transfer fees, but callbacks, rebases, and sender-charged fees may require a broader accounting design.
Does SafeERC20 support fee-on-transfer tokens automatically?
It handles call success and return conventions. It does not measure received value or repair protocol accounting.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Assess smart contract admin powers, upgrade authority, key custody, delays, caps, and the limits of source-only centralization analysis.
Review smart contract liveness failures caused by gas growth, external-call reverts, griefing, and unrecoverable state.
Understand first-depositor and donation attacks against tokenized vaults, rounding conditions, tests, and mitigation tradeoffs.
Understand transaction-ordering risk, sandwich attacks, the conditions that make them profitable, and practical review and mitigation techniques.
Learn how weak swap bounds expose users and vaults to adverse execution, how to review integrations, and where minimum outputs and deadlines fall short.