- Unhandled return values of
transfer
andtransferFrom
- Random task execution
- Tokens with more than 18 decimal points will cause issues
- Error codes of Compound’s
Comptroller.enterMarket
,Comptroller.exitMarket
are not checked - Reversed order of parameters in allowance function call
- Token approvals can be stolen in
DAOfiV1RouteraddLiquidity()
swapExactTokensForETH
checks the wrong return valueDAOfiV1Pair.deposit()
accepts deposits of zero, blocking the poolGenesisGroup.commit
overwrites previously-committed values- Purchasing and committing still possible after launch
UniswapIncentive
overflow on pre-transfer hooksBondingCurve
allows users to acquire FEI before launchTimed.isTimeEnded
returns true if the timer has not been initialized- Overflow/underflow protection
- Unchecked return value for
IWETH.transfer
call GenesisGroup.emergencyExit
remains functional after launch- ERC20 tokens with no return value will fail to transfer
- Reentrancy vulnerability in
MetaSwap.swap()
- A new malicious adapter can access users’ tokens
- Owner can front-run traders by updating adapters
- Users can collect interest from
SavingsContract
by only staking mTokens momentarily - Oracle updates can be manipulated to perform atomic front-running attack
- Certain functions lack input validation routines
- Remove
Loihi
methods that can be used as backdoors by the administrator - A reverting fallback function will lock up all payouts
Saferagequit
makes you lose funds- Creating proposal is not trustless
- Emergency processing can be blocked
- Token Overflow might result in system halt or loss of funds
- Whitelisted tokens limit
- Summoner can steal funds using bailout
- Sponsorship front-running
- Delegate assignment front-running
- Queued transactions cannot be canceled
- Proposal transactions can be executed separately and block
Proposal.execute
call - Proposals could allow
Timelock.admin
takeover - Reentrancy and untrusted contract call in
mintMultiple
- Lack of return value checks can lead to unexpected results
- External calls in loop can lead to denial of service
- OUSD allows users to transfer more tokens than expected
- OUSD total supply can be arbitrary, even smaller than user balances
- Flash minting can be used to redeem
fyDAI
- Lack of
chainID
validation allows signatures to be re-used across forks - Lack of a contract existence check allows token theft
- No incentive for bidders to vote earlier
- Lack of access control separation is risky
- Lack of two-step procedure for critical operations leaves them error-prone
- Initialization functions can be front-run
- Missing validation of
owner
argument could indefinitely lock owner role - Incorrect comparison enables swapping and token draining at no cost
- Unbound loop enables denial of service
- Front-running pool’s initialization can lead to draining of liquidity provider’s initial deposits
- Swapping on zero liquidity allows for control of the pool’s price
- Failed transfer may be overlooked due to lack of contract existence check
- Use of undefined behavior in equality check
- Assimilators’ balance functions return raw values
- System always assumes USDC is equivalent to USD
- Assimilators use a deprecated Chainlink API
cancelOrdersUpTo
can be used to permanently block future orders- Specification-Code mismatch for
AssetProxyOwner
timelock period - Unclear documentation on how order filling can fail
- Market makers have a reduced cost for performing front-running attacks
setSignatureValidatorApproval
race condition may be exploitable- Batch processing of transaction execution and order matching may lead to exchange griefing
- Zero fee orders are possible if a user performs transactions with a zero gas price
- Calls to
setParams
may set invalid values and produce unexpected behavior in the staking contracts - Improper Supply Cap Limitation Enforcement
- Improper Storage Management of Open Loan Accounts
- Contract Owner Can Arbitrarily Change Minting Fees and Interest Rates
- Inadequate Proxy Implementation Preventing Contract Upgrades
- Blacklisting Bypass via
transferFrom()
Function - Wrong Order of Operations Leads to Exponentiation of
rewardPerTokenStored
- Staking Before Initial notifyRewardAmount Can Lead to Disproportionate Rewards
- External Call Reverts if Period Has Not Elapsed
- Gap Between Periods Can Lead to Erroneous Rewards
- Malicious Users Can DOS/Hijack Requests From Chainlinked Contracts
- Lack of event emission after sensitive actions
- Functions with unexpected side-effects
- Mooniswap pairs cannot be unpaused
- Attackers can prevent honest users from performing an instant withdraw from the Wallet contract
- Not using upgrade safe contracts in
FsToken
inheritance - Unchecked output of the ECDSA recover function
- Adding new variables to multi-level inherited upgradeable contracts may break storage layout
- Unsafe division in
rdivide
andwdivide
functions - Incorrect
safeApprove
usage - ETH could get trapped in the protocol
- Use of transfer might render ETH impossible to withdraw
- Not following the Checks-Effects-Interactions pattern
- Updating the Governance registry and Guardian addresses emits no events
- The quorum requirement can be trivially bypassed with sybil accounts
- Inconsistently checking initialization
- Voting period and quorum can be set to zero
- Some state variables are not set during initialize
- Expired and/or paused options can still be traded
- ERC20 transfers can misbehave
- Incorrect event emission
- Anyone can liquidate on behalf of another account
- Orders cannot be cancelled
- Re-entrancy possibilities
- Governance parameter changes should not be instant
- Votes can be duplicated