attacker can DOS or manipulate rounds deposits count by depositing 0 ETH with depositETHIntoMultipleRounds()

attacker can DOS and LOCK users tokens because function depositETHIntoMultipleRounds() doesn't check MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND

function claimable() in TrufVesting may return value bigger than maxClaimable

function _extendLock() allows extending the expired lockups

auction settlements will revert because function `_computeTotalRewards()` calculates inconsistent totalReward and reward list

function _addFounders() in Token contract doesn't support more than 99 funder with ownershipPct and also it doesn't support less than 1% pct

attacker can force pause the Auctions

DOS and griefing the sequencer by bridging large data deposits from L1 to L2 with low gas

deploying contracts with forceDeployOnAddress will break contracts when callConstructor is false

Attacker can manipulate loan token price per share in the Pool and users would lose funds due to division error

fund loss because calculated Interest would be 0 in getCurrentState() due to division error

middle level admins can take control of the tree after unlinking it because function unlinkTopHatFromTree() doesn't reset the value of the linkedTreeRequests[]

middle level admins can steal child trees because function unlinkTopHatFromTree() is callable by them

function reconcileSignerCount() set higher value for safe's threshold which can cause safe's transaction execution to revert always

attacker can perform malicious transactions in the safe because reentrancy is not implemented correctly in the checkTransaction() and checkAfterExecution() function in HSG

Unbound recursive function call can use unlimited gas and break hats operation

unbound loops in the code which can cause high gas usage and break the protocol and fund would be locked

Protection sellers can bypass withdrawal delay mechanism and avoid losing funds when loans are defaulted by creating withdrawal request in each cycle

function lockCapital() doesn't filter the expired protections first and code may lock more funds than required and expired defaulted protections may funded

attacker can cause claims of the atomicBounty and TieredPercentageBounty to revert if one of the whitelisted tokens revert when transferring 0 amount

attacker can cause calls to claim function of the all Bounty types (except Ongoing) to revert because code would try to transfer refunded NFT deposits

attacker can cause claim calls to bounty type TieredPercentageBounty to revert always by refunding his deposit after closeCompetition() get called

malicious winner in the TieredPercentageBounty can steal other winner funds by inflating contract token balance right before claiming and then refunding his deposit

Function refundDeposit() in BountyCore doesn't decrease deposit items and it can cause deposits to reach to the limit even so they are refunded

Attacker can perform DOS on any bounty contract by over calling fundBountyToken() with different tokens

Attacker can perform griefing and DOS by deposit and refunding NFTs into the bounty

Wrong fund distribution when users refunds deposits between claims and deposits set as refunded while code refund them partially

call to setPayoutSchedule() and setPayoutScheduleFixed() would revert when bounty's issuer try to resize winners to fewer tiers

when issuer set new winner by calling setTierWinner() code should reset invoice and supporting documents for that tier

[High] Function PreCheckWithdrawals() assumes that all the messages in the LegacyMessagePasserAddr are from L2CrossDomainMessanger and attacker can break migration script by calling OVM_L2ToL1MessagePasser.passMessageToL1() before migration

[High] Attacker can block other users L2 to L1 withdrawals in the OptimisimPortal and lock their funds by proving it to the wrong output index if sequencer send invalid L2 output root(future L2 blocks states) for that index

[Medium] Challenger shouldn't be able to delete finalized L2 outputs

[High] Function MigrateWithdrawal() may set gas limit so high for old withdrawals when migrating them by mistake and they can't be relayed in the L1 and users funds would be lost

BackingManager: rTokens might not be redeemable when protocol is paused due to missing token allowance

attacker can prevent vesting for a very long time

attacker can steal RToken holders funds by performing reentrancy attack during redeem() function token transfers

early user can call issue() and then melt() to increase basketsNeeded to supply ratio to its maximum value and then melt() won't work and contract contract features like issue() won't work

attacker can make stakeRate to be 1 in the StRSR contract and users depositing tokens can lose funds because of the big rounding error

Function processEpoch() in PublicVault would revert when most of the users withdraws their funds because of the underflow for new yIntercept calculation

Attacker can take loan for Victim

Improper validations in Clearinghouse. possible to lock collateral NFT in contract.

Deadlock in valuts with underlying token with less then 18 decimals

Function withdraw() and redeem() in ERC4626RouterBase would revert always because they have unnecessary allowance setting

