Incorrect interest calculated as staker history not updated inside `_checkBoundariesAndRecord()`

Staker actions can run OOG or become too expensive due to stuffing of tier history by attacker

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

Faulty Gauge Weight Update Formula: Voting Power Delta Not Considered Leading to Arithmetic Underflow and Vote Weight Inconsistency

Users Can Overwrite Existing Locks in veRAACToken Resulting in Permanent Loss of Funds

Gauge period cannot be updated

`GaugeController::_calculateReward` implementation will cause smaller shares to be allocated to every gauge

Multiple issues from unnecessary balance increase calculation in DebtToken.mint

Incorrect Reward Claim Logic in FeeCollector::claimRewards Causes Denial of Service

RToken's transfer function lead to loss of funds due to incorrect math

Users can borrow more assets than they have deposited as collateral

Attackers can get most of RAACToken rewards by withdrawing dust amount from StabilityPool multiple times

Any attempt to liquidate a user will fail, because StabilityPool does not hold crvUSD during operational lifecycle

Double Usage Index Scaling in StabilityPool Liquidation Inflates Required CRVUSD Balance

Attackers can double voting power and veToken amount by locking and increasing

The total voting power of all veRAAC tokens is wrongly assigned

Ineffective Time-Weighted Average Implementation in Fee Distribution

Voting Power Snapshot Missing

Missing StabilityPool Integration in `mintRewards` Function

Gauge reward period can be extended indefinitely

Incorrect utilization rate forces protocol to issue maximum rewards indefinitely

Incorrect DebtToken totalSupply Scaling Breaks Interest Rate Calculations

RToken.transferFrom() Does Not Scale User Balances Due to Stale Liquidity Index

Liquidation Cannot Be Closed Even With Healthy Position Due To Strict Debt Check

There is no logic checking for RAACNFT price staleness before minting it

`RToken::calculateDustAmount` are incorrectly calculated, leading to not be able to transfer the accrued dust amount

LendingPool.getUserDebt returns outdated value and can lead to liquidation failure

Workingsupply would always be overwritten in boostcontroller.sol impacting reward calculations

Permanent boost inflation through delegation removal in Boostcontroller.sol

Incorrect Period Transition Logic in Reward Distribution

Time-skew Attack in RWAGauge Weight Calculations Through Precision Gaming

Multiple Token Management Lets Withdraw a Token Different than Deposited Token

`RAACReleaseOrchestrator::emergencyRevoke()` fails to update `categoryUsed`, leading to token lockup and incorrect accounting

Incorrect reward calculations in tick function

Proposal Front-Running via Predictable Salt in `TimelockController::scheduleBatch`

Cordinated group of attacker can artificially lower quorum threshold during active proposals forcing malicious proposals to pass without true majority support.

RAACToken burns less tokens than expected when feeCollector is unset

Flawed Boost Multiplier Calculation Always Yields Maximum Boost

Pending fee not cleared and overwritten by updates via updateFeeType()

Paused Protocol Prevents Critical Functions Including Debt Repayment and Liquidations

RAACNFT wrongly suppose crvUSD to be equal to 1 dollar

Emission Rate can be Manipulated (Locked, Higher or Lower)

When bad debt is accumulated the loss is not distributed amongst all suppliers leading to a huge loss for the last supplier to withdraw

Incorrect rewardRate management in BaseGauge

Emergency Timelock Bypass: No Enforced 1-Day Delay for Emergency Actions

Missing Controller Functions in GaugeController

Unauthorized Vote Casting Vulnerability

Impossible to rescue funds from `RToken` contract

Emergency withdraw functionality in veRAACToken takes longer than expected

Missing Checkpoint Reset in `veRAACToken::emergencyWithdraw` Function

Missing `BaseGauge::distributionCap` validation leads to over-emission of rewards

Hardcoded Emission Values Lead to Incorrect Reward Calculations

Deposits/Withdrawals can be DOS'ed if crvVault::withdraw produces any losses

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