Wrong handling of ERC20 denoms in `ERC20Keeper::BurnCoins`

setBeforeSendHook can never delete an existing store due to vulnerable validate

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

Challenger misses discrepancy events, allowing executors to perform malicious actions

Users can DOS the token deposits for any future bridges

Apply oracle update doesn't check for duplicate validator votes

Stable swap pools don't properly handle assets with different decimals, forcing LPs to receive wrong shares

User cannot claim rewards or close_position, due to vulnerable division by zero handling

Protocol allows creating broken tricrypto CPMM pools

Logical error in `validate_fees_are_paid` can cause a DoS or allow users to bypass fees if `denom_creation_fee` includes multiple coins including `pool_creation_fee` and the user attempts to pay all fees using only `pool_creation_fee`

Multi-token stableswap pools allow 0 liquidity for tokens, creating bricked pools

Block gas limit can be hit due to loop depth

Farms can be created to start in past epochs

`compute_offer_amount` floors the `offer_amount` when simulating constant product reversed swaps, leading to unexpected results

`query_reverse_simulation` doesn't account for extra fees when simulating stable reversed swaps

Single sided liquidity can't be used to lock LP tokens in the farm manager

Penalty fees can be shared among future farms or expired farms, risks of exploits

`withdraw_liquidity` lacks slippage protection

Wrong handling of call data check indices, forcing it sometimes to revert

`decreaseLever` uses incorrect position address when withdrawing

`Flashlender.sol#flashLoan()` should use `mintProfit()` to mint fees. The current implemetation may lead to locked up WETH in PoolV3.

`CDPVault.sol#liquidatePositionBadDebt()` does correctly handle profit and loss

PositionAction.decreaseLever() fails to consider the loan fee in Flashlender when calculating loanAmount, as a result, the functionanlity will not work when protocolFee != 0.

WhenNotPaused modifier in the CDPVault can be bypassed by users

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

`PoolAction::_balancerExit` returns wrong token out amount

`PositionAction4626::_onDecreaseLever` wrongly updates `tokenOut` forcing user's funds to be stuck in the position action contract

`PoolAction::updateLeverJoin` wrongly updates `assetsIn` array, leading to `PositionAction4626::_onIncreaseLever` to always revert

`PositionAction4626::increaseLever` will always revert

`SwapAction::getSwapToken` will return wrong swap token for balancer EXACT_OUT swaps

Wrong repayment amount used in `PositionAction::_repay`, forcing users to unexpectedly lose funds

Invalid handling of risdual amount in `PositionAction::onCreditFlashLoan`, forcing it to revert

Invalid handling of flash loan fees in `PositionAction::onCreditFlashLoan`, forcing it to always revert

`LidoVault::vaultEndedWithdraw` doesn't take into consideration income withdrawals before slashing, blocking variable users from withdrwing their income

Users can't reclaim their votes after canceling a collection shutdown process

`Listings::relist` wrongly resolves the listings tax for liquidation listings, allowing users to steal other users' paid tax

`Listings::relist` is not reseting the listing's created date, allowing users to bypass listing fees

`Locker::isListing` doesn't check if the token is unlocked and pending withdrawal, allowing users to steal unlocked tokens

Users can cancel listings even after having them being reserved

Wrong comparison value used in `UniswapImplementation::beforeSwap` forcing swaps to revert

Price limit is used as the price range in internal swaps, causing swap TXs to revert

`CollectionShutdown::execute` is not resetting `shutdownVotes`, blocking future shutdown processes

`PositionBalanceConfiguration::getSupplyBalance` returns shares instead of assets, forcing curated vault depositors to lose funds

Total shares is wrongly subtracted when minting to treasury, blocking users from withdrawing their funds

Wrong debt amount used in `LiquidationLogic::_calculateDebt`, causing liquidation to always result in wrong results

Supply pool reserves are not updated on an early stage, leading to incorrect calculations of shares and fees

`LiquidationLogic::_repayDebtTokens` is wrongly setting `nextDebtShares` to the burnt shares, messing up all loans accumulated debt

Profit is transferred to the treasury without checking if there's enough balance, blocking users from withdrawing their funds

Using the same heartbeat for multiple price feeds, causing DOS

Super pool uses `ERC20.approve` instead of safe approvals, causing it to always revert on some ERC20s

`decreaseLever` uses incorrect position address when withdrawing

`Flashlender.sol#flashLoan()` should use `mintProfit()` to mint fees. The current implemetation may lead to locked up WETH in PoolV3.

`CDPVault.sol#liquidatePositionBadDebt()` does correctly handle profit and loss

