Malicious lender can prevent borrower from repayment due to try/catch block revert

Using original principal amount as due amount inside `liquidateDefaultedLoanWithIncentive` breaks contract accounting leading to lost assets/broken functionalities

Attacker can revoke any user from a market

Not updating state before making custom external call can cause borrower's to loose assets due to re-entrancy

Using `.approve` will cause bidding to revert in LenderCommitmentGroup_Smart.sol

Repayer can brick lending functionality of `LenderCommitmentGroup_Smart` by repaying excess

Tokens that revert of zero value transfers can cause reverts on liquidation

EMI calculation is flawed

User's can seize more assets during liquidation by using type(uint).max

Formula used for minimum required collateral value is flawed

Superpool doesn't handle USDT due to abi decoding

Attacker can inflict losses to other Superpool user's during a bad debt liquidation depending on the deposit/withdraw queue order

`maxWithdraw` deviates from `ERC4626` spec

`ChainlinkOracle` doesn't validate for minAnswer/maxAnswer

Setting `minDebt` and `minBorrow` to low values can cause protocol to accrue bad debt

Planned large liquidation fees will make liquidation not profitable causing bad debt

New depositors can loose their assets due to existing shares when totalAssets is 0 following a bad debt rebalance

User's can create non-liquidateable positions by leveraging `rebalanceBadDebt` to decrease share price

`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.

Debt position interest is compounded while pool interest is simple causing inconsistency b/w `expectedLiquidity_` and `availableLiquidity_`

Emission schedule is not followed

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

Incorrect address is used as `spender` for ERC20 permit signature verification

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

In CDPVault::liquidatePositionBadDebt(), the calculation of `loss` is incorrect.

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

Incorrect calculation of `newCumulativeIndex` in function `calcDecrease`

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

`PositionAction4626::increaseLever` will always revert

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

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

`PositionAction.sol#onCreditFlashLoan` may have leftover tokens after conducting `leverParams.auxSwap`.

Predefined amount parameter can challange allocation to Obol validators

`ratiosX96Value` is rounded down

1:1 price is assumed b/w stETH and WETH

Reward allocation can result in allocation of more than 100% of available reserves

User's might be able to claim their prizes even after shutdown

`maxDeposit` doesn't comply with ERC-4626

`maxRedeem` doesn't comply with ERC-4626

Incorrect implementation of `drawTimeout`

Using `feePerClaim` for slippage control could result in claimer's making losses during claims

Can start draw will return incorrectly

Users can setup hooks to control the expannsion of tiers

Lot id is always set to 0 for new auctions

Gas is not configured to be claimable in Blast

Downcasting to uint96 can cause assets to be lost for some tokens

Lack of max field value check for coordinates allows bricking the decryption

Incorrect `prefundingRefund` calculation will disallow claiming

Overly restrictive check for claimBid function disallows bidder's from claiming

Inconsistent timestamp usage across `_revertIfLotActive` and `_revertIfLotConcluded`

User's can be grieved by not submitting the private key

Bidder's payout claim could fail due to validation checks in LinearVesting

Inaccurate value is used for partial fill quote amount when calculating fees

Remaining funds of FMAP auctions cannot be recovered once auction is concluded

Deactivating operators doesn't clear it's strategy allocations

Epoch is not incremented when current epoch settlement is queued

Validator keys are loaded incorrectly from storage to memory

Operators can steal ETH by front running validator registration

Operators undelegating via EigenLayer is not handled

Shares associated with operator exits are not marked unwithdrawable

Min excess scrape amount can cause unused ETH and possbily lost LRT tokens for users

Strict check for precalculated shares to equal the actual shares received will revert often due to rounding in eigenlayer

TranferETH gas limitation of 10k is not enough

Operators can cause verification of other operators to fail by verifying a validator that was added outside Rio

Withdrawals can be frozen by creating null deposits

Bonds created in year cross epoch's can lead to lost payouts

