`_checkBoundariesAndRecord` checks incorrectly and this causes confusion for recording tier history(Tier 2 boundary handling)

Incorrect implementation of `ERC4626ViewAdjustor`

Incorrect handling of ERC4626 vaults with fees

Attacker can decrease the overall reward amount by notifying dust.

Attacker can prevent stakers from claiming all rewards by extending reward period

Incorrect base calculation in Leverager#isLiquidateable() prevents normal liquidations

`secondaryPosition`'s `tickLower` can be equal or larger than `tickUpper`

`Secp256k1ProverV1`.`postBatch` doesn't check duplication of signers

Malicious `batchSender` can reject ethers so that only he can claim reward

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

RAACNFT mint function receives funds to address(this) but has no way of withdrawing them

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

Reward manipulation vulnerability in StabilityPool

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

NFTs Get Permanently Locked in Stability Pool After Liquidation

Double Usage Index Scaling in StabilityPool Liquidation Inflates Required CRVUSD Balance

Ownership Parameter Mismatch in LendingPool’s Vault Withdrawal Logic

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

Ineffective Time-Weighted Average Implementation in Fee Distribution

Incorrect utilization rate forces protocol to issue maximum rewards indefinitely

LendingPool deposits do not work with CurveVault due to lack of funds

Multiple Critical Calculation And Logic Errors in `RToken::mint/burn` Function

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

Missing Liquidity Rebalancing in Repayments and Liquidations Leading to Inefficient Liquidity Management

hardcoded baseamount in Updateuserboost fucntion causes users with small token holdings to receive higher boosts relative to their holdings t

Permanent boost inflation through delegation removal in Boostcontroller.sol

FeeCollector stakeholders may receive less fee distribution due to unnecessarily precision loss

Usage rate is increased even when no debt is present in `LendingPool`

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

When the prime rate is updated by the oracle, the values of the sub-rates are not ajdusted accordingly, which can cause loss of assets for borrowers

Portion of revenue to be distributed for gauges remains undistributed

Canceled vote still get voted on and accumulate voting power in Goverance.sol

Impossible to rescue funds from `RToken` contract

`FeeCollector::updateFeeType` wrong fee share validation leads to impossible update for some fee types

Boost Delegation Allows Invalid Recipients on BoostController

Incorrect Mint() Event Emission in RToken#mint()

Wrong event emitted in `LendingPool::_repay`

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

[M-3] Anyone can deploy a new `FraxSwapPair` with a Low fee incurring losses to the protocol

Loss of Fees for Router `UpliftOnlyExample` due to Division Rounding in Admin Fee Calculation, Causing Unfair Fee Distribution

Inconsistent timestamp storage when the LPNFT is transferred.

Critical Precision Loss in MultiHopOracle Price Calculations

Incorrect Total Assets Calculation in _harvestAndReport Leading to Share Value Manipulation and Irredeemable Assets

Inflated `totalAssets` in `StrategyMainnet`, `StrategyArb`, and `StrategyOp` Contracts

Missing Router Update Mechanism in StrategyMainnet Contract

Missing slippage protection in `AerodromeDexter.sol` `swapExactTokensForTokens()`

Users can claim more that their actual allotment

Incorrect referral fee calculations

Unauthorized Fund Transfer on `modifyOrder`

Stop Limit and Bracket Orders can cause ID collision and fund locking

Replay attack vulnerability in `withdraw` function due to nonce mismanagement, in `CDS` contract

Arbitrary price manipulation in `redeemUSDT` function enables treasury drain

Missing access control in `updateDownsideProtected` allows arbitrary manipulation

Exploitable high `strikePrice` input allows borrowers to minimize withdrawals

Incorrect borrower count and withdrawal issues due to improper flag handling in `treasury` contract

Inconsistent `lastEthprice` updates impact omnichain data calculations

`calculateCumulativeRate` always returns `lastCumulativeRate` due to incorrect `lastEventTime` update

Excess ether not refunded to users in `depositTokens` function

Minting zero tokens when underlyingToken is not Ether in cashIn()

Fee calculation vulnerability will overcharge users during vote purchases

Attacker can gain a advantage by manipulating the order in which votes are bought and sold.

`slash` function lacks 24-hour lock mechanism for accused staking and withdrawals

Multiple fee miscalculation leads to inaccurate implementation of the fee model

Wrong unlockPeriod behavior in FluidLocker contract

Missing NFT claim mechanism prevents buy order owners from accessing transferred NFTs

Valid lenders and borrowers may not receive their incentives due to sequence of `lenders`

Lack of handling for unclaimed incentives causes permanent lockup of funds

Loan extension miscalculation will cause reversion of extendLoan

Borrowers will face excessive principal loss due to incorrect fee calculation(`feeOfMaxDeadline`) in loan extension

Inconsistent `isActive` state in `DLOImplementation` enables repeated exploitation of `changePerpetual` to clear factory lend orders

Incorrect calculation of extended loan days leads to unfair borrower fees

Incorrect interest handling after loan extension leads to lender losses

Attacker manipulates precision loss to overcharge borrower on APR

Subtraction in `variance()` will revert due to underflow

Potential underflow vulnerability in score range calculation of `LLMOracleCoordinator::finalizeValidation`, leading to DoS.

Platform fees withdrawal will sweep oracle agents earned fees

Request responses and validations can be mocked leading to extraction of fees and/or forcing other generators to lose their fees by making them outliers

Phase calculation inaccuracy will always extend sell phase and cut withdrawal phase time

checkIsAddressCompromised will always revert on restored addresses (Including inviteAddress)

Compromise check will prevent malicious operations

Precision loss in createDistribution will accumulate and lock undistributed tokens