PositionAction.decreaseLever() fails to consider the loan fee in Flashlender when calculating loanAmount, as a result, the functionanlity will not work when protocolFee != 0.

WhenNotPaused modifier in the CDPVault can be bypassed by users

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

`PoolAction::_balancerExit` returns wrong token out amount

`PositionAction4626::_onDecreaseLever` wrongly updates `tokenOut` forcing user's funds to be stuck in the position action contract

`PoolAction::updateLeverJoin` wrongly updates `assetsIn` array, leading to `PositionAction4626::_onIncreaseLever` to always revert

`PositionAction4626::increaseLever` will always revert

`SwapAction::getSwapToken` will return wrong swap token for balancer EXACT_OUT swaps

Wrong repayment amount used in `PositionAction::_repay`, forcing users to unexpectedly lose funds

Invalid handling of risdual amount in `PositionAction::onCreditFlashLoan`, forcing it to revert

Invalid handling of flash loan fees in `PositionAction::onCreditFlashLoan`, forcing it to always revert

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

When `sellCreditMarket()` is called to sell credit for a specific cash amount, the protocol might receive a lower swapping fee than expected.

Fragmentation fee is not taken if user compensates with newly created position

Borrower is not able to compensate his lenders if he is underwater

Credit can be sold forcibly as `forSale` setting can be ignored via Compensate

withdraw() users may can't withdraw underlyingBorrowToken properly

`BalancerConnector::_getPositionTVL` is calculated incorrectly

`Registry.sol#updateHoldingPosition` remove position logic is incorrect: should use `ownerConnector` instead of `calculatorConnector` when calculating holdingPositionId.

`SNXConnector.sol` TVL calculation is incorrect.

`AccountingManager::resetMiddle` will not behave as expected

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

Incomplete TVL Calculation in `AerodromeConnector::_getPositionTVL` Function.

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

`NoyaValueOracle.getValue` returns an incorrect price when a multi-token route is used

Invalid handling of holding positions in `DolomiteConnector::transferBetweenAccounts`

Invalid calculation of position TVL in Pendle connector

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

It is possible to open insolvent position is Silo connector, due to missing check in borrow function

SiloConnector `_getPositionTVL` miscalculate the TVL position

`CurveConnector.sol#depositIntoConvexBooster` does not keep track of TVL if `stake == false`

The `TVLHelper.sol#getTVL` function is DOSed by the `under collateralized connector`, and as a result, many parts of the protocol may be DOS.

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

The modifier `onlyExistingRoute` works incorrectly

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

Incorrect Return Value in `CompoundConnector.getBorrowBalanceInBase()` Affecting TVL Calculation

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

Incorrect modifier condition

FullMath libabry is missing `unchecked` blocks, leading to DOS protocol's TVL and UniswapValueOracle

Registry deletes liquidity positions without verifying complete withdrawal.

Kerosene collateral is not being moved on liquidation, exposing liquidators to loss

Users can get their Kerosene stuck until TVL becomes greater than Dyad's supply

User can get their Kerosene stuck because of an invalid check on withdraw

Unable to withdraw Kerosene from `vaultmanagerv2::withdraw` as it expects a `vault.oracle()` method which is missing in Kerosene vaults

Value of kerosene can be manipulated to force liquidate users

Incorrect deployment / missing contract will break functionality

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

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

dailyDebtIncreaseLimitLeft is not updated in liquidate().

Tokens can't be removed as a collateral without breaking liquidations and other core functions

V3Oracle susceptible to price manipulation

Repayments and liquidations can be forced to revert by an attacker that repays miniscule amount of shares

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

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

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

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

FighterFarm:: reroll won't work for nft id greator than 255 due to input limited to uint8

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)

When borrowers repay USDS, it is sent to the wrong address, allowing anyone to burn Protocol Owned Liquidity and build bad debt for USDS

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

Adversary can prevent updating price feed addresses by creating poisonous proposals ending in `_confirm`

Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST

Anyone can steal all distributed rewards

Re-triggering the `canOffboard[term]` flag to bypass the DAO vote of the lending term offboarding mechanism

Positions that have `veCVG` amount block users from extending their lock amount/time in the last cycle

Attacker can reenter to mint all the collection supply

Soft Restricted Staker Role can withdraw stUSDe for USDe

Borrower can use Refinance to cancel auctions so they can extend their loan indefinitely

During refinance() new Pool balance debt is subtracted twice

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Using forged/fake lending pools to steal any loan opening for auction

Stealing any loan opening for auction through others' lending pool

Malicious lender can increment the loan interest using the auction process