Inadequate Checking of `isIncreasing` when trader adjusts position size

Incorrect logic for checking isFillPriceValid

Incorrect parameters passed in `_requireOnlyOperatorOrOwnerOf()` function allows any caller to have rights over any tokenID

Inconsistent check in `harvestPositionsTo()` function

`addToPosition()` might use incorrect `amountToAdd` value if amount received is different than input parameter

Users are able to front-run reward distribution

A user can lose funds in `sdlPoolSecondary` if tries to add more sdl tokens to a lock that has been queued to be completely withdrawn

It is not possible to execute actions that require ETH (or other protocol token)

`UlyssesToken` asset ID accounting error

Second per liquidity inside could overflow `uint256` causing the LP position to be locked in UniswapV3Staker

Underflow of `lpPosition.points` during withdrawLP causes huge reward minting

Updating a pool's total points doesn't affect existing stake positions for rewards calculation

Loss of user funds when completing CASH redemptions

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

Liquidity providers may lose funds when adding liquidity

First depositor can break minting of shares

`LPDA` price can underflow the price due to bad settings and potentially brick the contract

`saleReceiver` and `feeReceiver` can steal refunds after sale has ended

Unsafe downcasting operation truncate user's input

NFTs mintable after Auction deadline expires

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

Mutual consent cannot be revoked and stays valid forever

Variable balance ERC20 support

address.call{value:x}() should be used instead of payable.transfer()

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

Lender can reject closing a position

Possible DOS in RollerPeriphery `approve()` function

Funds are not refunded to current bidder in `cancelAuction(...)` function

Bug #1 - Incorrect `newDuration` calculation cause auction extending to `maxDuration` every time

Bug #2 - Incorrect new duration logic cause DOS in `createBid(...)` function

User can deploy and call multiple times with the same signature

Making a payment to the protocol with `_dontMint` parameter will result in lost fund for user.

Beneficiary credit balance can unwillingly be used to mint low tier NFT

Anyone can steal fee in ExchangeProxy to do the swap

Possible DOS in `deposit()`, `extendLock()` and `increaseLock()` because of potential overflow

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

First depositor can break minting of shares

Oracle data feed is insufficiently validated.

Replay signature attack to changeRecipientAddress function

Incompatability with deflationary / fee-on-transfer tokens

There is no limit on the amount of fee users have to pay

Wrong percent for `FraxlendPairCore.dirtyLiquidationFee`.

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

Possible DOS in `lendToProject()` and `toggleLendingNeeded()` function because unbounded loop can run out of gas

updateProjectHash does not check project address

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

Cash-out from a successful buyout allows an attacker to drain Ether from the `Buyout` contract

Create a short call order with non empty floor makes the option impossible to exercise and withdraw

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

An attacker can create a short put option order on an NFT that does not support ERC721(like cryptopunk), and the user can fulfill the order, but cannot exercise the option

Zero strike call options will avoid paying system fee

`Staking.sol#stake()` DoS by staking 1 wei for the recipient when `warmUpPeriod > 0`

Cannot mint to exactly max supply using `_mint` function

`_storeRebase()` is called with the wrong parameters

Possible DOS (out-of-gas) on loops.

`_harvest` has no slippage protection when swapping `auraBAL` for `AURA`

Withdrawing all funds at once to vault can be DoS attacked by frontrunning and locking dust

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

Rounding Issues In Certain Functions

Malicious user can populate `rewards` array with tokens of their interest reaching limits of `MAX_REWARD_TOKENS`

First depositor can break minting of shares

Use `safeTransfer()`/`safeTransferFrom()` instead of `transfer()`/`transferFrom()`

`RubiconMarket.sol#isClosed()` always returns false, making the market can not be stopped as designed

Use safeTransferFrom instead of transferFrom for ERC721 transfers

Vault is Not Compatible with Fee Tokens and Vaults with Such Tokens Could Be Exploited

StakedCitadel doesn't use correct balance for internal accounting

Funding.deposit() doesn't work if there is no discount set

New vest reset `unlockBegin` of existing vest without removing vested amount

When _lpToken is jpeg, reward calculation is incorrect

Division before Multiplication May Result In No Interest Being Accrued

`sendCollateralTo` is unchecked in `closeLoan()`, which can cause user's collateral NFT to be frozen

ERC20 transferFrom return values not checked

Centralisation RIsk: Owner Of `RoyaltyVault` Can Take All Funds

Wrong formula when add fee `incentivePool` can lead to loss of funds.

Incompatibility With Rebasing/Deflationary/Inflationary token

denial fo service

Assets sent from MarginAccount to InsuranceFund will be locked forever