Misscalculation of `assetsToWithdraw` in `E4626::commit(...)` leads to invalid vault accounting

`Burve`'s multi-pool won't work with vaults that charge fees

`removeValueSingle(...)` will always produce a zero `realTax` leading to issues

Users will receive less tokens when using `ValueFacet::removeValueSingle(...)` due to double tax

Missing `acceptOwnership` selector in the `Diamond.sol` facet initialization

Anyone can DOS handleReallocation over and over

Invalid token amount calculations leads to DoS in `Launch::updateParticipation(...)`

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

ZENO Token Redemption Returns Negligible USDC Amount Compared to Purchase Price

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

Gauge period cannot be updated

`GaugeController` does not send funds to FeeCollector disrupting fees distribution and causing loss of funds

Multiple issues from unnecessary balance increase calculation in DebtToken.mint

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

Users can borrow more assets than they have deposited as collateral

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

Ownership Parameter Mismatch in LendingPool’s Vault Withdrawal Logic

Gauge rewards are not transferred to gauge when distributeRewards() is called

Ineffective Time-Weighted Average Implementation in Fee Distribution

Future Stakers Gains More Rewards from Already Accumulated `rewardPerTokenStored` Causing Unfair Reward Distribution

Incorrect DebtToken totalSupply Scaling Breaks Interest Rate Calculations

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

LendingPool::getNormalizedIncome() returns stale liquidity index

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

Treasury Contract Deposit Function Can Be Frontrun To Deny Protocol Operations

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

Incorrect Period Transition Logic in Reward Distribution

Wrong access control in `RAACToken::setFeeCollector`, `RAACToken::setSwapTaxRate`, `RAACToken::setBurnTaxRate`

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

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

Emission rate manipulation via temporary utilization spike in RAACMinter.sol

Delegated Boost Persists Even If veRAAC Is Withdrawn/Reduced

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

Missing Controller Functions in GaugeController

Incorrect Initialization of minBoost in BaseGauge Constructor Breaks Core Contract Functionality

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

Overwriting Previous Allocations in allocateFunds May Lead to Loss of Cumulative Allocation Data

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

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

Invalid `period` used in `Pool::transferReserveToAuction(...)` function leads to DoS of the `Auction` contract

Plaza token creation can be gamed when collateral level is <= 1.2

Base mainnet ChainLink oracle is incompatible with `wstETH` causing issues for fetching the reserve token price

Blacklisted `USDC` user could DoS the `Auction` contract

Stuck funds in `BalancerRouter` when user exceeds `PreDeposit` deposit cap

`BondEth` holders could end up claiming other users' `couponTokens`

Precission loss in the Pool contract

Users can claim more that their actual allotment

Rounding error in stepDuration calculations.

Weak randonmness in `AutomationMaster::generateOrderId(...)` could lead to `orderId` clashes

Missing maximum limit for the `pendingOrderIds` array in the `OracleLess` contract could lead to DoS

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

Invalid vest unlock flow rate calculations in `FluidLocker::_vestUnlock(...)` leads to recepients paying much higher tax rates than intended

Malicious actor can front-run any `VVVVCTokenDistributor::claim(...)` transaction and get all of the user funds

Archived/Deleted author could archive his/her review

Funds can be locked indefinitely in the GammaRewarder contract

Taker of bid offer will loss assets without any benefit if he calls the DeliveryPlace::settleAskMaker() for partial settlement.

`DeliveryPlace::settleAskTaker` Has Incorrect Access Control

Formulaic Error Rounds Down Causing Total Loss Of Funds For Bid Takers During Abort

The `DeliveryPlace::settleAskTaker()` function mistakenly uses `makerInfo.tokenAddress` to update the `TokenBalanceType.PointToken` in the `userTokenBalanceMap` mapping, leading to a critical error.

Missing abort status check allows bid taker to steal users funds

`listOffer` Unsafely References Fungible Identifiers

Number of entities in generation can surpass the 10k number

Wrong minting logic based on total token count across generations

Forger Entities can forge more times than intended

Duplicate NFT generation via repeated forging with the same parent

Imprecise token age calculation results in an incorrect nuke factor, causing users to claim the wrong amount

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

Invalid validation in _farmPlots function allowing a malicious user repeated farming without locked funds

Not upadting `_totalAuctionTokenAllocation` when removing last auction config at cooldown leads to wrong accounting of `_totalAuctionTokenAllocation` and permanent lock of auction tokens