AegisMinting#approveRedeemRequest wrongly implements redemption fee

USDC rewards will not be distributed if `_updateRewardsStates` is triggered too often

addLiquidity will revert in certain cases towards the end of the vesting period

rewards will be diluted into perpetuity via regular `notifyRewardAmount` calls with 1 wei of each reward token

createOrder will be abused to drain all approvals

Actual funding can be lower than intended due to precision loss in `utilization`

Missing storage gaps in ManageableVault's parent contracts

Anyone can cancel a raffle with tickets == minTicketsThreshold, griefing all participants

Admin can prevent raffle winner from claiming their reward

SuperPool inherits Pausable and implements `togglePause`, but none of the functions are pausable

USDC rewards round down to zero in `rewardPerTokenUSDC`

Bribes are permanently stuck in BribeRewarder if there's no voters

Lock expiration is not properly validated in Voter#vote

DoS of bribes for any pool for any period via dust bribes

Anyone can `addToPosition` to any lock because `_requireOnlyOperatorOrOwnerOf` always returns `true` for any existing lock

During emergency, funds can be withdrawn from a lock by the approved address or owner, instead of exclusively by owner

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

Invalid validation allows users to unlock early

Missing disapproval check in `LockManager.sol::approveUSDPrice` allows simultaneous approval and disapproval of a price proposal

Incorrect withdraw queue balance in TVL calculation

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

`claimAndRequestDeposit` can be used to make any user lose their deposit requests of the current epoch

Users with approvals for routers may not be able to use VaultZapper

New epoch is not started once the current one is queued for withdrawal from EigenLayer

Reward distribution can be sandwiched

`LiquidInfrastructureERC20.sol` disapproved holders keep part of the supply, diluting approved holders revenue.

Distribution can be bricked, and double claims by a few holders are possible when owner calls `LiquidInfrastructureERC20::setDistributableERC20s`

Malicious user can stake an amount which causes zero curStakeAtRisk on a loss but equal rewardPoints to a fair user on a win

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

Fighters cannot be minted after the initial generation due to uninitialized `numElements` mapping

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

Can mint NFT with the desired attributes by reverting transaction

Fighter created by mintFromMergingPool can have arbitrary weight and element

Reward distribution can be sandwiched

OperationalStaking may not possess enough CQT for the last withdrawal

setValidatorAddress allows exceeding the validator and delegator staking caps by 27 times

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

Unrestricted claiming of fees due to missing balance updates in `FeeSplitter`

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

Single token purchase restriction on curve creation enables sniping

A subject creator within a single block can claim holder fees without holding due to unprotected reentrancy path

onBalanceChange causes previously unclaimed rewards to be cleared

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

Users retain their voting power after the lock expiration

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

Missing deadline check allow pending transactions to be maliciously executed

WrappedTokenBridge#recoverTokens will drain the whole token balance

ProfitManager's "creditMultiplier" calculation does not count undistributed rewards; this can cause value losses to users

No slippage protection for Market functions

Attacker can drain all ETH from AuctionDemo when block.timestamp == auctionEndTime

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