WithdrawProxy allows redeem() to be called before withdraw reserves are transferred in

For a public vault, minimum deposit requirement that is enforced by `ERC4626Cloned.deposit` function can be bypassed by `ERC4626Cloned.mint` function or vice versa when share price does not equal one

Users are unable to mint shares from a public vault using `AstariaRouter` contract when share price is bigger than one

Lack of support for fee-on-transfer token

[High] attacker can drain or theft any user who gave spending allowance for PerpDepository contract by calling rebalanceLite()

Stealing fund by applying reentrancy attack on `removeCollateral`, `startLiquidationAuction`, and `purchaseLiquidationAuctionNFT`

`PaprController` pays swap fee in `buyAndReduceDebt`, not user

user fund loss because function purchaseLiquidationAuctionNFT() take extra liquidation penalty when user's last collateral is liquidated, (set wrong value for maxDebtCached when isLastCollateral is true)

Disabled NFT collateral should not be used to mint debt

Inflation of ggAVAX share price by first depositor

Hijacking of node operators minipool causes loss of staked funds

node operator is getting slashed for full duration even though rewards are distributed based on a 14 day cycle

AVAX Assigned High Water is updated incorrectly

Division by zero error can block RewardsPool#startRewardCycle if all multisig wallet are disabled.

Users may not be able to redeem their shares due to underflow

maxWithdraw() and maxRedeem() doesn't return correct value which can make other contracts fail while working with protocol

wrong reward distribution between early and late depositors because of the late syncRewards() call in the cycle, syncReward() logic should be executed in each withdraw or deposits (without reverting)

any duration can be passed by node operator

Cancellation of minipool may skip MinipoolCancelMoratoriumSeconds checking if it was cancelled before

Functions cancelMinipool() doesn't reset the value of the RewardsStartTime for user when user's minipoolcount is zero

NodeOp funds may be trapped by a invalid state transition

Coding logic of the contract upgrading renders upgrading contracts impractical

Liquidity providers may lose funds when adding liquidity

First depositor can break minting of shares

Rounding error in buyQuote might result in free tokens

it's possible to swap NFT token ids without fee and also attacker can wrap unwrap all the NFT token balance of the Pair contract and steal their air drops for those token ids

griefing / blocking / delaying users to withdraw

`PrePOMarket.setFinalLongPayout()` shouldn't be called twice.

Malicious user can steal all assets in BondNFT

reentrancy attack during mint() function in Position contract which can lead to removing of the other user's limit orders or stealing contract funds because initId is set low value

GovNFT: maxBridge has no effect

one can become referral of hash 0x0 and because all users default referral hash is 0x0 so he would become all users referral by default and earn a lot of fees while users didn't approve it

distribute() won't update epoch[tigAsset] when totalShares[tigAsset]==0 which can cause later created bond for this tigAsset to have wrong mint epoch

`_handleDeposit` and `_handleWithdraw` do not account for tokens with decimals higher than 18

Governance NFT holder, whose NFT was minted before `Trading._handleOpenFees` function is called, can lose deserved rewards after `Trading._handleOpenFees` function is called

Interest rates are incorrect on Liquidation

Anyone can prevent themselves from being liquidated as long as they hold one of the supported NFTs

Data corruption in NFTFloorOracle; Denial of Service

safeTransfer is not implemented correctly

New BAKC Owner Can Steal ApeCoin

NTokenMoonBirds Reserve Pool Cannot Receive Airdrops

user collateral NFT open auctions would be sold as min price immediately next times user health factor gets below the liquidation threshold, protocol should check health factor and set auctionValidityTime value anytime an valid action happen to user accou

Centralization risk: admin can with rug the project by removing asset and price manipulation on oracle.

Malicious Users Can Drain The Assets Of Auto Compound Vault

Underlying assets stealing in `AutoPxGmx` and `AutoPxGlp` via share price manipulation

fee loss in AutoPxGmx and AutoPxGlp and reward loss in AutoPxGlp by calling PirexRewards.claim(pxGmx/pxGpl, AutoPx*) directly which transfers rewards to AutoPx* pool without compound logic get executed and fee calculation logic and pxGmx wouldn't be exe

Assets may be lost when calling unprotected `AutoPxGlp::compound` function

