User pays no fee while redeeming due to order of operations

Unauthorized Reallocation in `NudgeCampaign::handleReallocation` and Reward Disruption Vulnerability in `NudgeCampaign::invalidateParticipations`

Not verifying that transaction initiator is the actual participator allows malicious user to allocate full reward as Uniswap V2 pool

Request gets permanently stuck if worker does not deploy

Reward rate can be diluted by attacker

Use of initializer modifier instead of onlyInitializing in Vesting.sol will cause reverts for more than one SymmVesting deployments

Incorrect constraint in resetVestingPlans() blocks admin and users from using acceptable amounts

Min and max user token allocation checked incorrectly inside updateParticipation()

If users withdraw while a position is in loss, the whole PNL of the position to their withdrawal amount instead of just their share of it.

getExecutionGasLimit() reports a lower gas limit due to gasPerSwap miscalculation

User may withdraw more than expected if ADL event happens

Protocol Recovery Mechanism at Risk Due to Unhandled Token Transfer Failures

`_withdraw` function uses `shortTokenPrice.max` instead of `shortTokenPrice.min` when computing negative PnL adjustment, leading to underestimation of losses and excessive collateral withdrawal

The calculation of `totalAssets()` could be wrong if `operatorFeeAmount` > 0, this can cause potential loss for the new depositors

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

Attacker can DOS liquidity migration in LiquidityManager.sol

Attacker can exploit getCreateAmount() to mint more than expected tokens

Protocol loses fee because claimFees() does not claim the accumulated fees as promised

PoolSaleLimit can be breached in auctions as fee is not accounted for in calculations

Flash loan can be used to breach PoolSaleLimit in auctions

Auction can fail if USDC blacklists user after bid placement

Incorrect liquidation mechanics either causes revert on liquidation due to insufficient seizeTokens or causes transition into bad debt

Removal of closeFactorMantissa & maxClose constraints in deprecated markets allows attack vector to worsen protocol's health

OrderID generated by generatedOrderId() may not be unique and can overwrite existing order, causing funds to be lost

Funds can be stolen via modifying cancelled orders

Attacker can delete other user's orders due to lack of reentrancy protection in cancelOrder()

performUpkeep() may fail when tokenIn is USDT due to allowance change from non-zero to non-zero value inside `execute()`

PythOracle::currentValue() will always revert for prices which are not stale

Bonding curve logic can be exploited to pay less for buying votes

Attacker can steal considerable portion of fee by vouching in two steps instead of one

No slippage protection in `sellVotes()`

Incorrect withdraw queue balance in TVL calculation

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

Pending withdrawals prevent safe removal of collateral assets

Not handling the failure of cross chain messaging

Lack of slippage and deadline during withdraw and deposit

Withdrawals and Claims are meant to be pausable, but it is not possible in practice

totalSupply is incorrectly calculated during revokeVestingSchedule()

depositReward() function reduces rewardRate incorrectly causing delayed reward distribution and can be used by a griefer

OCL_ZVE::forwardYield() is susceptible to price manipulation attack due to the logic inside fetchBasis()

distributeYield() calls earningsTrancheuse() with outdated emaSTT & emaJTT while calculating senior & junior tranche yield distributions

Validity and contests bond ca be incorrectly burned for the correct and ultimately verified transition

Invocation delays are not honoured when protocol unpauses

Proposers would choose to avoid higher tier by exploiting non-randomness of parameter used in getMinTier()

The decision to return the liveness bond depends solely on the last guardian

Incorrect __Essential_init() function is used in TaikoToken making snapshooter devoid of calling snapshot()

Bridge watcher can forge arbitrary message and drain bridge

retryMessage unable to handle edge cases.

Malicious caller of `processMessage()` can pocket the fee while forcing `excessivelySafeCall()` to fail

Exploitation of the receive Function to Steal Funds

User's attempt to deposit & withdraw reverts due to the calculation style inside `_calculateShares()`

