Maximum leverage can be exceeded due to insufficient positionLeverage calculation

The Deleverage Will apply twice on market USDtoken minting

Vaults weth reward is not distributed correctly

Unclaimed Rewards Loss Due to Missing Validation in `VaultRouterBranch.stake()`

Incorrect Debt Check in `CreditDelegationBranch::settleVaultsDebt` Function

Markets and vaults will not update their state until market fee is received, any deposits before market fee will not be reflected

Total market debt > 0 when credit deposits > netusdissuance which breaks key protocol logic

Incorrect calculation in CreditDelegationBranch::withdrawUsdTokenFromMarket allows attacker mint any amount of usdz

Incorrect vault debt validation logic in rebalanceVaultsAssets causes reverts

Vault accumulated values do not reflect market change correctly

rebalanceVaultAssets will revert with erc20 insufficient balance error

`_fillOrder` should update the vaults before deleveraging

Stuck tokens in `BalancerRouter`

Users will be able to manipulate redemptions because of flawed logic

`transferReserveToAuction` will always revert

Broken cAMM curve when `Collateral Level ≤ 1.2`

Users can perform fee manipulations to limit their fee exposure

A user will be able to always sabotage auctions

A user will be able to steal funds from the protocol by getting blacklisted

Users may not be able to claim their coupons in some cases

First depositor attack in CNumaToken and CNumaLst

`buyVotes` function will overcharge users with fee

`withdrawGraduatedMarketFunds` will try to send more eth than there actually is

An attacker could front-run user's claim and steal their tokens

Missing implementation to claim ERC1155 royalties

Bridging from L1 to L2 will always result in DOS

Wrong refund logic in Locker.sol `initializeCollection`

A collection will not be shutdown in an edge case

claimRoyalties will use wrong receiver

Availability of deposit invariant can be bypassed

`vestTokens` bug in MultiFeeDistribution.sol causes new incentives to erase previous incentives

There is a calculation error in AuraVault::redeem().

Directly sending dust token amount will slow down distribution in `MultiFeeDistribution.sol`

An infinite loop in `MultiFeeDistribution.sol` withdraw

Discrepency b/w the `lastRewadTime` and the `lastAllPoolUpdate` can allow for incorrect reward distribution to pools if `registerRewardDeposit` deposits less assets

Usage of `lastEligibleStatus` can cause user to miss out on rewards on `manualStopEmissionsFor` invocation

Users of a vault can steal other user's rewards when one vault's `lastRewardTime` differs from another vault's `lastRewardTime`

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

ChefIncentivesController caches endRewardTime, which is not required, and may cause issues during reward update.

Unclaimed rewards are not sent back to the briber in `BribeRewarder.sol`

Positions with expired locks can still vote and earn rewards

Wrong amount is used when calculation avgDuration in MlumStaking.sol

`harvestPositionsTo` will not work as expected

Lido withdraw limitation will brick the withdraw process in an edge case

`_splitWithdrawRequest` will make invalid withdraw requests in an edge case

Availability of deposit invariant can be bypassed

`vestTokens` bug in MultiFeeDistribution.sol causes new incentives to erase previous incentives

There is a calculation error in AuraVault::redeem().

Directly sending dust token amount will slow down distribution in `MultiFeeDistribution.sol`

An infinite loop in `MultiFeeDistribution.sol` withdraw

Discrepency b/w the `lastRewadTime` and the `lastAllPoolUpdate` can allow for incorrect reward distribution to pools if `registerRewardDeposit` deposits less assets

Usage of `lastEligibleStatus` can cause user to miss out on rewards on `manualStopEmissionsFor` invocation

Users of a vault can steal other user's rewards when one vault's `lastRewardTime` differs from another vault's `lastRewardTime`

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

ChefIncentivesController caches endRewardTime, which is not required, and may cause issues during reward update.

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

Attacker can increase the length of `withdrawQueue` by withdrawing 0 amount of tokens frequently

Balancer flashloan contract can be DOSed completely by sending 1 wei to it

Incorrect depositReward function slows down reward vesting

New auctions override old ones in `lotRouting` mapping

Bidders will not be able to claim bids

Some tokens will cause DOS of claimProceeds function

Malicious seller can cancel batch auction and freeze user's bids

All funds for the current lot will be frozen if seller does not give the private key

Users can drain the vesting contract with reentrancy

V3Utils.execute() does not have caller validation, leading to stolen NFT positions from users

Owner of a position can prevent liquidation due to the 'onERC721Received' callback

Protocol can be repeatedly gas griefed in `AutoRange` external call

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

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

ERC721 locking mechanism does not work

Users can mint as many `Flat.money Points` as they want