LockeERC20.sol: Frontrun attack on approve()

Handle itsmeSTYJ Vulnerability details Impact It is possible to frontrun the standard ERC20 token approve function. Proof of Concept Read this for more info. Recommended Mitigation Steps Either require that allowance is 0 before approve can be called or use increase / decrease allowance e.g...

Bonding doesn't work with fee-on transfer tokens

Handle cmichel Vulnerability details Certain ERC20 tokens make modifications to their ERC20's transfer or balanceOf functions. One type of these tokens is deflationary tokens that charge a certain fee for every transfer or transferFrom. Impact The Bonding.bond function will revert in the...

ERC20.transfer return value is ignored

Handle pants Vulnerability details ERC20 transfer and transferFrom return values are ignored. There is no whitelist, therefore users can use ERC20 tokens that transfer/transferFrom returns False instead of revert. for example: YaxisVoteProxy.sol line 55 MetaVault.sol line 579 MockPickleJar.sol li...

NestedFactory: Ensure zero msg.value if transferring from user and inputToken is not ETH

Handle GreyArt Vulnerability details Impact A user that mistakenly calls either create or addToken with WETH or another ERC20 as the input token, but includes native ETH with the function call will have his native ETH permanently locked in the contract. Recommended Mitigation Steps It is best to...

Tokens with fee on transfer are not supported

Handle WatchPug Vulnerability details There are ERC20 tokens that charge fee for every transfer or transferFrom, E.g Vader token. In the current implementation, BasePoolV2.solmint assumes that the received amount is the same as the transfer amount, and uses it to calculate liquidity units. functi...

Zap contract's redeem() function doesn't check which token the user wants to receive

Handle Ruhum Vulnerability details Impact In the redeem function, the user can pass a token address. That's the token they receive in return for the ibbtc they give back. Because of missing address checks the user can provide any possible ERC20 token here without the function reverting. Although...

safe erc20

Handle pauliax Vulnerability details Impact Contracts e.g. InvestorDistribution, AirdropDistribution, Vesting have declared to use safe ERC20 library: using SafeERC20 for IERC20; However, when actually making the approvals or transfers, they make no use of this library and rely on simple standard...

ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter should checked for success. Some functions perform ERC20 transfers without checking for the return value: BasicSale.processWithdrawal...

Unsafe token transfer

Handle WatchPug Vulnerability details Calling ERC20.transfer without handling the returned value is unsafe. function processWithdrawal uint era, uint day, address member private returns uint value uint memberUnits = mapEraDayMemberUnitseradaymember; // Get Member Units if memberUnits == 0 value =...

Unchecked transferFrom call in Vesting

Handle loop Vulnerability details Vesting.sol makes use of the safeERC20 library to make transfer calls on the vestingToken as vestingToken does not seem to be a predetermined ERC20 token. There is however a transferFrom call on vestingToken which does not make use of the safeERC20 version. Impac...

Contract BasicSale is missing an approve(address(vestLock), 2**256-1) call

Handle Reigada Vulnerability details Impact As we can see in the contracts AirdropDistribution and InvestorDistribution, they both have the following approve call: mainToken.approveaddressvestLock, 2256-1; This is necessary because both contracts transfer tokens to the vesting contract by calling...

Slingshot: Incorrect initial balance fetched for native token in executeTrades()

Handle hickuphh3 Vulnerability details Impact The executioner contract only supports ERC20ERC20 token trades. Native token swaps are supported by either wrapping / unwrapping the ERC20 wrapped native token before / after the trades respectively. When exchanging from the native token, the wrapping...

approvalHandler.transferFrom(..) isn't safe

Handle pants Vulnerability details approvalHandler can be set by the admin to any ERC20 token. A popular possible token is USDT, for example, which the admin can use. Then ignoring transferFrom return value isn't safe - since USDT transferFrom doesn't revert on failure but returns false instead...

The design of wibBTC is not fully compatible with the current Curve StableSwap pool

Handle WatchPug Vulnerability details Per the documentation, wibBTC is designed for a Curve StableSwap pool. However, the design of wibBTC makes the balances change dynamically and automatically. This is unusual for an ERC20 token, and it's not fully compatible with the current Curve StableSwap...

Inconsistent ERC20 function may lead to DOS and unexpected behaviour

Handle gzeon Vulnerability details Impact There are 2 important yet similar concept in this wrapper contract, namely "SHARE" and "BALANCE". SHARE equivalent to the number of underlying ibbtc and is stored in balance as the native value, while BALANCE is SHAREpricepershare and is the return value ...

ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter should checked for success. See VestedRewardPool.claim which performs ERC20 transfers without checking for the return value. Impact As the trusted moc...

DutchAuctionLiquidator.settleLiquidation() Does Not Operate On Non-Standard ERC20 Tokens

Handle leastwood Vulnerability details Impact settleLiquidation does not validate the return value of an ERC20 transfer call. As a result, if the call to transfer does not revert but instead returns a boolean or void value, it may be possible that a user liquidates a user's position but does not...

Unhandled return values of transfer

Handle WatchPug Vulnerability details ERC20 implementations are not always consistent. Some implementations of transfer could return ‘false’ on failure instead of reverting. It is safer to wrap such calls into require statements to these failures. Unsafe transfer calls were found in the following...

Unchecked ERC20 transfer calls

Handle loop Vulnerability details ERC20 transfer and transferFrom calls normally return true on a succesful transfer. In DutchAuctionLiquidator the call asset.transfermsg.sender, collateral; is made. asset refers to whichever ERC20 asset is used for the vault of that auction. If asset is an ERC20...

Arbitrary contract call allows attackers to steal ERC20 from users' wallets

Handle WatchPug Vulnerability details function fillZrxQuote IERC20 zrxBuyTokenAddress, address payable zrxTo, bytes calldata zrxData, uint256 ethAmount internal returns uint256, uint256 uint256 originalERC20Balance = 0; if!signifiesETHOrZeroaddresszrxBuyTokenAddress originalERC20Balance =...