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

[H-01] Auction tokens will be lost forever when auction ends without bids

Epoch mismatch in FjordPoints and FjordStaking leads to user being able to stake and unstake instantly for rewards

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Wrong value decremented from `totalSupply` when revoking a vesting schedule will lead to last users not being able to withdraw their funds

"Revoked" vesting amount can still be used for voting even after vesting is revoked

Any user can grief rewards distribution `rewardRate` variable

A user can split up their junior deposit into smaller portions to extract maximum `maxBonusIncentive` value

Flawed bid cancellation logic allows user to win auction with 100% certainty without even spending any money

Reentrancy when claiming vesting funds allows attacker to steal all other users' funds

No way for vesting contract to receive native funds to pay out to users

Partial withdrawals to operator delegator are bricked due to low-level call gas limit

Attacker can front-run rewards distribution to be awarded unfairly which decreases the yield for honest users

Minting formula does not subtract pending withdrawals

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

Since you can reroll with a different fighterType than the NFT you own, you can reroll bypassing maxRerollsAllowed and reroll attributes based on a different fighterType

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

Can mint NFT with the desired attributes by reverting transaction

Constraints of dailyAllowanceReplenishTime and allowanceRemaining during mint() can be bypassed by using alias accounts & safeTransferFrom()

Fighter created by mintFromMergingPool can have arbitrary weight and element

No proposal time limit traps sponsors of unpopular proposals

SALT staker can get extra voting power by simply unstaking their xSALT

Creation of token whitelisting proposals can be DOS'd

Whitelised accounts can be forcefully DoSed from buying curveTokens during the presale

Attack to make ````CurveSubject```` to be a ````HoneyPot````

Unauthorized Access to setCurves Function

Protocol and referral fee would be permanently stuck in the Curves contract when selling a token

Selling will be bricked if all other tokens are withdrawn to ERC20 token

Curves::_buyCurvesToken(), Excess of Eth received is not refunded back to the user.

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

`costInEuros` calculation will incur precision loss due to division before multiplication

Users staking via the `SurplusGuildMinter` can be immediately slashed when staking into a gauge that had previously incurred a loss

The price of rsEHT could be manipulated by the first staker

Possible arbitrage from Chainlink price discrepancy

Incompatibility With Fee-On-Transfer Tokens

Front-Running rollLoan With newTermsForRoll Forces High Interest Rate on Loan

No Access Control Modifier for rollLoan() can Force Borrower to Default and Lose Collateral

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

Centralization Risk for trusted organizers

DAI Tokens at Risk Due to Lack of address(0) Check in distribute

During refinance() new Pool balance debt is subtracted twice

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Lender fails to giveLoan because of inconsistent length between `loadIds` and `poolIds`

Possible DOS by borrowers in `setPool()`