Malicious user can stake an amount which causes zero curStakeAtRisk on a loss but equal rewardPoints to a fair user on a win

Since you can reroll with a different fighterType than the NFT you own, you can reroll bypassing maxRerollsAllowed and reroll attributes based on a different fighterType

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

Fighters cannot be minted after the initial generation due to uninitialized `numElements` mapping

NFTs can be transferred even if StakeAtRisk remains, so the user's win cannot be recorded on the chain due to underflow, and can recover past losses that can't be recovered(steal protocol's token)

Can mint NFT with the desired attributes by reverting transaction

Constraints of dailyAllowanceReplenishTime and allowanceRemaining during mint() can be bypassed by using alias accounts & safeTransferFrom()

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

Incorrect calculation to check remaining ratio after reward in StableConfig.sol

Incorrect assumption in PoolMath.sol can cause underflow when zapping is used

StakingRewards pools are not given their promised share of rewards due to incorrect calculation

Minimium Collateral Check Can Be Bypassed

Suboptimal arbitrage implementation

changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehand

Ballots not yet past their deadline are incorrectly looped too by tokenWhitelistingBallotWithTheMostVotes()

Adversary can prevent updating price feed addresses by creating poisonous proposals ending in `_confirm`

SALT staker can get extra voting power by simply unstaking their xSALT

Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST

Rewards can be drained because of lack of access control

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

No incentive to liquidate small positions could result in protocol going underwater

Removal of approved token from token manager can lead to unintended liquidation of vaults

`costInEuros` calculation will incur precision loss due to division before multiplication

Anyone with TST tokens can monitor the mempool and frontrun mint/burn functions to get EUROs rewards without even staking.

Lack of Minimum Amount Check in `SmartVaultV3::mint`, `SmartVaultV3::burn`, and `SmartVaultV3::swap` Can Result in Loss of Fees

Griefer can deny holders of their fair share of fees

Users with Negligible TST Holdings Might Not Receive Their Share of EUROs Fees

Incorrect value returned by position() function

User can get liquidated due to incorrect calculateMinimumAmountOut()

No slippage protection for Market functions

Attacker can drain all ETH from AuctionDemo when block.timestamp == auctionEndTime

Attacker can reenter to mint all the collection supply

On a Linear or Exponential Descending Sale Model, a user that mint on the last `block.timestamp` mint at an unexpected price.

Bidder Funds Can Become Unrecoverable Due to 1 second Overlap in `participateToAuction()` and `claimAuction()`

getPrice `salesOption` 2 can round down to the lower barrier, skipping the last time period

`setAnnualInterestBips()` can be abused to keep a market's reserve ratio at 90%

Users can avoid liquidation while being under the primary liquidation ratio if on the last short record

Flag can be overriden by another user

Possible DOS on deposit(), withdraw() and unstake() for BridgeReth, leading to user loss of funds

Rounding-up of user's `cRatio` causes loss for the protocol

Primary short liquidation can not be completed in the last hour of the liquidation timeline

Loss of precision in `twapPriceInEther` due to division before multiplication

Lack of Duplicate ID Check in combineShorts Function

ETH cannot always be unstaked using Rocket Pool

Partial filled short does not reset liquidation flag after user gets fully liquidated, meaning healthy position will still be flagged if the rest of the order gets filled.

`Errors.InvalidTwapPrice()` is never invoked when `if (twapPriceInEther == 0)` is true

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

Owner can incorrectly pull funds from contests not yet expired

Centralization Risk for trusted organizers

Theft of collateral tokens with fewer than 18 decimals

DSC protocol can consume stale price data or cannot operate on some EVM chains

Chainlink oracle will return the wrong price if the aggregator hits `minAnswer`

Lack of fallbacks for price feed oracle

Too many DSC tokens can get minted for fee-on-transfer tokens.

Protocol can break for a token with a proxy and implementation contract (like `TUSD`)

Precision loss when calculating the health factor