Usage of `slot0` on dexBalances() is easy to manipulate

first depositor attack possible through multiple attack paths because the deposit function does not check 0 shares received.

Accrued reward cannot be claimed when the last staker unstake all the token he own

self.claimed not updated when recipient make a claim on InflationaryVest.vy, lead to miscalculation for subsequent claim

Inconsistent balance accounting in stETH deposits leads to DOS of core functions and reward loss

Same heartbeat for multiple price feeds is vulnerable

Lack of slippage protection for user when deposit / withdraw

wrapAndSupplyOnExtensionMarket always revert because lack of gasFee when executing supplyOnHost on mTokenGateway

Rebalancer will fail if using EverclearBridge because lack of fund transfer from Rebalancer contract to EverclearBridge contract

IERC20.transfer() not working for USDT, this affect redeem() function on CoreRouter.sol

Mishandling of receiving HYPE in the StakingManager , lead to user can't confirm withdrawal and inflate the exchange ratio

Non-whitelisted owner can also hold/own a troveNFT

The current implementation is incompatible with `WBTC` as collateral token

All reallocate cross-chain token and rewards will be lost for the users using the account abstraction wallet

Attacker can weaponize payWithERC20() to drain all balance from victim

`Vesting.sol` use `initializer` modifier instead of `onlyInitializing`

Incorrect calculation on `userTokens` when user call `updateParticipation()`

The calculation of `totalAssets()` could be wrong if `operatorFeeAmount` > 0, this can cause potential loss for the new depositors

Protocol fee amount calculation is inconsistent

The remaining deposit BLP will be stuck in `BalancerRouter.sol` when the user makes a deposit to `PreDeposit.sol`

Blocklisted bidder cannot be removed from auction even his bid == lowestBidIndex and his can make auction always fail

Users can claim more that their actual allotment

Creator of one vesting plan can affect vesting plans created by other users.

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

Lack of slippage on `sellVotes()`

User can only make a claim once and can't claim on remaining available epochs, although there are still rewards to claim

`drawRaffle()` cannot be call, this results in boost participants not getting their incentives

Fee on Transfer and Rebasing Token can't be used for budget asset

There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` function

`ZEROLEND` protocol can consume stale price data or cant operate on some EVM chains

`ChainlinkEthOracle` and `ChainlinkUsdOracle` did not check `minAnswer` and `maxAnswer`, this may cause wrong price

The `superPool` contract cannot be `paused` and `unpaused` completely when needed (i.e. `superPool` is hacked) because none of the functions in it use the `whenNotPaused` and `whenPaused` modifiers

Funds can be locked indefinitely in NukeFund.sol

Pause and unpause functions are inaccessible

Lack of slippage and deadline during withdraw and deposit

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

AccountingManager has no correct implementations of the core ERC-4626 functions `deposit`, `mint`, `withdraw` and `redeem`

Lack of Slippage Controls in retrieveTokensForWithdraw Function

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

The `BURNER` cannot burn tokens from accounts not KYC verified due to the check in `_beforeTokenTransfer`.

V3Vault is not ERC-4626 compliant

PrincipalToken is not ERC-5095 compliant

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

There is no way to liquidate a position if it breaches maxDebtPerCollateralToken value creating bad debt.

`ODSafeManager#allowSAFE()` cannot be executed either by the proxy contract or any other address.