The reward per token stored can be prevented from being updated

malicious user can extend the reward duration by calling `notifyRewardAmount`

Incorrect accounting of `LaunchToken` with `CurrencyToken` in `updateParticipation`

Users cannot claim rewards for the whole distribution period.

`_lockedETH` is never decremented on the cancellation of a raffle.

TokenManager - Unlimited withdraw

`mulDiv()` can round down to 0 in realistic cases, allowing for tax avoidance

incorrect price for negative ticks due to lack of rounding down

`updateIRMParams` does not call `applyInterestForToken` before updating `irmParams` which leads to incorrect calculation of interest rate for subsequent trades.

Liquidity manipulation is possible when trading

Vaults can become immune from liquidation by setting `vault.recipient` to a blacklisted quote token address

Chainlink's `latestRoundData` might return stale or incorrect results

`PendleConnector` incorrectly sends the redeemed `PT` tokens to the market instead of the

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

Numerous errors when calculating the TVL for the MorphoBlue connector

In Dolomite, when opening a borrow position, the holding position in the Registry will never be updated due to the removePosition flag being set to true

LP tokens from Boosted Positions are not included in the TVL calculation of a position held by the MaverickConnector

Withdrawals in AccountManager are prone to DOS attacks.

The total deposit amount limit in `AccountingManager.sol` can be bypassed

Missing calls to `_updateTokenInRegistry` leads to incorrect state of tokens in registry

Incorrect modifier condition

`AccountingManager` contract's `previewDeposit`, `previewMint`, `previewWithdraw`, and `previewRedeem` functions are not compliant with EIP-4626 standard

Extra rewards are not updated in curve connector when harvestConvexRewards is called

Camelot and Aerodrome Connector TVL susceptible to manipulation attack

Using the same heartbeat for multiple price feeds

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

`deposit` function in `SpotHedgeBaseMaker` and `OracleMaker` is prone to slippage

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

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

Can mint NFT with the desired attributes by reverting transaction

In `settleFundingFees`, `_globalPositions.marginDepositedTotal` can be assigned a wrong value because of improper comparisons.

Missing deadline check allow pending transactions to be maliciously executed

Fees are hardcoded to 3000 in ExactInputSingleParams

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

Test addresses and incorrect interface in code prevent integration with UniswapV3 and Camelot

Decimal Limitation in CamelotRelayer and UniV3Relayer Contract Deployment

If `dt` is not updated accurately then `timeWeightedWeeklyPositionInRangeConcLiquidity_` might be updated incorrectly.

Malicious lender can prevent borrowers from repaying their loans.

`rollLoan` function can be called by anyone.

Sandwich attack to steal all ERC-20 tokens in the Fees contract

Token spending by Uniswap router doesn't get approved

Hardcoded Router Address May Cause Token Lockup in Non-Standard Networks

The `borrow` and `refinance` functions can be front-run by the pool lender to set high interest rates

No expiration deadline leads to losing a lot of funds

Fixed fee level is used when swap tokens on Uniswap

Pragma non-specification can lead to non-functional / corrupted contract when deployed on Arbitrum

Some ERC20 tokens would revert on zero value fee transfers.

Rounding error risk in borrow() function in Lender.sol

Cannot use `_burn` Function in Beedle.sol Contract

Uncheck Arithmetic where overflow/underflow impossible

staleCheckLatestRoundData() does not check the status of the Arbitrum sequencer in Chainlink feeds.

DSC protocol can consume stale price data or cannot operate on some EVM chains

Chainlink oracle will return the wrong price if the aggregator hits `minAnswer`

All of the USD pair price feeds doesn't have 8 decimals

Pragma isn't specified correctly which can lead to nonfunction/damaged contract when deployed on Arbitrum

`++i`/`i++` should be `unchecked{++i}`/`unchecked{i++}` when it is not possible for them to overflow, as is the case when used in `for`- and `while`-loops

Contract Can Be Deployed Without Funds.

IVT tokens can be minted many times by calling `initializeDistributionRecord` several times.

`_setTotal` function in `CrosschainDistributor` will revert

`Vault.mintYieldFee` FUNCTION CAN BE CALLED BY ANYONE TO MINT `Vault Shares` TO ANY RECIPIENT ADDRESS

deposit function does not check for the `maxMint` amount.

More checks needed for Chainlink price feed return values

`getQuoteAtTick` uses `slot0` to calculate prices, which can be manipulated.

Oracle return values are not being checked.

No checks for whether Arbitrum sequencer is down

`mintRebalancer` and `burnRebalancer` can be called by anyone.

No slippage parameter in `UniV3SwapInput` function

Wrong addresses are used in Oracle contracts.

Using `slot0` to calculate prices can be manipulated.

Chainlink Oracle return values are not being checked.

Club owner can mint more players than _maxGenerationId

Wrong treasury address set in changeTreasury function in VaultFactoryV2 contract