Wrong rounding will make a market insolvent

Determining how many votes to buy may run OOG.

Attacker can drain the protocol due to unsafe downcasting

User can create offers with the same id and drain the contract

User can drain `oracleLess` approvals as the contract pulls the funds from the recipient address.

Order will be executed with wrong slippage if by the time of execution, price crosses take profit

`oracleLess` contract can be permanently DoS'd

When buying votes, fees are taken from the whole `msg.value` instead of the amount spent on votes.

When buying votes, protocol and donation fees are accidentally added to the market funds

The bonding curve logic is flawed and allows for full drain of funds

There's no slippage protection when selling votes

Detaching HSG when there's non-unregistered owners who no longer own the hat would give them control over the multi-sig

Signer can avoid restrictions and change `safe` state variables

Attacker can steal all claims

Repayments will fail if lender gets blacklisted

Refinancing and auction take less fee than expected.

User could withdraw more than supposed to, forcing last user withdraw to fail

Users are incentivized to not withdraw immediately after the market is closed.

Role providers can bypass intended restrictions and lower expiry set by other providers

`FixedTermLoanHook` looks at `block.timestamp` instead of `expiry`

Inconsistency across multiple repaying functions causing lender to pay extra fees.

User can sandwich their own position close to get back all of their position fees

Usage of `tx.origin` to determine the user is prone to attacks

First depositor could DoS the pool

Liquidity providers can remove liquidity to force positions into high fees

If position goes to 0, the funding fees it should've received are never redistributed and are forever stuck

User could have impossible to close position if funding fees grow too big.

User can make their `veNFT` unpokeable by doing a dust vote

`disable_max_lock` does not work for last NFT in the array

User might lose funds when adding liquidity within `OptionTokenV4`

Pausing a gauge results in all it's claimable funds becoming forever stuck

Checkpointing total supply when `block.timestamp % WEEK == 0` will result in overdistribution of rewards

If user merges their `veNFT`, they'll lose part of their rewards

Exercising a large amount of options gives significantly higher discounts than supposed to.

User can make their `veNFT` unpokeable by voting for a to-be-killed gauge

Minter will get DoS'd in certain scenario

First liquidity provider of a stable pair can DoS the pool

Rewards supplied to a gauge, prior to its first depositor will be permanently lost.

`ReseedSilo#reseedSiloDeposit` does not credit the user any `roots`

Successful transactions are not stored, causing a replay attack on ``redeemDepositsAndInternalBalances``

Internal balances are never actually migrated within `L2ContractMigrationFacet`

L2ContractMigrationFacet doesn't increase total Stalk and Roots

User's stalk is overwritten instead of increased within `ReseedSilo`

`L2ContractMigrationFacet.addMigratedDepositsToAccount()` doesn't update some global balances during the migration.

Possible loss of user's balances after calling `addMigratedDepositsToAccount()`.

ReseedSilo doesn't update total balances of Stalk and Roots

`ReseedSilo` does not set the necessary user variables

quickSort function does not work as expected, compromising the calculation of Beans per Well to be minted during a flood

When migrating via `L2ContractMigrationFacet`, user is not minted roots for the newly accrued stalk

Attacker can spam Plots to victim to cause DOS on Plot transfer

If user has not mown since germination, they'll lose their portion of `plenty`

User will lose the rest of their `plenty` if they fully withdraw during/after `rain`.

`redeemDepositsAndInternalBalances` should mow before adding migrated deposits

`fundsSafu` modifier will be useless on L2 before all users have successfully migrated.

Malicious users can delete plots from other users in a specific edge case

If token get's unwhitelisted, users will be unable to claim the `plenty` they've accrued prior to the unwhitelist

Hardcoded `MERKLE_ROOT` will make the contract unusable

`plenty` balances are not migrated on L2

Accounting will be broken if `output` token is one of the `lpTokens`

Users can take undercollateralized borrows, as contract falsely assumes `requiredCollateral` is scaled up by 1e18

No way for `LenderCommitmentGroup_Smart` to claim funds deposited into an `EscrowVault`

`lenderCloseLoanWithRecipient` sends the collateral to the lender, instead of the `recipient`

Attacker can drain/DoS any `LenderCommitmentGroup_Smart` by repaying fake loans.

Multiple instances of using `approve` instead of `safeApprove`

It is impossible for a lender to close loan if they've claimed the loan NFT

Possible donation attack within `LenderCommitmentGroup_Smart`

