Malicious user can DoS whole period redeems when limit is in place

Any unused approvals to `BlueprintV5.sol` can be used to steal funds

Attacker can easily disrupt reward distribution and render `SymmStaking` useless

Adding liquidity to the LP will revert in some cases

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

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

`BaseGauge` users can claim rewards without staking

`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

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

NFTs Get Permanently Locked in Stability Pool After Liquidation

Double Usage Index Scaling in StabilityPool Liquidation Inflates Required CRVUSD Balance

Ownership Parameter Mismatch in LendingPool’s Vault Withdrawal Logic

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

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

Gauge rewards are not transferred to gauge when distributeRewards() is called

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

Ineffective Time-Weighted Average Implementation in Fee Distribution

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

Missing Boost Balance and other parameters Update in veRAACToken Functions. Incomplete Boost State Updates Result in Inaccurate Voting Power and Reward Distribution

Incorrect utilization rate forces protocol to issue maximum rewards indefinitely

RToken.transferFrom() Does Not Scale User Balances Due to Stale Liquidity Index

LendingPool deposits do not work with CurveVault due to lack of funds

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

Using balanceOf Instead of Voting Power

There is no logic checking for RAACNFT price staleness before minting it

Treasury Contract Deposit Function Can Be Frontrun To Deny Protocol Operations

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

Emergency revoke in RAACReleaseOrchestrator will freeze revoked RAAC tokens in orchestrator

Insufficient Balance Validation in BaseGauge Can Lead to Reward Insolvency

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

Missing Boost State Update in extend() and withdraw()

Gauge emissions revert when emissions are higher than the leftover buffer instead of depositing the difference

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

`GaugeController::distributeRewards` can be called multiple times by anyone, leading to excessive reward distribution

Lack of Time-Weighted Voting and Weight Decay in GaugeController

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

Irreversible emission cap reduction in BaseGauge

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

Hardcoded addresses

Missing Router Update Mechanism in StrategyMainnet Contract

Old router retains token allowance after update

Buy fee PID is updated with wrong amounts leading to unexpected fee growth

Vaults can be purposefully bricked by leaving small amounts of rETH

Lenders can force borrowers into liquidation

Lender group members can be prevented from burning their shares forever

Overpaying a loan can DoS an entire lender commitment group

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

`sellQuote` and `buyQuote` are missing deadline check in `LamboVEthRouter`

Malicious attacker can brick users claiming sale proceeds from collection shutdown by reclaiming vote

`ERC721Bridgable` cannot receive ETH for royalty payouts

Users cannot claim royalties for `ERC1155`

Users can create permanent protected listings and inflate interest rates

If a collection has been shutdown but later re-initialized, it cannot be shutdown again

Users can dodge `createListing` fees

Users can sandwich unlocking their protected listings to pay less fees

Unrestricted Changes to Token Settings Allow Artists to Alter Critical Features

Exposed `_removeCredIdPerAddress` & `_addCredIdPerAddress` allows anyone to cause issues to current holders as well as upcoming ones

`shareBalance` bloating eventually blocks curator rewards distribution

Signature replay in `createArt` allows to impersonate artist and steal royalties

Refunds sent to incorrect addresses in certain cases

Incorrect Fee Handling Prevents Protocol from Updating Fees