User can override the `deployWorkerAddr` and not submit a deployment proof

Incorrect Token Price Validation in KeeperProxy

Protocol Recovery Mechanism at Risk Due to Unhandled Token Transfer Failures

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

`GaugeController` does not send funds to FeeCollector disrupting fees distribution and causing 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

Boost Miscalculation Leads to Excess Distribution

Lack of Access Control in BoostController::updateUserBoost Leading to Unauthorized Delegation Overwrite.

Treasury Balance Tracking Bypass in FeeCollector

Untracked Direct Fee Transfers from RAACToken to FeeCollector Break Fee Distribution System

Critical Economic Design Flaw in ZENO Zero-Coupon Bond Implementation Leads to Guaranteed User Losses

Gauge stakers won't get any reward due to round-down in user weight calculation

Gauge reward system can be gamed with repeatedly stake/withdraw

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

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

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

Treasury Contract Deposit Function Can Be Frontrun To Deny Protocol Operations

Failure to Withdraw Liquidity to RToken.sol Before Changing Curve Vault Address

Portion of revenue to be distributed for gauges remains undistributed

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

WSTETH is not supported by the protocol

User can always inflate the `totalSellReserveAmount` variable to block the auction from being ended

USDC blacklist may be a problem in Auction

Precision loss in `Pool::getRedeemAmount` will result in users redeeming less collateral than they should

User can cancel his order and then call modify order to get even more funds

User can brick the `Bracket` contract by inputing malicious `txData`

NFT buyer will never receive his receipt NFT after `buyOrder::sellNFT` function

Nobody can buy the `TaxTokenReceipt` NFT from auction

`BuyOrder` is not compliant with `TaxTokenReceipt`

Malicious seller of receipt token is able to control the corresponding veNFT after a sell

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

`hashProposal` is not compliant with EIP-712

Incorrect Fee Handling Prevents Protocol from Updating Fees

Availability of deposit invariant can be bypassed

AuraVault inherits AccessControl BUT does not call the _setupRole() function in it's constructor to set the initial roles, this leads to a complete DOS of the important claim function rendering the contract unable to claim rewards

Incorrect calculation of `newCumulativeIndex` in function `calcDecrease`

`PendleLPOracle::_fetchAndValidate` uses Chainlink's deprecated `answeredInRound`

Absence of deflationary rebasing tokens protection in `BaseRewarder`

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

StakingToken.sol doesn't properly handle FOT, rebasing tokens or those with variable which will lead to accounting issues downstream.

Availability of deposit invariant can be bypassed

AuraVault inherits AccessControl BUT does not call the _setupRole() function in it's constructor to set the initial roles, this leads to a complete DOS of the important claim function rendering the contract unable to claim rewards

Incorrect calculation of `newCumulativeIndex` in function `calcDecrease`

`PendleLPOracle::_fetchAndValidate` uses Chainlink's deprecated `answeredInRound`

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

[M-1]

[H-2]

[H-3]

Owner of a position can prevent liquidation due to the 'onERC721Received' callback

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.