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

User can earn rewards by frontrunning the new rewards accumulation in Ron staking without actually delegating his tokens

Adversary can win proposals with voting power as low as 4%

Users can redeem more than permitted by manipulating the `collateralLevel` from `< 120%` to `> 120%` through donations.

`LeverageToken` holders can drain the pool.

`COLLATERAL_THRESHOLD` should be set to `125%` instead of `120%`.

When Creating and Redeeming, the Protocol Fee is Not Updated

`BalancerRouter.joinBalancerPool()` Doesn't Refund Remaining Tokens

When Redeeming `LeverageToken`, the Redemption Price is Unfairly Compared with `BondToken`'s Market Price

Once the total supply of `LeverageToken` reaches 0, it will never be minted again.

`Pool.getRedeemAmount()` Could Revert Due to Integer Underflow

In `transferVesting`, the `grantorVesting.releaseRate` is calculated incorrectly, which leads to the sender being able to unlock more tokens than were initially locked.

Users can claim more that their actual allotment

`SecondSwap_Marketplace` vesting listing order affects how much the vesting buyers can claim at a given step

Incorrect referral fee calculations

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Price Granularity Limited by Payment Token Decimals: Cannot List Tokens Cheaper than 0.000001 USDT

`buyFee` And `sellFee` Should Be Known Before Purchase

Underflow in `claimable` DOSing `claim` Function

Inflation Attack via Donations.

Before transferring `CToken`, the `accrueInterest()` function should be called first.

The `CNumaToken.leverageStrategy()` function reverts due to an improper check of the `principal` borrow amount.

Title: Incorrect implementation of `LenderCommitmentGroupShares._afterTokenTransfer()` may lead to DoS of `LenderCommitmentGroup_Smart`

Users can lower the interest rate by dividing a loan into multiple smaller loans

The `totalPrincipalTokensRepaid` and `totalInterestCollected` may not be updated even when funds are already transferred

Minting zero tokens when underlyingToken is not Ether in cashIn()

`LamboRebalanceOnUniswap::_getTokenInOut` formula used to compute rebalancing amount is wrong for a UniV3 pool

`sellQuote` and `buyQuote` are missing deadline check in `LamboVEthRouter`

The `MixOracle.getThePrice` function calculates the price incorrectly using the `TarotOracle.getResult` function as the TWAP price

The fee mechanisms for withdrawals and redemptions differ in the `UsualX` contract

Rewards are not updated for the removed allocations in the UsualSP.removeOriginalAllocation() function

The protocol can't collect reward tokens from the gauges of Velodrome and Aerodrome

The `V2AMO._mintAndSellBoost()` function does not work with Velodrome and Aerodrome

The `MasterAMO.initialize()` function should have the `onlyInitializing` modifier

The `BoostCore` contract lacks the ability to call certain functions of the incentive contracts, such as `clawback()` and `drawRaffle()`

`DoS` when creating boosts with `fee-on-transfer` tokens

The `api.burn` function should have cool down period

The protocol should consider the variance of quote tokens' price

Invalid Redstone oracle payload size prevents the protocol from working properly

Protocol incompatibility with smart contract wallets

Not decreasing oracle timestamp validation leads to DoS for protocol users

Incorrect `psmRa` in the `VaultLib._liquidatedLp()` function

The `DsFlashSwap.emptyReserve()` function incorrectly always returns 0

The `PsmLib.repurchase()` function doesn't increase the locked amount of `RA`

The `PsmLib.lvRedeemRaWithCtDs()` function doesn't decrease the locked amount of `RA`

The `FlashSwapRouter` mistakenly transfers certain `RA` tokens to `DS` buyers, resulting in financial losses for `lv` holders

Incorrect implementation of the modifier `LVDepositNotPaused()`

Reentrancy Vulnerability Allows Bypass of Cooldown, Leading to Unfair Reward Extraction Through Flash Loan

