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

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

Users can claim more that their actual allotment

Incorrect listing type validation bypasses enforcement of minimum purchase amount

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

In Starknet already processed messages can be re-submitted and by anyone

A cross-chain message can be initiated with invalid parameters

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

Excessive Authority Granted to Managers in the `ckr_btc.cairo` Contract Presents Significant Management Risks

`get_fee_growth_inside` in `tick.rs` should allow for `underflow`/`overflow` but doesn't

No related function to set fee_protocol

Wrong minting logic based on total token count across generations

There is no slippage check in the `nuke()` function.

Forger Entities can forge more times than intended

Pause and unpause functions are inaccessible

NFTs mature too slowly under default settings.

`Golden God` Tokens can be minted twice per generation

WhenNotPaused modifier in the CDPVault can be bypassed by users

Malicious actor can abuse the minimum shares check in `StakingLPEth` and cause DoS or locked funds for the last user that withdraws

`PendleLPOracle::_fetchAndValidate` uses Chainlink's deprecated `answeredInRound`

Single plot can be occupied by multiple renters

The `refundAccount` is erroneously set to `msg.sender` instead of `tx.origin` when `refundAccount` specified as `address(0)`

WhenNotPaused modifier in the CDPVault can be bypassed by users

Malicious actor can abuse the minimum shares check in `StakingLPEth` and cause DoS or locked funds for the last user that withdraws

`PendleLPOracle::_fetchAndValidate` uses Chainlink's deprecated `answeredInRound`

Incorrect withdraw queue balance in TVL calculation

Withdrawals of rebasing tokens can lead to insolvency and unfair distribution of protocol reserves

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

stETH/ETH Feed being used opens up to 2 way deposit<->withdrawal arbitrage

`AccountingManager::resetMiddle` will not behave as expected

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

`depositQueue.queue` in `AccountingManager` can be flooded causing a DoS

Using the same heartbeat for multiple price feeds

Inability to perform partial liquidations allows huge positions to accrue bad debt in the system

Value of kerosene can be manipulated to force liquidate users

No incentive to liquidate when CR <= 1 as asset received < dyad burned

Liquidation bonus logic is wrong

RioLRTWithdrawalQueue.settleEpochFromEigenLayer does not increase the current epoch, resulting in a loop while rebalancing.

Leak of value when waiting for assets to be withdrawn after requesting withdrawal

Holders array can be manipulated by transferring or burning with amount 0, stealing rewards or bricking certain functions

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

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