Deposit Feature Of The Vault Will Break If Update To A New Platform

broken logic in configureGmxState() of PirexGmx contract because it doesn't properly call safeApprove() for stakedGmx address

_calculateRewards() in PirexGmx don't handle reward calculation properly, and it would revert when totalSupply() is zero which will cause claimRewards() to revert if one of 4 rewardTracker's totalSupply was zero

Reward tokens mismanagement can cause users losing rewards

Incorrect accounting in SyndicateRewardsProcessor results in any LP token holder being able to steal other LP tokens holder's ETH from the fees and MEV vault.

Sender transferring GiantMevAndFeesPool tokens can afterward experience pool DOS and orphaning of future rewards

possible reentrancy and fund theft in withdrawDETH() of GiantSavETHVaultPool because there is no whitelist check for user provided Vaults and there is no reentrancy defnece

fund lose in function bringUnusedETHBackIntoGiantPool() of GiantSavETHVaultPool ETH gets back to giant pool but the value of idleETH don't increase

User lose his remaining rewards in GiantMevAndFeesPool when new deposits happen because _onDepositETH() set claimed[][] to max without transferring user remaining rewards

Giant pools can be drained due to weak vault authenticity check

Old stakers can steal deposits of new stakers in `StakingFundsVault`

withdrawETH() in GiantPoolBase don't call _distributeETHRewardsToUserForToken() or _onWithdraw() which would make users to lose their remaining rewards

Freezing of funds - Hacker can prevent users withdraws in giant pools

Withdrawing wrong LPToken from GiantPool leads to loss of funds

Users who deposit in one vault can lose all deposits and receive nothing when counterparty vault has no deposits

Depeg event can happen at incorrect price

User fund lost because they can't withdraw() their funds before epoch startTime and they have to stuck in positions that become unprofitable even when epoch is not started

`timewindow` can be changed unexpectedly that blocks users from calling `deposit` function

StakingRewards: recoverERC20() can be used as a backdoor by the owner to retrieve rewardsToken

Different Oracle issues can return outdated prices

Founders can receive less tokens that expected

Vault implementation can be destroyed leading to loss of all assets

Delegate call in `Vault#_execute` can alter Vault's ownership

Buyout Module: `redeem`ing before the update of totalSupply will make buyout's current state success

Order duration can be set to 0 by Malicious maker

Order cancellation is prone to frontrunning and is dependent on a centralized database

Putty position tokens may be minted to non ERC721 receivers

The contract serves as a flashloan pool without fee

`fee` can change without the consent of users

Malicious Token Contracts May Lead To Locking Orders

Reentrancy bug in Basket's withdraw multiple tokens function which gives attacker ability to transfer basket ownership and spend it but withdraw all the tokens out of basket

token transfers in LiquidityReserve and Staking contract don't support deflationary ERC20 tokens, and user funds can be lost if stacking token was deflationary

It's possible to perform DOS and fund lose in Stacking by transferring tokens directly to contract

User fund lose in addLiquidity() of LiquidityReserve by increasing (totalLockedValue / totalSupply()) to very large number by attacker

Tempus lend method wrongly calculates amount of iPT tokens to mint

Incorrect implementation of APWine and Tempus `redeem`

Able to mint any amount of PT

Funds may be stuck when `redeeming` for Illuminate

Illuminate PT redeeming allows for burning from other accounts

[H-05] Not minting iPTs for lenders in several lend functions

Sandwich attacks are possible as there is no slippage control option in Marketplace and in Lender yield swaps

`Lender.mint()` May Take The Illuminate PT As Input Which Will Transfer And Mint More Illuminate PT Cause an Infinite Supply

Centralisation Risk: Admin Can Change Important Variables To Steal Funds

auraBAL can be stuck into the Strategy contract

attacker can call sweepRewardToken() when `bribesProcessor==0` and reward funds will be lost because there is no check in sweepRewardToken() and _handleRewardTransfer() and _sendTokenToBribesProcessor()

`_harvest` has no slippage protection when swapping `auraBAL` for `AURA`

Badger rewards from Hidden Hand can permanently prevent Strategy from receiving bribes

Lose of funds in matchOneToManyOrders() and takeOrders() and matchOrders() because code don't check that different ids in one collection are different, so it's possible to sell one id multiple time instead of selling multiple id one time in one collection