FlashRolloverLoan is unusable as `SmartCommitmentForwarder` does not inherit `ERC2711ContextUpgradeable`

`_repayLoan` now allows for overpaying of loan and could cause DoS within `LenderCommitmentGroup_Smart`

Liquidation bonus scales exponentially instead of linearly.

User can drain the Vesting contract via re-entrancy

Tax refund is calculated based on the wrong amount

If token does not oversell, users cannot claim tax refund on their tax free allocation.

Vesting contract cannot work with ETH, although it's supposed to.

Users can still receive and send tokens after getting blacklisted

`BridgeRelay` makes an approval to the same `predicate` address, despite different tokens/ eth having different predicates.

Router's permit functions are unusable, since `JalaPair` lacks a permit function

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

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

Users can win the pot with 0-value entries

A user can mask a ERC20 deposit as ERC721 one and get significant advantage.

`depositETHIntoMultipleRounds` allows to bypass `MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND` which can lead to OOG in `fulfillRandomWords`

Unsafe `call` allows an arbitrary user to steal all funds within JOJODealer

Adversary can DoS all users from regular withdraws

First depositor issue in `FundingRateArbitrage`

Users can fully drain the `TrufVesting` contract

User can extend their expired lock and get free ve balance

User can pass an array full of the same token id to `manageOwnedAndDelegated` and significantly increase their voting power

Reducing a gauge's weight might result to full DoS within GaugeController

If the multiple calls to `writeStakingRewards` cross a week's end, it will result in unfair distribution of rewards

`mgCvg` balances are wrongfully calculated

A malicious user can avoid unfavorable score updates after alpha/multiplier changes, resulting in accrual of outsized rewards for the attacker at the expense of other users

If `claimDefaulted` is called before `claimRepaid` all of `loan.unclaimed` will be lost

If `loan.callback == true`, lender can force all repayments to revert and force loan into default

Anyone can accept new terms by calling `rollLoan` due to lack of access control.

Lender can front-run `rollLoan` and call `provideNewTermsForRoll` with unfavorable terms

`ReLPContract` wrongfully assumes protocol owns all of the liquidity in the UniswapV2 pool

Improper precision of strike price calculation can result in broken protocol

The peg stability module can be compromised by forcing lowerDepeg to revert.

reLP() mintokenAAmount the calculations are wrong.

If a winner is blacklisted on any of the tokens they can't receive their funds

When adding a gauge, its initial value has to be set by an admin or all voting power towards it will be lost

Voters from VotingEscrow can vote infinite times in vote_for_gauge_weights() of GaugeController

If governance removes a gauge, user's voting power for that gauge will be lost.

Users can front-run calls to `change_gauge_weight` to gain extra voting power

Tokens with less than 18 decimals allow for draining of funds

During refinance() new Pool balance debt is subtracted twice

Borrower can bypass maxLoanRatio's configuration of a pool via buyLoan()

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Stealing any loan opening for auction through others' lending pool

A pool lender can fully drain another user's pool by abusing `buyLoan`

Forcing a borrower to pay a huge debt via the giveLoan()

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

Some ERC20 tokens would revert on zero value fee transfers.

User can DoS pool lender's withdrawals.

Possible DOS by borrowers in `setPool()`

Inability to refinance within the same pool due to exceeding the pool balance

Chainlink Oracle will return the wrong price for asset if underlying aggregator hits minAnswer

Oracle doesn't check if L2 Arbitrum sequencer is down

Calling `StandardFunding.screeningVote` function and `ExtraordinaryFunding.voteExtraordinary` function when `block.number` equals respective start block and when `block.number` is bigger than respective start block can result in different available votes

Use of unsafe `_mint` method

USDT will get permanently stuck in `FootiumPrizeDistributor.sol` and `FootiumEscrow.sol`

Usage of deprecated `transfer` method might lead to lose of funds

ChainlinkAdapterOracle's getPrice() doesn't check if Arbitrum L2 sequencer is down

Possible stale values from Chainlink oracle

Uniswap getting the price from all available pools for certain token pair possesses a risk

Lender can steal all of liquidator's tokens

Project breaks when a fee-on-transfer ERC20 is used as collateral

Lenders can steal all of the borrowers tokens.

Challengers and bidders can collude together to restrict the minting of position owner

function `restructureCapTable()` in Equity.sol not functioning as expected

If auction price goes to 0, NFT might become unclaimable/ stuck forever