NFTs can be transferred even if StakeAtRisk remains, so the user's win cannot be recorded on the chain due to underflow, and can recover past losses that can't be recovered(steal protocol's token)

Can mint NFT with the desired attributes by reverting transaction

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

Due to missing checks on minimum gas passed through LayerZero, executions can fail on the destination chain

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.

Potential loss of capital due to fixed fee calculations

Missing access control on UTB:receiveFromBridge allows UTB swaps to be executed without spending bridge fees while bypassing fee/swap instruction signature verification

Users can use the protocol freely without paying any fees by calling the `DecentEthRouter::bridgeWithPayload()` function directly.

First depositor can break staking-rewards accounting

changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehand

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

Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

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

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

Unauthorized Access to setCurves Function

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

The `refundAccount` is erroneously set to `msg.sender` instead of `tx.origin` when `refundAccount` specified as `address(0)`

The quorumVotes can be bypassed

CultureIndex.sol#dropTopVotedPiece() - Malicious user can manipulate topVotedPiece to DoS the whole CultureIndex and AuctionHouse

It may be possible to DoS AuctionHouse by specifying malicious creators

No slippage protection for Market functions

The price of rsEHT could be manipulated by the first staker

Bidder Funds Can Become Unrecoverable Due to 1 second Overlap in `participateToAuction()` and `claimAuction()`

Auction payout goes to AuctionDemo contract owner, not the token owner

users still forced to follow previously set cooldownDuration even when cooldown is off (set to zero) before unstaking

Soft Restricted Staker Role can withdraw stUSDe for USDe

Malicious users can front-run to cause a denial of service (DoS) for StakedUSDe due to MinShares checks

Obtaining sqrtPriceX96 from slot0 may be dangerous if liquidity is low

Inaccurate swap amount calculation in ReLP leads to stuck tokens and lost liquidity

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

boreWell can be frontrun/DoS-d

Incorrect function call in LybraRETHVault's getAssetPrice

Understatement of `poolTotalPeUSDCirculation` amounts due to incorrect accounting after function `_repay` is called

Chainlink's `latestRoundData` may return stale or incorrect result

no bidder has incentive to bid the Auction except doing last-minute MEV due to fixed endBlock

[M-01] Some functions in Talos contracts does not allow user to supply slippage and deadline, which may cause swap revert

Lack of slippage protection can lead to significant loss of user funds

getOwnValuation() calculation may overflow

Using slot(0) to derive price is susceptible to price manipulations

No slippage check when swapping through Uniswap

StableOracleWBTC.sol does not use the WBTC/USD pricefeed

getPriceUSD() in StableOracleDAI.sol does not calculate DAI price in terms of USD properly

Chainlink's latestRoundData Might Return Stale Results

ShortFall contract might transfer incorrect amount of tokens to the highest bidder.

Bad Debt in PoolLens.sol#getPoolBadDebt() is not calculated correctly in USD

It's possible to borrow, redeem, transfer tokens and exit markets with outdated collateral prices and borrow interest

Use safetransfer instead of transfer for ERC20 tokens

Round completeness not check in ChainlinkAdapterOracle#latestRoundData

need alternative ways for fund transfer in `end()` to prevent DoS

Challengers and bidders can collude together to restrict the minting of position owner

Transaction revert if the baseToken does not support 0 value transfer when charging changeFee

Calling `Position._marketBuy` and `Position._marketSell` functions that calculate `_fee` by dividing by `10000` can cause incorrect calculations

Staking, unstaking and rebalanceToWeight can be sandwiched (Mainly rETH deposit )

`WstEth` derivative assumes a ~1=1 peg of stETH to ETH

Non-ideal rETH/WETH pool used pays unnecessary fees

DoS due to external call failure

Lack of deadline for uniswap AMM

Chainlink oracle's price check may be insufficient validated

The buyer of the ticket could be front-runned by the ticket owner who claims the rewards before the ticket's NFT is traded

Protocol assumes that all future collateral will have 18 decimal places

First depositor can break minting of shares

If the collateral token and loan token does not have the same decimal places, collateral ratio will be broken

ProtectionPool#withdraw does not check the cycle state

Possible DoS of functions by exceeding maximum gas limit when protectionInfo array is too large

latestRoundData() has no check for round completeness

IchiLpOracle will malfunction if token0 or token1 decimal is not 18

First vault depositor can steal other's assets

Staking rewards can be drained

Incorrect Reward Duration After Change in Reward Speed in MultiRewardStaking

Protocol fees can be withdrawn multiple times in `Erc20Quest`

Funds can be stuck due to wrong order of operations

Users may not claim Erc1155 rewards when the Quest has ended

User may loose rewards if the receipt is minted after quest end time

Use safeTransfer and safeTransferFrom instead of transfer and transferFrom for ERC20 contracts

Loss of user funds when completing CASH redemptions

SmartAccount.sol is intended to be upgradable but inherits from contracts that contain storage and no gaps

methods used by EntryPoint has `onlyOwner` modifier

Griefing attacks on `handleOps` and `multiSend` logic

Anyone can call PerpDepository.rebalance()

PerpDepository._rebalanceNegativePnlWithSwap uses wrong parameter in quoteAmount.fromDemicalToDecmial()

PerpDepository.getDebtValue() is not used or checked when redeeming collateral for UXD

Clearing house fees are stored in PerpDepository() but not paid

Inflation of ggAVAX share price by first depositor

Coding logic of the contract upgrading renders upgrading contracts impractical

Centralization risks: owner can freeze withdraws and use timelock to steal all funds

Underlying assets stealing in `AutoPxGmx` and `AutoPxGlp` via share price manipulation

Unsafe usage of ERC20 .transfer

address.call{value:x}() should be used instead of payable.transfer()

First depositor of sGLP token can break share calculations

Protocol withdrawals of collateral can be unexpectedly locked if governance sets the `collateralFactorBps` to 0.

Chainlink oracle data feed is not sufficiently validated and can return stale `price`

Bidder's payment is not refunded if Auction is cancelled prematurely via cancelAuction()

AuctionHouse firstBidTime is set to block.timestamp which breaks the calculation of the Auction's total duration

The calculation of extended Auction timing when a bidder calls createBid() is incorrect

Wrong slashing calculation rewards for operator that did not do his job

Vouchers that vouches first may not get their stake locked or unlocked sequentially according to updateLocked() if cancelVouch() is called

Supply cap of VariableSupplyERC20Token is not properly enforced