Attacker will drain LEND tokens from CoreRouter

Free, Zero-Cost Cross-Chain Liquidation

Collateral Check Bypass via USD vs Token Units Mismatch

Fee Bypass in `ValueFacet.removeValueSingle`

Incorrect Netting in `E4626::commit`

Sqrt function silently reverts the entire control flow when a packed float of 0 value is passed

Natural Logarithm Function Silently Accepts Invalid Non-Positive Inputs

Lack of State Validation in `submitProofOfDeployment` Allows Invalid Proof Submission and Workflow Bypass

In the `configureRewardToken` function when a token is unwhitelisted, the rewardState is not reset

Wrong amount is minted to user when they deposit into the lending pool

Delegation Boost Not Usable by Delegatees

Incorrect decimal handling in `Auction::buy()` leads to massive overpayment for ZENO tokens

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

`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

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

NFTs Get Permanently Locked in Stability Pool After Liquidation

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

Treasury Balance Tracking Bypass in FeeCollector

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

Gauge Voting Misallocation Vulnerability

The total voting power of all veRAAC tokens is wrongly assigned

Interest Accrual Failure Due to Incorrect Scaling in RToken Implementation

Incorrect Debt Token Accounting Due to Multiple Scaling Issues

Ineffective Time-Weighted Average Implementation in Fee Distribution

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

Voting Power Snapshot Missing

Stability pool does not consider RToken balance increase when DEToken is withdrawn

Users can lose additional collateral by depositing NFTs after grace period expiration

Incorrect accounting in `veRAACToken::emergencyWithdraw` and `veRAACToken::withdraw` due to missing `totalLocked` update

veRaac Token Constraint MAX_TOTAL_SUPPLY Can Be Bypassed. Vulnerability Disrupts Protocol Functionality and Undermines Governance Quorum.

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

Users Can Lose Funds and Collateral by Repaying Loans After Liquidation Grace Period Expiry

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

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

`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

Emergency revoke in RAACReleaseOrchestrator will freeze revoked RAAC tokens in orchestrator

`veRAACToken::_updateBoostState` function sets individual user voting power instead of system-wide totals

User may not be able to increase the amount of locked RAAC tokens

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

Token Accounting Mismatch Between tick() and mintRewards() in RAACMinter

Emergency Withdrawal Remains Active After Cancellation

Incorrect Period Transition Logic in Reward Distribution

[L-1] Inaccurate boost calculations in `veRAACToken` due to wrong input parameter

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

Incorrect reward calculations in tick function

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

balanceOf(address(this)) in StabilityPool causes reward distribution to be higher than it should be

Users Cannot Remove Their Own Boost Delegation, Causing Potential Lock-In

The earned yield from the Curve vault can never be utilized when withdrawing or borrowing

Emergency Withdrawals in `FeeCollector` will break Fee Distribution Logic

Inconsistent Fee Collector Address Validation in RAACMinter: Denial of Service for Disabling Fee Collection

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

Unnecessary Vault Withdrawals Due to Unchecked User Withdrawal Amounts

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

Lack of enforcement of the `MAX_TOTAL_LOCKED_AMOUNT`

Unauthorized Vote Casting Vulnerability

Impossible to rescue funds from `RToken` contract

Incorrect Initialization of minBoost in BaseGauge Constructor Breaks Core Contract Functionality

Missing Checkpoint Reset in `veRAACToken::emergencyWithdraw` Function

Missing Pause Functionality in veRAACToken Contract Can Be Abused When Emergency Withdrawal Mechanism Is Activated

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

Missing Check for Gauge Activation Status in vote :: GaugeController.sol

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

Lack of incentives for users to call LendingPool::initiateLiquidation allows extensive delay between when health factor dropped below threshold and when grace period starts

Auction Price Calculation Fails to Reach Reserve Price Due to Integer Division Truncation

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

Ineffective proposal threshold validation allows setting arbitrary high values

Underflow when updating credit delegation will result protocol DoS

ZlpVault Does Not Fully Implement ERC-4626

Malicious User Can Inflate Rewards, Depleting the Pool for Honest Users.

`Pool::transferReserveToAuction` Will Always Revert Due to Incorrect Period

Market Rate Calculation Error in LEVERAGE Token Redemption

Incorrect Calculation of Token Creation and Redemption Rates Due to BondOracleAdapter

Malicious User Can Grief an Auction by Manipulating Pool Reserves

Unable to Remove Bid Due to USDC Blacklist

The `PreDeposit._deposit()` Logic Will Lock User `BPT` Token Funds in the BalancerRouter

Inaccurate Share Calculations Due to Inclusion of Failed Auctions

Incorrect Precision Adjustment in Token Rate Calculations

Incorrect Ether Recipient in Liquidation

Updating the `downsideProtected` in the CDS Contract Lacks Access Control

Complete loss of USDT funds from the Treasury contract

Borrower-Set Strike Price Mechanism Can Lead to Collateral Losses for Users Under Volatile Market Conditions

Loss of User Funds Due to Incorrect LZ Fee Handling in Borrowing and CDS Contracts

The `liquidationType1` function in the borrowLiquidation contract reverts unexpectedly when calculating the yields

`liquidationType2` Requires Admin to Fund Liquidations

Inability to Withdraw ETH/tokens in BorrowLiquidation Contract if `closeThePositionInSynthetix` is Called

Logical Vulnerability in deposit and withdraw Functions of Treasury contract that Allowing Manipulation of `noOfBorrowers` State