Crypto Training
Adversarial Token Integration: Why ERC-20 Compatibility Is Not a Security Model
Most token integrations assume transfer amount fidelity and standard return behavior. Production incidents show the opposite: token behavior is adversarial from the integrator’s perspective.
“Supports ERC-20” is not enough to conclude “safe to integrate.”
The standard surface is broad. Real token behavior diverges in ways that break lending, swaps, and vault accounting.
flowchart TD
A[Protocol expects amount X] --> B[Token applies fee or cap]
B --> C[Protocol receives amount Y]
C --> D[Protocol still books X]
D --> E[Insolvency / unfair accounting]
Token behavior classes you must test#
| Class | Example behavior | Common breakage |
|---|---|---|
| Fee-on-transfer | recipient gets less than sent | over-crediting |
| Rebasing | balances drift over time | stale cache logic |
| Blocklist/pause | selected transfers fail | liquidation dead paths |
| Non-standard returns | missing/false/odd return data | silent failure handling |
Balance-delta settlement pattern#
function _pullExactOrRevert(IERC20 token, address from, uint256 expected) internal {
uint256 beforeBal = token.balanceOf(address(this));
SafeERC20.safeTransferFrom(token, from, address(this), expected);
uint256 afterBal = token.balanceOf(address(this));
uint256 received = afterBal - beforeBal;
require(received == expected, "non-fidelity token");
}
When strict equality is too restrictive, encode explicit tolerated ranges and reflect that in accounting.
Approvals and permit paths#
sequenceDiagram
actor User
participant D as DApp
participant T as Token
User->>D: sign permit
D->>T: submit permit
D->>T: transferFrom
Note over D,T: If permit silently fails, transfer path may behave unexpectedly
Treat permit as “may fail silently” unless token behavior is proven.
Integration policy contract#
A practical design is to maintain token risk profiles and route actions accordingly.
| Profile | Allowed actions |
|---|---|
| Strict fidelity | lending collateral, vault base asset |
| Drift-tolerant | isolated pools with conservative caps |
| Restricted | no collateral role, only swap route |
Audit checklist#
- Are all token transfers settled by measured delta?
- Are liquidation and repay paths resilient to transfer refusal?
- Are approvals reset/managed safely for non-standard tokens?
- Are integration assumptions documented per token class?