Attacker can DOS liquidity migration in LiquidityManager.sol

Fee Recipient Shares Cannot Be Decreased When Total Fee recipients’s share is at Max Limit

Refund Underflow in Swap Refund Logic Leading to Locked Funds

rebalanceVaultsAssets incorrectly accounts vaults' depositedUsdc

Slight miscalculation in maxAmountsIn for Admin Fee Logic in UpliftOnlyExample::onAfterRemoveLiquidity Causes Lock of All Funds

formula Deviation from White Paper and Weighted Pool `performUpdate` unintended revert

Inconsistent timestamp storage when the LPNFT is transferred.

Liquidity Removal Reverts in `onAfterRemoveLiquidity` Callback Triggered by `removeLiquidityProportional`

Users can claim more that their actual allotment

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Incorrect referral fee calculations

Malicious User Can Front-Run and Steal Token Claims in `VVVVCTokenDistributor.claim()` Function.

Malicious lender can delete all lend offers.

Borrowers will overpay fees when extending loans.

Extending loan will revert due to the unused variable.

Rounding error in `DebitaIncentives.claimIncentives()` function.

Withdrawal fee for UsualX vault will be mis-calculated.

Deleted address can still perform actions allowed to undeleted addresses.

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

Contracts of the codebase will not strictly compliant with the ERC-1504.

Users will pay less fee than it should be.

Remove splitter will always revert if there are some rewards left on splitter contract

`Listings.relist()` function doesn't set `listing.created` as `block.timestamp`.

`TaxCalculator.calculateCompoundedFactor()` function inflate the compounded factor by 10 times.

User can avoid protected listing fee.

User can pay less protected listing fees.

Attacker can lock shutdown voters' collectionTokens forever.

User can unlock protected listing without paying any fee.

Attacker can take out user's repaid protected listing NFT with only `1 ether`.

Attacker can lock all ethers after shutdown executed and collection liquidation completed.

Attacker can disable `CollectionShutdown.preventShutdown()` function.

Beneficiary will lose unclaimed fees.

User may lose fund when modify listings.

Anyone can manipulate user nonce (nonce_manager) in settlement contract

SettlementSignatureVerifier is missing check for duplicate validator signatures

`shareBalance` bloating eventually blocks curator rewards distribution

Refunds sent to incorrect addresses in certain cases

Wrong calculation of supply balance and debt balance when withdraw and repay.

The protocol considers shares as amount when liquidation.

The protocol updates interest rates of collateral wrongly when liquidation.

Partial repayment is reverted because of rounding error.

Allocator will not be able to withdraw all assets from pool.

`FjordAuction` incorrect `block.timestamp` check allows users to bid after calling `auctionEnd` to claim more tokens than they should

Ethers of refunded amount for canceled raffle will be locked for the next raffles.

Attacker can set prize manager address of CCIP message as whatever he wants.

Admin can't revoke role.

SuperPool doesn't strictly comply with ERC-4626.

Incorrect set up and logic of `referralInfoMap` in `SystemConfig::updateReferrerInfo` function

TokenManager - Unlimited withdraw

Native token withdrawal fails until manually approved

[H-4] The function `PreMarkets::listOffer` charges an incorrect collateral amount, allowing users to manipulating collateral rates and drain the protocol's funds

`LiquidationBranch::checkLiquidatableAccounts()` executes `for` loop with wrong values, causing array out of bounds to be recovered, the program will not work as expected

Wrong parameter passed in `TradingAccount::deductAccountMargin` function that results in excess margin withdrawal

A malicious user can use voting power doubly.

`Voting` is always reverted when it has `bribes` to notify.

Remained rewards for period which is not voted can be freezed to `BribeRewarder`.

Total LUM rewards may be distributed for exeeding the `_lumPerSecond`.

`MlumStaking.sol#addToPosition` function has error in calculating the average lock duration.

`MlumStaking.sol#harvestPositionsTo` function doesn't function properly.

An attacker can acquire much share of rewards by sandwiching transaction which transfers rewards to `MlumStaking`.

The `lockMultiplier` can be decreased unexpectedly by `renewLockPosition`.

Anyone can create bribe rewarder.

The claimable amount of Flow token for paused gauge will be locked forever.

`Voter.sol#replaceFactory` function has errors in validity check.

Vultisig whitelisting can be bypassed by anyone

