Farms can be created to start in past epochs

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

Block gas limit can be hit due to loop depth

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`

In edge cases, create_pool can either be reverted or allow user underpay fees.

Emergency Unlocking Penalty Makes Long Duration Positions Economically Advantageous

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

Insufficient Intermediate Value Precision in StableSwap Calculations

Liquidity providers can lose tokens due to disproportionate deposits not being properly handled

M-07- Slippage Tolerance Vulnerability in StableSwap

Standard deviation calculation is biased

Malicious peer can cause a syncing node to panic during blocksync

Reentrancy in buy function for ERC777 tokens allows buying funds with considerable discount

NFTs mintable after Auction deadline expires

Data corruption in NFTFloorOracle; Denial of Service

safeTransfer is not implemented correctly

Fallback oracle is using spot price in Uniswap liquidity pool, which is very vulnerable to flashloan price manipulation

During oracle outages or feeder outages/disagreement, the `ParaSpaceFallbackOracle` is not used

Centralization risk: admin can with rug the project by removing asset and price manipulation on oracle.

MintableIncentivizedERC721 and NToken do not comply with ERC721, breaking composability

Underlying assets stealing in `AutoPxGmx` and `AutoPxGlp` via share price manipulation

GiantLP with a transferHookProcessor cant be burned, users' funds will be stuck in the Giant Pool

GiantMevAndFeesPool.bringUnusedETHBackIntoGiantPool function loses the addition of the idleETH which allows attackers to steal most of eth from the Giant Pool

Giant pools can be drained due to weak vault authenticity check

Banned BLS public keys can still be registered

Attacker can grift syndicate staking by staking a small amount

Incorrect checking in _assertUserHasEnoughGiantLPToClaimVaultLP

Medium: Vaults can be griefed to not be able to be used for deposits

Freezing of funds - Hacker can prevent users withdraws in giant pools

StandardPolicyERC1155.sol returns amount == 1 instead of amount == order.amount

Direct theft of buyers ETH funds.

Seller's ability to decrypt bids before reveal could result in a much higher clearing price than anticpated and make buyers distrust the system

Attacker may DOS auctions using invalid bid parameters

Incompatibility with fee-on-transfer/inflationary/deflationary/rebasing tokens, on both base tokens and quote tokens, with varying impacts

Non-existing revenue contract can be passed to claimRevenue to send all tokens to treasury

addCredit / increaseCredit cannot be called by lender first when token is ETH

Lender can trade claimToken in a malicious way to steal the borrower's money via claimAndRepay() in SpigotedLine by using malicious zeroExTradeData

Variable balance ERC20 support

Borrower/Lender excessive ETH not refunded and permanently locked in protocol

Reward can be over- or undercounted in `extendPledge` and `increasePledgeRewardPerVote`

Owner can transfer all ERC20 reward token out using function recoverERC20

ERC777 reentrancy when withdrawing can be used to withdraw all collateral

Protocol withdrawals of collateral can be unexpectedly locked if governance sets the `collateralFactorBps` to 0.

Oracle assumes token and feed decimals will be limited to 18 decimals

Chainlink oracle data feed is not sufficiently validated and can return stale `price`

Replayable signatures allowing free deploys when they should not be free

An attacker can manipulate each pod and gain an advantage over the remainder Operators

Gas price spikes cause the selected operator to be vulnerable to frontrunning and be slashed

HolographERC721.safeTransferFrom not compliant with EIP-721

HolographERC721.approve not EIP-721 compliant

Bond tokens (HLG) can get permanently stuck in operator

`_payoutToken[s]()` is not compatible with tokens with missing return value

Changing default reserved token beneficiary may result in wrong beneficiary for tier

Iterations over all tiers in recordMintBestAvailableTier can render system unusable

Overdue balances cannot be paid back

Downcast in UToken.borrow allowing borrows that should not be allowed

Comptroller.withdrawRewards: totalFrozen subtracted two times from totalStaked

AssetManager.removeAdapter: Adapter not removed from withdrawSeq

UserManager.cancelVouch not updating voucherIndexes / voucheeIndexes

Transfering funds to yourself increases your balance

beforeTokenTransfer called with wrong parameters in LBToken._burn

setCurvePoint: unit not updated when curve.length changes

StandardPolicyERC1155.sol returns amount == 1 instead of amount == order.amount

Direct theft of buyers ETH funds.

Deployment can be bricked by manually transferring small LINK amount before first deposit

TrueFiStrategy: Too little withdrawn when used with AlphaBetaSplitter

It is possible that, after swapping, extra input token amount is transferred from user to pool but pool does not give user output token amount that corresponds to the extra input token amount

Biased estimator for volatility used

Wrong accounting logic when syncRewards() is called within beforeWithdraw makes withdrawals impossible

removeValidator() and removeMinter() may fail due to exceeding gas limit

frxETHMinter.depositEther may run out of gas, leading to lost ETH

frxETHMinter: Non-conforming ERC20 tokens not recoverable

Two address tokens can be withdrawn by the admin even if they are vested

Reentrancy may allow an admin to steal funds

The reveal process could brick if `randProvider` stops working

Wrong balanceOf user after minting legendary gobbler

Funds are locked up for fee-on-transfer

Withdrawing payments may fail

Overflow possible in logIncomingERC20

Incorrect handling of pricefeed.decimals()

Users who deposit in one vault can lose all deposits and receive nothing when counterparty vault has no deposits

LOSS OF PRECISION RESULTING IN WRONG VALUE FOR PRICE RATIO

Risk users are required to payout if the price of the pegged asset goes higher than underlying

Vault.sol is not EIP-4626 compliant

Depeg event can happen at incorrect price

Oracle is tracked per token instead of per pair, leading to surprise results

Fee-on-Transfer tokens cause problems in multiple places

StakingRewards: Significant loss of precision possible

Different Oracle issues can return outdated prices

Possibility to burn all ETH in Crowdfund under some circumstances

PartyGovernance: Can vote multiple times by transferring NFT in same block as proposal

TokenDistributor: ERC777 tokensToSend hook can be exploited to drain contract

A majority attack can steal precious NFT from the party by crafting and chaining two proposals

Possible that unanimous votes is unachievable

Maximum bid will always be used in Auction

# Only part of `keccak256()` is used as hash, making it susceptible to collision attacks

ExchangeRate age not checked

Token: Founder percentages not always respected

`Token:mint`: infinite loop if the founders' shares sum up to 100

LEther: Flash loan can be used to manipulate borrow rate

ChainlinkOracle: Assumes all feeds have 8 decimals

ERC4626Oracle: Assumes that asset and share have same number of decimals

UniV2LPOracle: Decimals of pair tokens ignored

StableBalancerLPOracle: Wrong calculation

BalancerController: Can be misused to get non-approved tokens into the account

AccountManager: Liquidations not possible when transfer fails

AccountManager: address(0) used for borrowing ETH

AccountManager: Fee-On-Transfer tokens not supported

Voted votes cannot change after the user are issued with new votes or the user's old votes are revoked during voting

[NAZ-M1] Chainlink's `latestRoundData` Might Return Stale Results

Unexecutable proposals when Actions.MigrateKernel is not last instruction

Activating same Policy multiple times in Kernel possible

Heart::beat() could be called several times in one block if no one called it for a some time

ERC721Checkpointable: delegateBySig allows the user to vote to address 0, which causes the user to permanently lose his vote and cannot transfer his NFT.

Any borrower with bad debt can be liquidated multiple times to lock funds in the lending pair

`liquidate()` doesn't mark off bad debt, leading to a 'last lender to withdraw looses' scenario

No incentives to write off bad debt when remaining collateral is very small

FraxlendPair.sol is not fully EIP-4626 compliant

Forget to check "Some manifolds contracts of ERC-2981 return (address(this), 0) when royalties are not defined" in 3rd priority - MarketFees.sol

NFT of NFT collection or NFT drop collection can be locked when calling _mint or mintCountTo function to mint it to a contract that does not support ERC721 protocol

Creator fees may be burned

User may get all of the creator fees by specifying high number for himself

Automation / management can be set for not yet existing vault

Registry.sol works bad - it fails to delivere expected functionality

Malicious manipulation of gas reserve can deny access to MIMOProxy

Builder can call `Community.escrow` again to reduce debt further using same signatures

Builder can halve the interest paid to a community owner due to arithmetic rounding

Add members to the not yet created community

Untyped data signing

Wrong APR can be used when project is unpublished and published again

Project funds can be drained by reusing signatures, in some cases

Project.addTasks() wouldn't work properly when it's called from disputes contract.

Attacker can drain all the projects within minutes, if admin account has been exposed

changeOrder requires subcontractor signature when the subcontractor address is 0

Hash approval not possible when contractor == subcontractor

Change of operators possible from old operators

System will not work anymore after EIP-4758

removeWrapping can be called when there are still wrapped tokens

Error in allowance logic

Incorrect implementation of `RRUtils.serialNumberGte`

Fund will be stuck if a buyout is started while there are pending migration proposals

Steal NFTs from a Vault, and ETH + Fractional tokens from users.

Division rounding can make fraction-price lower than intended (down to zero)

Malicious User Could Burn The Assets After A Successful Migration

```migrateFractions``` may be called more than once by the same user which may lead to loss of tokens for other users

Migration fails when all tokens are joined

An attacker can DoS vault's buyout with as little as 1 wei per 4 days

Delegate call in `Vault#_execute` can alter Vault's ownership

Migration total supply reduction can be used to remove minority shareholders

Token Change Can Be Frontrun, Blocking Token

`acceptCounterOffer()` May Result In Both Orders Being Filled

Options with a small strike price will round down to 0 and can prevent assets to be withdrawn

Put options are free of any fees

getBorrowRate returns rate per year instead of per block

Deny of service in `CNote.doTransferOut`

NibblVault: In the buy function, users can avoid paying fees

Buyout cannot be rejected when paused

No withdrawal possible for ETH TOKE pool

Functions in the `BatchRequests` contract revert for removed contract addresses

coolDown & warmUp period do not work when a low _firstEpochEndTime is passed to initialize

Allowance check always true in ERC5095 redeem

ERC5095 redeem/withdraw does not update allowances

Unable to redeem from Notional

`Redeemer.sol#redeem()` can be called by anyone before maturity, which may lead to loss of user funds

Funds may be stuck when `redeeming` for Illuminate

Overpayment of native ETH is not refunded to buyer

Accumulated ETH fees of InfinityExchange cannot be retrieved

`lending-market/Note.sol` Wrong implementation of access control

`LibDiamond.diamondCut()` should check `diamondStorage().acceptanceTimes[keccak256(abi.encode(_diamondCut))] != 0`