Deriving the price with balanceOf() is dangerous

Lines of code Vulnerability details Impact Deriving the price with balanceOf is dangerous as it can easily be manipulated by direct transfers. Proof of Concept In the getAssetDistributionData function, the asset lying in the LRTDepositPool is retrieved using balanceOfaddressthis:...

Incorrect calculation of totalSupply(), balanceOf() in rUSDY.sol if the rate is unlinked from $1

Lines of code Vulnerability details Impact In rUSDY.sol, the functions totalSupply, balanceOf are calculated. totalSupply : function totalSupply public view returns uint256 return totalShares oracle.getPrice / 1e18 BPSDENOMINATOR; balanceOf : function balanceOfaddress account public view returns...

balanceOf method can be manipulate to liquidated vault

Lines of code Vulnerability details Impact Deriving price from balanceOf can be manipulated to liquidate vault see example Attacker can provide ERC20 token to the vaultAsset and mint vault shares. The deposited tokens will then be withdrawn with having same shares in the vault. The shares then wi...

Tokens with multiple addresses can be stolen due to reliance on balanceOf()

Lines of code Vulnerability details Impact Some ERC20 tokens have multiple valid contract addresses that serve as entrypoints for manipulating the same underlying storage such as Synthetix tokens like SNX and sBTC and the TUSD stablecoin. The accrueUser function holds all rewards for all pools,...

The ethlbrStakePool, which is used in LOC 155 in EUSDMiningIncentives.sol, has no function balanceOf()

Lines of code Vulnerability details Impact The EUSDMiningIncentives.sol in LOC 155 uint256 userStaked = IEUSDethlbrStakePool.balanceOfuser; calls balanceOf function of ethlbrStakePool. By asking one of the sponsors, the address of this pool was given as 0x857CC243b8494e13BdbAde27C25ef61c2e500fda...

[NAZ-M2] ReaperVaultERC4626.sol doesn't fully conform to EIP4626 implementation

Lines of code Vulnerability details Impact Specifically the two function maxDeposit && maxMint don't fully conform to EIP4626 implementation. Proof of Concept Looking at the following from EIP4626: This assumes that the user has infinite assets, i.e. MUST NOT rely on balanceOf of asset. This goes...

Not checking amount of received ERC20 tokens

Lines of code Vulnerability details Description There are ERC20 tokens, which apply intenal fee on transfers such as USDT, so that amount of received tokens could differ from requested amount. There is a line where contract receives facilityFee as an amount of tokens. The same variable is used on...

Lack of check for fee tokens

Lines of code Vulnerability details Impact The lendToProject function will receive the cost as an argument. However, some tokens will charge a fee, which might cause the balance of the token in the contract mismatch the cost. File: contracts/Project.sol /// @inheritdoc IProject function...

WETH.sol computes the wrong totalSupply()

Lines of code Vulnerability details Impact Affected code: WETH.sol is almost copied from the infamous WETH contract that lives in mainnet. This contract is supposed to receive the native currency of the blockchain for example ETH and wrap it into a tokenized, ERC-20 form. This contract computes t...

VoterProxy.claimVeAsset() and VeAssetDepositor._lockVeAsset() both spend veAsset.balanceOf(staker) for different purposes

Lines of code Vulnerability details Impact Each of the functions VeAssetDepositor.lockVeAsset and VoterProxy.claimVeAsset will use the entire balance of the VoterProxy for different purposes. In VeAssetDepositor.lockVeAsset the balance is locked into the VoterEscrow contract and cannot be...

Exchange Rate Race Condition

Lines of code Vulnerability details GAX-01M: Exchange Rate Race Condition | File | Lines | Type ---|---|--- gALCX.sol | L69-L81 | Improper State Assumption Description The gALCX contains a race condition whereby whenever the contract has no stakes such as when the contract is first deployed the...

Staking Zap add liquidity can be denied

Handle cmichel Vulnerability details The NFTXStakingZap.addLiquidity721WETH function verifies if the contract indeed received the expected amount of vault tokens of balance = count BASE by checking: function addLiquidity721WETH uint256 vaultId, uint256 memory ids, uint256 minWethIn, uint256 wethI...

Wrong implementation of NoYield.sol#emergencyWithdraw()

Handle WatchPug Vulnerability details function emergencyWithdrawaddress asset, address payable wallet external onlyOwner returns uint256 received requirewallet != address0, 'cant burn'; uint256 amount = IERC20asset.balanceOfaddressthis; IERC20asset.safeTransferwallet, received; received = amount;...

function timeLockERC20 does not check the return value of transferFrom

Handle paulius.eth Vulnerability details Impact function timeLockERC20 uses transferFrom for erc20 transfers, however, it does not check the return value. According to the ERC20 standard, this function should return a boolean to indicate success. Not checking that may not work with some tokens...

erc1155 are redeemed one by one

Handle paulius.eth Vulnerability details Impact When depositing erc1155s amounts array is used and tokens are sent in bulk safeBatchTransferFrom, however, when redeeming it iterates over the amount and redeems it one by one. It is not convenient when the amount is large. Let's say I deposited 100...