Standards

Non-Standard ERC-20

A non-standard ERC-20 is a token that behaves differently from common ERC-20 assumptions, such as missing return values, fees, rebases, pauses, blacklists, or unusual decimals.

The token looks like an ERC-20, but one of its behaviors does not match what your contract expects.

Non-Standard ERC-20 Explained in Detail

A non-standard ERC-20 is an ERC-20-like token that does not match the assumptions an integration makes. The token may omit return values, return false, revert on approval patterns, charge transfer fees, rebase balances, pause transfers, blacklist accounts, or use unexpected decimals.

The risk is not that every unusual token is malicious. The risk is that the integrating contract treats all token behavior as uniform.

Smart contract example

require(token.transferFrom(msg.sender, address(this), amount));
credits[msg.sender] += amount;

This can fail with tokens that do not return a boolean. It can also credit too much if the token is a fee-on-transfer token.

Non-Standard ERC-20 in Auditing

Token integrations are external calls plus economic assumptions. Auditors review whether the protocol supports a strict allowlist of assets, rejects incompatible behavior, or handles each behavior deliberately.

Using SafeERC20 addresses some call-result issues, but it does not solve fee accounting, rebases, blacklists, transfer hooks, or decimal normalization.

Red flags in code

  • The protocol accepts arbitrary user-selected tokens.

  • Transfer success is assumed without a wrapper or explicit return-value handling.

  • Deposits credit requested amounts instead of actual received amounts.

  • The code assumes every token has 18 decimals.

  • Pause, blacklist, max-transfer, or approval quirks are not considered.

How to test or review it

  • Test with mocks for no-return, false-return, fee-on-transfer, rebasing, paused, and blacklisted tokens.

  • Check whether unsupported tokens are blocked at onboarding.

  • Review unchecked return value findings together with accounting behavior.

  • Verify balance-delta accounting where exact receipt matters.

  • Document which token behaviors are supported, unsupported, or accepted as an integration risk.

Sources