`InvestToken`: Whitelisted investors can inflate USDE to infinity by arbitraging previous and current price differences

Collateral can already be seized even when negRiskMarket is not fully resolved

Lender can deny a repayment by getting themselves on the USDC blacklist

Wrong call order for `setTopPoolIdsWithWeights`, resulting in wrong distribution of rewards

Bribe rewards are lost if a pool receives no votes during an epoch

Unlocked positions can still vote

Bribes can be denied by filling up a farm with fake bribes until `MAX_BRIBES_PER_POOL` limit

Incorrect access control for `_requireOnlyOperatorOrOwnerOf()`. Anyone can call `MlumStaking.addToPosition()` for other users, with various impacts.

Users can artificially create a voting ballot with 2 weeks `lockDuration`, effectively bypassing the 3-month limit

Down Rebasing Tokens will cause bankrun in MlumStaking and MasterChefV2

New staking positions still gets the full reward amount as with old stakings, diluting rewards for old stakers

Max exposure cap can be bypassed on assets using WrappedAerodromeAM.sol

LP can instantly arbitrage and drain any Maker by updating the Pyth price

OracleMaker's price with spread does not take into account the new position

USDT/USDC depeg event will pit both makers at a highly risky position due to arbitrage

No slippage check for deposit/withdraw in either Makers

`CREATE2` address collision against an Account will allow complete draining of lending pools

L2 sequencer down will push an auction's price down, causing unfair liquidation prices, and potentially guaranteeing bad debt

New staking between reward epochs will dilute rewards for existing stakers. Anyone can then front-run `OperationalStaking.rewardValidators()` to steal rewards

Frontrunning validator freeze to withdraw tokens

No cooldown in `recoverUnstaking()`, opens up several possible attacks by abusing this functionality.

`validatorMaxStake` can be bypassed by using `setValidatorAddress()`

No option to change validator address without also transferring unstakings, leads to lost rewards when a validator has taken more than 300 unstakings (even if through normal usage)

Chainlink price feed uses BTC, not WBTC. In case of depegging, oracles will become easier to manipulate.

Some tokens enable the direct draining of all approved `ERC20Votes` tokens

`emergency_shutdown` role is not enough for emergency shutdown.

Blacklisted STADIUM_ADDRESS address cause fund stuck in the contract forever

If a winner is blacklisted on any of the tokens they can't receive their funds

Potential DOS due to Gas Exhaustion Due to Large Array Iteration in `_distribute` Function

Using basis points for percentage is not precise enough for realistic use-cases

If governance removes a gauge, user's voting power for that gauge will be lost.

Fee on transfer tokens will cause users to lose funds

Use smaller data types for `lenderFee` and `borrowerFee` for better storage packing

Protocol does not check for price staleness from the XOracle, which is problematic if the price feeder goes down.

PriceOracle will use the wrong price if the Chainlink registry returns price outside min/max range

Chainlink oracle may return stale data

Incorrect `blocksPerYear` constant in `WhitepaperInterestRateModel`

Exchange Rate can be manipulated

Potential Unjust Liquidation After Exiting Market

Unsafe ERC20 transfer: tokens that don't revert on failed transfers may disable claims

Placeholder

Potential infinite loop in `_borrowLimit` function

A liquidated position possibly cannot be closed

Bad implementation in minter access control for `RabbitHoleReceipt` and `RabbitHoleTickets` contracts

DOS risk if enough tokens are minted in Quest.claim can lead, at least, to transaction fee lost

Rollable loans can be indefinitely rolled, opening up room for a griefing attack that will permanently lock funds.

Unsafe ERC20 usage: If one of the token is a non-revert on transfer, the other token can be stolen.

`getEmergencySettlementBPTAmount()`: Wrong usage of `IERC20.totalSupply()` on BPT tokens