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

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