Exposed `_removeCredIdPerAddress` & `_addCredIdPerAddress` allows anyone to cause issues to current holders as well as upcoming ones

Refunds sent to incorrect addresses in certain cases

`executeLiquidationCall` utilizes wrong debt and collateral balance, disrupting whole liquidation process

`_repayDebtTokens` wrongly sets `vars.debtReserveCache.nextDebtShares` to incorrect value, leading to false `liquidityRate`, `borrowRate`

Wrong calculation of supply/debt balance of a position, disrupting core system functionalities

Incorrect deduction of `accruedToTreasuryShares` from totalSupply, causing loss of shares

The `CuratedVault.reallocate` function will fail when `allocation.assets == uint256.max`, even though this scenario is possible

The `SuperPool.reallocate()` function uses `approve` instead of `forceApprove`, which could lead to a revert

The `SuperPool._supplyToPools()` function only considers the state variable `poolCapFor` for the `SuperPool`'s `poolId`s, not the `poolCap` for the `Pool`'s `poolId`s

`mintToken()`, `mintWithBudget()`, and `forge()` in the `TraitForgeNft` Contract Will Fail Due to a Wrong Modifier Used in `EntropyGenerator.initializeAlphaIndices()`

The maximum number of generations is infinite

Number of entities in generation can surpass the 10k number

Wrong minting logic based on total token count across generations

Lack of Slippage Protection in Dynamic Pricing Mint Function

Funds can be locked indefinitely in NukeFund.sol

Incorrect `isApprovedForAll` check in the `NukeFund.nuke()` function.

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.

Discrepancy between nfts minted, price of nft when a generation changes & position of `_incrementGeneration()` inside `_mintInternal()` & `_mintNewEntity()`

Incorrect check against golden entropy value in the first two batches

Incorrectly assigned `decimal1` parameter upon decoding

A malicious attacker can make significant amount of reward token to be locked in `StakedEXA` by calling `harvest()` frequently

Anyone could call `harvest()` to extend the period finish time

In periods where `totalSupply = 0`, rewards will be locked forever in `StakeEXA` contract

Slashing NativeVault will lead to locked ETH for the users

A `DoS` on snapshots due to a rounding error in calculations.

Violation of Invariant Allowing DSSs to Slash Unregistered Operators

Delayed Slashing Window and Lack of Transparency for Pending Slashes Could Lead to Loss of Funds

A snapshot may face a permanent DoS if both a slashing event occurs in the NativeVault and the staker's validator is penalized.

`MIPS` - Incorrect implementation of SRAV instruction

Improper `msg.sender` check in the `BribeRewarder._modify()` function

In the `Voter.vote()` function, `lockDuration` is used incorrectly instead of the remaining time

Pending rewards need to be processed when `BribeRewarder.Deposit()` is called

`BribeRewarder` has no sweeping mechanism

Incorrect looping in the `BribeRewarder.claim()` function

The bribe reward mechanism is susceptible to exploitation by attackers

The `MlumStaking._requireOnlyOperatorOrOwnerOf()` function always returns `true`

The `MlumStaking.addToPosition()` function can be called even during the `emergencyUnlock` situation

Unclaimed rewards from the `emergencyWithdraw()` function remain permanently locked in the `MlumStaking` contract

The `BribeRewarder.fundAndBribe()` function will be reverted when using `fee-on-transfer` tokens

Loss of funds when gauge is paused

Vulnerability in `OptionTokenV4::exerciseLp` Function Enabling Malicious Lock Manipulation

Vultisig whitelisting can be bypassed by anyone

Most users won't be able to claim their share of Uniswap fees

Risk of Overpayment Due to Race Condition Between repay and liquidateWithReplacement Transactions

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.

The collateral remainder cap is incorrectly calculated during liquidation

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

`executeBuyCreditMarket` returns the wrong amount of cash and overestimates the amount that needs to be checked in the variable pool

