token-compatibility

# Token compatibility detection ## When this applies - Any ERC-20 integration: lending, AMM, vault, staking, bridge - Balance-based accounting (`balanceOf(this) - prevBalance`) - Decimal scaling between tokens - Cross-chain bridges with various token implementations - Aggregators / routers handling user-supplied tokens ## Detection patterns ### Fee-on-transfer assumed away (HIGH) ```solidity uint256 before = token.balanceOf(address(this)); token.transferFrom(user, address(this), amount); shares = amount * X / Y; // ← uses `amount`, not actual received ``` Tokens like USDT (when fee enabled), SafeMoon, etc. take a fee. Use `balanceOf(this) - before` as the effective amount. ### Rebasing token accounting (HIGH) stETH, aUSDC, AMPL — balances change without `transfer`. Vaults assuming `balanceOf` ≡ deposit will mis-account. Either don't accept rebasing tokens, or use share-based accounting (wstETH-style wrappers). ### Non-standard return values — USDT (HIGH) USDT's `transfer` does NOT return bool (pre-`SafeERC20` use breaks): ```solidity bool ok = IERC20(usdt).transfer(to, amt); // ← reverts: ABI mismatch ``` Use OZ `SafeERC20` which uses low-level call + return-data inspection. ### Blacklistable tokens (HIGH) USDC, USDT can blacklist addresses. If a user gets blacklisted after deposit, the protocol may be unable to return funds → other users' funds stuck if pooled. ### Pausable tokens (HIGH) USDC, USDT can pause transfers. Protocol functions that must succeed (l...