Sellers may lose NFTs when orders is matched with `matchOrders()`

Overpayment of native ETH is not refunded to buyer

Maker buy order with no specified NFT tokenIds may get fulfilled in `matchOneToManyOrders` without receiving any NFT

Accumulated ETH fees of InfinityExchange cannot be retrieved

fund lose or griefing in all order matching functions [matchOneToOneOrders(), matchOneToManyOrders(), matchOrders(), takeMultipleOneOrders(), takeOrders()] because condition (seller != buyer ) is not checked in any of them

In execute() the amount routers pay is what user signed, but in _reconcile() the amount routers get is what nomad sends and this two amount are not necessary equal because of slippage in original domain

Router Owner Could Be Rugged By Admin

division rounding error in _handleExecuteLiquidity() and _reconcile() make routerBalances and contract fund balance to get out of sync and cause fund lose

attacker can perform griefing for process() in PromiseRouter by reverting calls to callback() in callbackAddress

in reimburseLiquidityFees() of SponserVault contract swaps tokens without slippage limit so its possible to perform sandwich attack and it create MEV

fCash of the wrong maturity and asset can be sent to wrapper address before wrapper is deployed

deposit() and mint() and _redeemInternal() in wfCashERC4626() will revert for all fcash that asset token is underlying token because they always call _mintInternal() with useUnderlying==True

The logic of _isUnderlying() in NotionalTradeModule is wrong which will cause mintFCashPosition() and redeemFCashPosition() revert on `fcash` tokens which asset token is underlying token (asset.tokenType == TokenType.NonMintable)

it's possible to initialize contract BkdLocker for multiple times by sending startBoost=0 and each time different values for other parameters

Users can claim more fees than expected if governance migrates current rewardToken again by fault.

Duplicate LP token could lead to incorrect deposits

`VE3DRewardPool` and `VE3DLocker` adds to an unbounded array which may potentially lock all rewards in the contract

Incorrectly set ```_maxTime``` to be in line with the locking ```maxTime``` of each veToken could render the ```deposit``` of this contract to be unfunctional or even freeze assets inside the contract

in notifyRewardAmount() of VE3DRewardPool and BaseRewardPool some tokes will be locked and not distributed becasue of rounding error

Unused rewards(because of totalSupply()==0 for some period) will be locked forever in VE3DRewardPool and BaseRewardPool

deposited staking tokens can be lost if rewards token info added by mistake in addReward() in VE3DRewardPool and there is no checking to ensure this would not happen (ve3Token for one reward was equal to stacking token)

User rewards stop accruing after any _writeCheckpoint calling action

temporary DOS by calling notifyRewardAmount() in Bribe/Gauge with malicious tokens

Wrong reward distribution in Bribe because deliverReward() won't set tokenRewardsPerEpoch[token][epochStart] to 0

Rewards can be locked in Bribe contract because distributing them is depend of base token reward amount and Gauge.deliverBribes() is not get called always by Voter.distribute()

Bribe.sol is not meant to handle fee-on-transfer tokens

First depositor can break minting of shares

Cannot deposit to BathToken if token is Deflationary Token (BathHouse.sol)

Strategists can take more rewards than they should using the function strategistBootyClaim().

Missing checks allow strategists to steal all fund via `tailOff`

Outstanding Amount Of A Pool Reduced Although Tokens Are Not Repaid

Wrong DOMAIN_SEPARATOR

SpeedBumpPriceGate: Excess ether did not return to the user

Verification should be leafed based and not address based

getRewards() in PermissionlessBasicPoolFactory calculate wrong reward amount for receiptId==0

The owner can mint all of the NFTs.

Many unbounded and under-constrained variables in the system can lead to unfair price or DoS

[WP-H1] A malicious early user/attacker can manipulate the vault's pricePerShare to take an unfair share of future users' deposits

User fund loss in supplyTokenTo() because of rounding

Fund loss or theft by attacker with creating a flash loan and setting SuperVault as receiver so executeOperation() will be get called by lendingPool but with attackers specified params

Users can use updateBoost function to claim unfairly large rewards from liquidity mining contracts for themselves at cost of other users.

User can steal all rewards due to checkpoint after transfer

function lockFunds in TopUpActionLibrary can cause serious fund lose. fee and Capped bypass. It's not calling stakerVault.increaseActionLockedBalance when transfers stakes.