Sandwich attack on loan fulfillment will temporarily prevent users from accessing their borrowed funds

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

Multicall does not work as intended

LiquidateWithReplacement does not charge swap fees on the borrower

When the `startBlock` is reset, the `lastRewardBlock`s of the pools are not updated accordingly

MinOut check should be added into the `Lock.earlyExitById` function

Adding liquidity can be `DoS`ed due to calculation mismatches

The `AccountFacet.batchUpdateAccountToken()` function is missing a caller authorization check

The `PositionMarginProcess.updateAllPositionFromBalanceMargin()` function is passing an incorrect parameter to the `updatePositionFromBalanceMargin()` function call

When withdrawing funds, the `PositionMarginProcess.updatePositionFromBalanceMargin()` function may not operate correctly

The `PositionMarginProcess.updatePositionFromBalanceMargin()` function calculates the `changeAmount` after modifying the storage variable

In the `AssetsProcess.deposit()` function, the user collateral cap check is performed using the outdated token amount, instead of the newly updated value

The `AssetsProcess.withdraw()` function doesn't update the `CommonData`

The `lossFee` is always 0 in the `GasProcess.processExecutionFee()` function

EETHAdapter.claimWithdrawal() uses a wrong condition and it doesn't work in most cases

Potential Incompatibility Issue with `PufETHAdapter::_stake` Function

MetapoolRouter.swapETHForYt() validates a wrong condition and this blocks intended workflow in most cases

Incorrect withdraw queue balance in TVL calculation

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

ETH withdrawals from EigenLayer always fail due to `OperatorDelegator`'s nonReentrant `receive()`

Incorrect calculation of queued withdrawals can deflate TVL and increase ezETH mint rate

Pending withdrawals prevent safe removal of collateral assets

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

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

Base tokens like USDT, USDC having different decimals on different chains can have their TVL updated incorrectly

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

The modifier `onlyExistingRoute` works incorrectly

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

`borrowAndSupply()` and `withdraw()` of `FraxConnector` should not be blocked when `maxLTV` of the Frax pair is 0

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

Incorrect modifier condition

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

Dust donation might DOS all connectors to create new holding positions, by preventing removing existing holding positions

A sandwich attack can potentially take most of the interest earned within the `LenderCommitmentGroup_Smart` contract

`_collateralAmount` is multiplied by `STANDARD_EXPANSION_FACTOR` unreasonably in the collateral check of the `LenderCommitmentGroup_Smart.acceptFundsForAcceptBid()` function.

The collateral tokens withdrawn `by liquidateDefaultedLoanWithIncentive()` will be frozen in the `LenderCommitmentGroup_Smart` contract.

The `LenderCommitmentGroup_Smart` contract cannot use USDT as its principal token, because `USDT.transfer()` does not return a boolean value.

The interest rate model should be improved in the `LenderCommitmentGroup_Smart`.

The newly added contracts will not work well on fee-on-transfer tokens, because there is no consideration for fee on transfer.

`FlashRolloverLoan_G5` cannot work well with some LenderCommitForwarders including the `SmartCommitmentForwarder` contract.

A user can borrow liquidity, even though `getPrincipalAmountAvailableToBorrow() < 0`.

Improper Reference in `FeeManager::_splitProtocolFee` Function

Incorrect Handling of Mint Fees in `Edition::mintBatch` Function

Attackers can revert `TitlesGraph.acknowledgeEdge()` by front-running

The function `TitlesGraph._setAcknowledged()` doesn't function properly due to its reliance on a memory variable

Design Flaw in `Edition::_refundExcess` Function Implementation

Improper handling of `msg.value` in the `Edition::mintBatch` function

Lack of Functionality for Granting or Revoking Important Roles in the `Edition` Contract

`Edition::transferWork` function doesn't change the receiver of the `_feeReceivers`

The function `updateFloatingDebt` must be called before every update of the `floatingAssets`, `floatingDebt` and `floatingBackupBorrowed` variables.