`claim` function lacks slippage controls for `amount0` and `amount1` returned by `pool.burn` function call

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

Users can not to buy/sell minimum credit allowed due to exactAmountIn condition

The condition check of function `DrawManager.sol#canStartDraw` is wrong.

User with two or more cross margin positions can update all positions from balance margin at a time.

Attacker can inflate stake rewards as he wants.

Keeper couldn't recognize the loss of order execution fee.

Depositor may deposit in excess of `collateralUserCap`.

Incorrect withdraw queue balance in TVL calculation

Deposits will always revert if the amount being deposited is less than the bufferToFill value

Lack of slippage and deadline during withdraw and deposit

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

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

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

It may not be consistent in calculating the Reward compensation for LPs.

The 5% ZVE Token is not distributed to the ITO participants.

`ZivoeTranches#rewardZVEJuniorDeposit` function miscalculates the reward when the ratio traverses lower/upper bound.

The `OCL_ZVE.sol#pushToLockerMulti` function call can often fail.

`SettleLongPremium` is incorrectly implemented: premium should be deducted instead of added

Wrong leg `chunkKey` calculation in `haircutPremia` function

`DailyLendIncreaseLimitLeft` and `dailyDebtIncreaseLimitLeft` are not adjusted accurately.

Users can lend and borrow above allowed limitations

User's attempt to deposit & withdraw reverts due to the calculation style inside `_calculateShares()`

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

Distribution can be bricked, and double claims by a few holders are possible when owner calls `LiquidInfrastructureERC20::setDistributableERC20s`

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

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

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

Erroneous probability calculation in physical attributes can lead to significant issues

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

OperationalStaking.sol has rounding errors.

Attacker can sell a position which is pending to close.

An attacker can steal other users' entries and dominate a round.

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

THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A `decreaseShareAmount` VALUE SUCH THAT THE `virtualRewardsToRemove` IS ROUNDED DOWN TO ZERO

When forming POL the DAO will end up stucked with DAI and USDS tokens that cannot handle.

DOS of proposals by abusing ballot names without important parameters

JUSDBankStorage.sol#accrueRate function has an error in calculating the tRate.

Funding.sol#requestWithdraw function has an error.

Unauthorized Access to setCurves Function

Protocol and referral fee would be permanently stuck in the Curves contract when selling a token

onBalanceChange causes previously unclaimed rewards to be cleared

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete

VotingEscrowTruf.sol#migrateVestingLock: does not recover user's unclaimed staking reword.

`ERC20TokenEmitter::buyToken` function mints more tokens to users than it should do

MaxHeap.sol: Already extracted tokenId may be extracted again.

Since buyToken function has no slippage checking, users can get less tokens than expected when they buy tokens directly

Users staking via the `SurplusGuildMinter` can be immediately slashed when staking into a gauge that had previously incurred a loss

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

Replay attack to suddenly offboard the re-onboarded lending term

OlympusPrice.v2.sol#storePrice: The moving average prices are used recursively for the calculation of the moving average price.

Wrong calculation of ProtocolOwnedLiquidityOhm in BunnySupply.

OlympusSupply.getReservesByCategory function always revert for some categories.

Incorrect calculation of the BunniTokenPrice.

The check for deviation in Deviation.sol is not valid.

Price can be miscalculated.

The first founder is to be allocated less tokens than other founders.

It can be impossible to settle the auction.

Protocol mints less rsETH on deposit than intended

Update in strategy will cause wrong issuance of shares

Attacker can drain all ETH from AuctionDemo when block.timestamp == auctionEndTime

On a Linear or Exponential Descending Sale Model, a user that mint on the last `block.timestamp` mint at an unexpected price.

The total amount of credits per `allocator` can be exceed `maxVoiceCreditsPerAllocator` in `QVSimpleStrategy`.

Allocation can be set invalid by incorrect calculation for quadratic voting strategies in QVBaseStrategy.

Function `_distribute` of `RFPSimpleStrategy.sol` would be reverted due to the coding error.

The settle feature will be broken if attacker arbitrarily transfer collateral tokens to the PerpetualAtlanticVaultLP

V3Proxy swapTokensForExactETH does not send back to the caller the unused input tokens

Malicious beneficiary will get more voting power than normal.

Change price calculation in BoundedStepwiseExponentialPriceAdapter.getPrice() is incorrect.