Invariant Violation: ETH0 Not Fully Backed After Collateral Price Drop Enables Treasury Drain

The user can send tokens to any address by using two bridge transfers, even when transfers are restricted.

Slippage protection in `AgentTax::dcaSell` and `BondingTax::swapForAsset` is calculated at execution time, effectively retrieving the very same price that the trade will be executing at, ultimately providing no protection

`amountOutMin` passed in as 0 in `AgentToken::_swapTax` leads to loss of funds due to slippage

BondingTax has invalid slippage implementation

Missing Slippage Protection On Buy And Sell

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

Delegation Boost Not Usable by Delegatees

`BaseGauge` users can claim rewards without staking

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

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

Double Usage Index Scaling in StabilityPool Liquidation Inflates Required CRVUSD Balance

Boost Miscalculation Leads to Excess Distribution

`MAX_TOTAL_SUPPLY` Bypass in `veRAACToken` via `increase()` Function

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

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

Proposal Front-Running via Predictable Salt in `TimelockController::scheduleBatch`

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

Unbounded Reward Accrual After Period End Enables Reward Manipulation Attacks

Unauthorized Vote Casting Vulnerability

Hardcoded Emission Values Lead to Incorrect Reward Calculations

quantAMMSwapFeeTake used for both getQuantAMMSwapFeeTake and getQuantAMMUpliftFeeTake.

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