# Limited support to a specific subset of ERC20 tokens

Buffer contracts call ERC20 transfer/transferFrom/approve without handling non-standard return semantics, so USDT-style tokens revert and ZRX-style false returns go undetected.

- Payout: Contest reward
- Severity: medium
- Program: Buffer
- Credited: m_Rassska
- Disclosed: 2022-11-11
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-buffer-judging/issues/73
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-buffer%3AM-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** Solidity contracts (BufferRouter, BufferBinaryOptions, BufferBinaryPool) ERC20 transfer calls
**Root cause:** ERC20 transfer/transferFrom/approve return values are either ignored or required to be boolean true, assuming all tokens revert on failure and return true on success.
**Steps:**
1. Identify ERC20 calls in BufferRouter.sol L86, L331, L335, L361; BufferBinaryOptions.sol L141, L477 (return value unchecked)
2. Identify calls in BufferBinaryPool.sol L162, L205, L241, L323 (require boolean true)
3. For a ZRX-style token returning false on failure, unchecked calls let failed transfers pass silently
4. For USDT-style token returning no value, checked calls revert on successful transfers
5. Fix by using SafeERC20 or low-level call with returndata length and code.length checks
**How found:** Code review of ERC20 interaction points against the contest's 'any ERC20 supported' claim, comparing USDT (no return) and ZRX (boolean return) token implementations.
**Insight:** When a protocol claims arbitrary ERC20 support, audit every transfer/transferFrom/approve site for both missing return checks and over-strict boolean checks; non-standard tokens like USDT and ZRX expose both failure modes.