Wrong invocation of Whirpools's updateFeesAndRewards will cause it to always revert

Possible DOS when withdrawing liquidity from Solana Lockbox

Withdraw amount returned by `getLiquidityAmountsAndPositions` may be incorrect

lower decimal token as quote asset allows initial depositor to set QUOTE_TARGET to 0 always

Initial depositor can alter the reserve-target ratio to trade subsequent depositors tokens at lower prices

BunniPrice returns totalValue instead of pool token price

Incorrect ProtocolOwnedLiquidityOhm calculation due to inclusion of other user's reserves

Incorrect StablePool BPT price calculation

Pool manipulation check in BunniHelper is flawed as uncollected fees is used

Incorrect deviation check

Possible incorrect price for tokens in Balancer stable pool due to amplification parameter update

usage of totalSupply for newer balancer pools should be replaced with getActualSupply

Partial transfers are still possible, leading to incorrect storage updates, and the calculated account premiums will be significantly different from what they should be

Attacker can steal all fees from SFPM in pools with ERC777 tokens.

Premium owed can be calculated as a very big number due to reentrancy on uninitialized pools

removedLiquidity can be underflowed to lock other user's deposits

premia calculation can cause DOS

User's can attain unlimited `veCvg/mgCvg` voting power due to lack of duplication checks

Killing a gague can lead to bricking of the protocol

Incorrect slippage protection for sdt/cvgSdt exchange

Division difference can result in a revert when claiming treasury yield and excess rewards to some users

cvgRewards may be incorrectly calculated due to possible changes in gagueWeights and totalWeight

try-catch does not store the state when it is reverted

`GMXVault` can be blocked by a malicious actor

Withdraw function provides more funds to withdrawer

Incorrect slippage protection on deposits

The protocol will mint unnecessary fees if the vault is paused and reopened later.

The transfer of ERC-20 tokens with blacklist functionality in process functions can lead to stuck vaults

Incorrect depositable shortToken amount calculation in Delta neutral vaults

Front-Run Attacks Due Slippage Mishandling Lead to Total Losses For Depositors

A depositor of the GMXVault can bypass paying the fee when the depositor deposit into the GMXVault.

Borrower has no way to update `maxTotalSupply` of `market` or close market.

Borrowers can escape from paying half of the penalty fees by closing the market, and those remaining penalty fees will be covered by the lender who withdraws last

Pending withdrawal batch debt cannot be payed by the borrower until the cycle end

Users Lose Funds and Market Functionality Breaks When Market Reachs 65k Id

New orders can overwrite active orders when order id reaches 65000

Users can avoid liquidation while being under the primary liquidation ratio if on the last short record

Owner of a bad ShortRecord can front-run flagShort calls AND liquidateSecondary and prevent liquidation

Previous NFT owner can burn NFT from the new owner

Flag can be overriden by another user

User's can loose collateral when exiting a short

Order creation can run out of gas since relying on previous order matchtype

Secondary short liquidation reverts due to arithmetic underflow in volatile market conditions

Loss of precision in `twapPriceInEther` due to division before multiplication

Lack of Duplicate ID Check in combineShorts Function

The same signature can be used in different `distribution` implementation causing that the caller who owns the signature, can distribute on unauthorized implementations

The `digest` calculation in `deployProxyAndDistributeBySignature` does not follow EIP-712 specification

Owner can incorrectly pull funds from contests not yet expired

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

Lender can Sandwich a borrower to seize his collateral

Missing Events Emitting

Emitting incorrect event parameters

Multiple accesses of a mapping/array should use a local variable cache.

Uncheck Arithmetic where overflow/underflow impossible

Wrong comment in `setPool` function

Unwanted gas expenditure by recomputing already computed value

Theft of collateral tokens with fewer than 18 decimals

[H-01] Lack of emergency withdraw function when no arbiter is set

Use Openzeppelin Minimal Clones to Save a Lot of Gas