The verifyBatchSignatures function may trigger an index out-of-range panic for consensus nodes, due to missing lower-bound check

Attacker can frontrun unstake calls to manipulate withdrawals

postBatch doesn’t check for duplicate signatures resulting in being able to overcome the consensus threshold

Multiple Delegation by Double Spending Boosts and Lack of Delegation Tracking in BoostController Contract

ZENO Token Redemption Returns Negligible USDC Amount Compared to Purchase Price

Multiple issues from unnecessary balance increase calculation in DebtToken.mint

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

Incorrect Debt Scaling Leading to Protocol Solvency Risk

Treasury Balance Tracking Bypass in FeeCollector

Ineffective Time-Weighted Average Implementation in Fee Distribution

Missing StabilityPool Integration in `mintRewards` Function

Incorrect Return Values and Double Scaling in `RToken.burn` Function Leads to Denial of Service

Using balanceOf Instead of Voting Power

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

Permanent boost inflation through delegation removal in Boostcontroller.sol

Inconsistent Scaling in RToken Transfer Functions

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

Failure to update `lastClaimTime` mapping when users claim rewards in FeeCollector Causes Time-Based Reward Calculation Issues

RAACToken burns less tokens than expected when feeCollector is unset

Incorrect boost calculation in `BoostController#_calculateBoost()` can be exploited to gain an unfair advantage in reward distribution

Flawed Boost Multiplier Calculation Always Yields Maximum Boost

Misuse of Raw vs. Normalized Values in Utilization Rate Calculation

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

`mint` function in RToken contract doesn't return the correct expected values, leading to emission of ReserveLibrary `Deposit` event and LendingPool `Deposit` event with incorrect values.

Limited veRaac Token Supply Triggers DoS, Hampering Proper Governance Participation.

Unauthorized Vote Casting Vulnerability

Incorrect Initialization of minBoost in BaseGauge Constructor Breaks Core Contract Functionality

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

Inadequate Emergency Shutdown Role Enforcement in RAACMinter: Denial of Service in Emergency Response

Hardcoded Emission Values Lead to Incorrect Reward Calculations

Misleading NatSpec and Ambiguous Access Control in `setHousePrice` Function

`emergencyUnlockEnabled` Is Never Used, Rendering “Emergency Unlock” Ineffective

`collateralLiquidated` value is always 0 when emitted in the `LiquidationFinalized` event

Incorrect Gauge Weight Emission in BoostController Vote Function

Indefinite Extension of Delegation in function delegateBoos() in BoostController.sol

Inaccurate Execution Time Reporting in Proposal Execution Revert

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

Adversary can win proposals with voting power as low as 4%

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

Missing Access Control on burnFrom() Function

Missing Handling of Excess Ether in buy() Function

No Time Checks During invest()

Potential Duplicate Participant Entries in participants Array

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

Users can list assets with price < 1 ERC20 (ETH, WETH), leading to potential DoS vulnerability.

Lack of output validation in `LLMOracleCoordinator::respond` allows empty responses and potential fee exploitation by oracles.

`LLMOracleCoordinator::request` lacks a check for non-empty `task.input`, making `assertValidNonce` easier to pass due to reduced uniqueness

Actor can frontrun lz_receive and steal users’ withdrawal

User will be able to use any deposit_token to bridge usdc

Possible DOS of pools leading

Potential Front-Running and DoS Vulnerabilities due to EIP-2612 Usage

Fee on transfer tokens will result in user losses