Epoch-boundary checkpoints retroactively qualify for the previous epoch's rewards

Reward manipulation vulnerability in StabilityPool

Users can borrow more assets than they have deposited as collateral

NFTs Get Permanently Locked in Stability Pool After Liquidation

Any attempt to liquidate a user will fail, because StabilityPool does not hold crvUSD during operational lifecycle

Boost Miscalculation Leads to Excess Distribution

Ownership Parameter Mismatch in LendingPool’s Vault Withdrawal Logic

Gauge reward period can be extended indefinitely

Incorrect utilization rate forces protocol to issue maximum rewards indefinitely

LendingPool deposits do not work with CurveVault due to lack of funds

Using balanceOf Instead of Voting Power

Concurrent Oracle Fulfillments Overwrite House IDs, which leads to Incorrect Pricing

LendingPool.getUserDebt returns outdated value and can lead to liquidation failure

No check for sequencer uptime can lead to Zeno auctions being executed at lower prices or may result in incomplete auctions

Treasury Contract Deposit Function Can Be Frontrun To Deny Protocol Operations

Liquidations are enabled when repayments are disabled, causing borrowers to lose funds without a chance to repay

Owner Can Change Vote Results After Voting Ends by Updating Quorum Numbers for New proposals

Incorrect Initialization of minBoost in BaseGauge Constructor Breaks Core Contract Functionality

Borrow, withdraw, deposit revert due to curve vault not having available liquidity or being paused.

No slippage check in `sellVotes` can cause users to receive less ETH than expected.

Users can unvouch during the 24-hour evaluation period.

Double voting is possible if the user withdraws and reopens a position within the voting duration.

`harvestPositionTo` should always send rewards to owner of NFT.

Loss of reward if `emergencyWithdraw` is called

Malicious users can exploit the bribe mechanism by awarding worthless tokens as a bribe and reaching the max bribe limit.

`BribeRewarder` will not handle fee-on-transfer tokens

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

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

Rewards in `LenderCommitmentGroup_Smart` is sandwichable.

The return value of arbitrary ERC20 tokens transfers is not checked.

The liquidator will not receive the collateral after liquidation.

`LenderCommitmentGroup_smart` does not support Fee on Transfer tokens

`OwnableUpgradeable` is not initialized in `LenderCommitmentGroup_Smart`

Double counting of the vote is possible in `ZivoeRewardVesting:revokeVestingSchedule` breaking the protocol core invariant.

Incorrect Accounting of `_totalSupply` and `_totalSupplyCheckpoints` in `zivoeStakingRewards:revokeVestingSchedule` can cause DOS.

Malicious actor can call `ZivoeRewards:depositReward` with 1 wei many times increase the reward’s `periodFinish` making the contract unusable..

`OCL_ZVE:pushToLockerMulti ` will likely revert because of allowance check.

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

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

Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

Wrong ProfitManager in GuildToken, will always revert for other types of gauges leading to bad debt

Malicious borrower can decrease Guild holders reward

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

Wrong hardcoded PnL factor is used in all GMXVault add liquidity operations

Unhandled DoS when access to Chainlik oracle is blocked

`processDeposit()` can cause a DoS if equityAfter is 0 and equityBefore > 0.

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

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

Centralization Risk for trusted organizers

Sandwich attack to steal all ERC-20 tokens in the Fees contract

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

Fee on transfer tokens will cause users to lose funds

update() not getting called right after a WETH amount has been sent will cause users to lose staking rewards

Rewards can be sabotaged by large deposit and withdraw

The `borrow` and `refinance` functions can be front-run by the pool lender to set high interest rates

Floating pragma in all contracts

Misspelled event in `Lender.sol`