Anyone can allow others' assets to be used as collateral without approval of the asset owner because the `Market.borrow` function doesn't check if `assets > 0`

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Design flaw and mismanagement in vault licensing leads to double counting in collateral ratios and positions collateralized entirely with kerosine

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

Missing enough exogeneous collateral check in `VaultManagerV2::liquidate` makes the liquidation revert even if (DYAD Minted > Non Kerosene Value)

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

Value of kerosene can be manipulated to force liquidate users

The depositors participating in the ITO may claim an airdrop amount different from the actual value

The `revokeVestingSchedule` function does not correctly track `_totalSupply`, `_totalSupplyCheckpoints` and `_checkpoints[account]`

A malicious attacker can make significant amount of reward token to be locked in `ZivoeRewards` by calling `depositReward()` frequently.

The function `OCL_ZVE.pushToLockerMulti()` often results in a revert.

Borrowers can circumvent fees by calling `OCC_Modular::callLoan` when the grace period exceeds the payment interval

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

Incorrect validation during checking liquidity spread

`AutoExit` could receive a reward calculated from the entire position's fund even if `onlyFee` is true in `AutoExit.execute()`.

Wrong global lending limit check in `_deposit` function

Large decimal of referenceToken causes overflow at oracle price calculation

Users can lend and borrow above allowed limitations

`currentEpochsByAsset` is not increased in `RioLRTWithdrawalQueue.queueCurrentEpochSettlement()`

The `allocation` of shares has to be deleted, if `old cap > 0 && new cap == 0` in `OperatorRegistryV1Admin.setOperatorStrategyCap()`.

Depositing tokens to EigenLayer strategy reverts because of dust differences.

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

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

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)

Attackers can win the round unfairly without dispositing ETH to the current round using `depositETHIntoMultipleRounds` function

`MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND` can be bypassed using `depositETHIntoMultipleRounds` function.

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

Whitelised accounts can be forcefully DoSed from buying curveTokens during the presale

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

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

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

An attacker can drain TRUF tokens after initial release period and before the cliff

Incorrect implementation and usage of TWAP oracle affects Ubiquity Dollar price validation

Incorrect amounts of ETH are transferred to the DAO treasury in `ERC20TokenEmitter::buyToken()`, causing a value leak in every transaction

Once EntropyRateBps is set too high, can lead to denial-of-service (DoS) due to an invalid ETH amount

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

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

The quorumVotes can be bypassed

Bidder can use donations to get VerbsToken from auction that already ended.

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

Price calculation can be manipulated by intentionally reverting some of price feeds.

BunnySupply missing accumulated fees in Protocol Owned Liquidity(aka POL) calculation

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

Incorrect validation during checking liquidity spread

The auction mechanism would be broken forever by a malicious highest bidder.

The first founder will lose 1% ownership if `reservedUntilTokenId >= 100`.

No slippage protection for Market functions

PartyGovernance.sol#accept - passThresholdBps isn't cached for each proposal which can lead to problems, if changed through another proposal

Attacker can reenter to mint all the collection supply

getPrice `salesOption` 2 can round down to the lower barrier, skipping the last time period

Auction winner can prevent payments via `safeTransferFrom` callback

Resetting delegation will result in user funds being lost forever

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

`_amountOut` is representing assets and shares at the same time in the `liquidate` function

The `_currentExchangeRate` of the Vault contract can't increase, and always be lower than or equal to `_assetUnit`

`Vault.mintWithPermit()` can be DOSed

`_voteSucceeded()` returns true when `againstVotes > forVotes` and vice versa

Liquidation won't work when bad and safe collateral ratio are set to default values

`stakerewardV2pool.withdraw()` should check the user's boost lock status.

`UlyssesToken` asset ID accounting error

`UlyssesToken.setWeights(...)` can cause user loss of assets on vault deposits/withdrawals