Draw auction rewards likely exceed the available rewards, resulting in overpaying rewards or running into an `InsufficientReserve` error

The RNG finish draw auction rewards are overpaid due to missing to account for the time it takes to fulfill the Witnet randomness request

`DrawManager.canStartDraw` does not consider retried RNG requests when determining if a new draw auction can be started

Using unconfirmed UTXOs as inputs for transactions is vulnerable to griefing attacks

Tombstoned observer can maliciously add a duplicate observer address resulting in forfeiting voting rewards of targeted observers

Outbound transactions that can not be broadcasted to an external EVM chain cause a Denial of Service of all outgoing transactions to this chain

zEVM cross-chain messages ignore the user-specified message and prevent calling the destination contract

Disabling outbound transactions is ineffective and allows for Zeta token theft

A malicious inbound transaction can prevent subsequent events from being processed by observers

Fake `ZetaReceived` events cause the outbound cctx to remain pending resulting in a blocked outbound EVM transaction queue

`ZetaSupplyChecker` calculation error

When updating gas, if one chain fails, the others should continue to be updated instead of being skipped.

An already executed InTxTracker can still be added

ZRC20 Token Pause Check Bypass

Incorrect genesis initialization of pending nonces

Lagging median gas price when the set of observers changes

Inability to reliably verify inbound transactions may result in missed inbound transactions

Lack of message ordering may lead to failed transactions

Inbound transactions submitted to the `InTxTracker` that contain multiple `ZetaSent` and `Deposited` events are not processed correctly by the observers resulting in a loss of funds

A single malicious observer can fill the block space with `MsgGasPriceVoter` messages without proper gas compensation resulting in griefing blocks

Zeta token supply checker incorrectly classifies in-transit cctxs as settled resulting in misleading checks

Arbitrary destination gas limit for `CoinType_Zeta` cctxs results in paying lower gas fees

Observer can halt outbound cctxs and steal funds

Outbound zEVM cross-chain messages ignore the user-specified gas limit and may fail with an out-of-gas error

The `Sender` of an outbound cctx originating from the zEVM is potentially set to an incorrect sender address resulting in lost assets during a refund

ERC-20 deposit cctxs are refunded to the EOA instead of an intermediary contract

The outbound transaction tracker only keeps track of a maximum of two different transaction hashes, preventing cctxs from being efficiently confirmed and blocking the outbound transaction queue

A single malicious observer can exploit the infinite gas meter to grief ZetaChain blocks without proper gas compensation

Risk-free profits for an attacker due to outdated debt reporting during `LMPVault` deposits

Consecutively queueing new rewards transfers more tokens than anticipated

Performing the liquidation process reverts due to failing to swap the reward tokens

Claimed destination vault base asset rewards are potentially lost during `LMPVault` withdrawals

`MainRewarder` staking rewards are diluted by new stakers resulting in less rewards for existing stakers

Potentially overpaying for vault shares due to the lack of incorporating native ETH into the required `assets` amount

Destination vault debt can be selectively updated to collect fees on "profits" while ignoring the losses from other destination vaults

Users are unable to withdraw from `LMPVault` if the accumulated `TOKE` rewards are below the `MIN_STAKE_AMOUNT` threshold

Edge case scenario during `LMPVault` withdrawals results in the inability to withdraw

Protocol fees are not collected for a while after the `LMPVault` got emptied

Option token receiver can steal funds by repeatedly reclaiming expired options

A malicious option token deployer can drain quote token funds from the `FixedStrikeOptionTeller` contract

Claiming epoch rewards at the time of the options expiry will mint options that are immediately expired and thus unable to get exercised

A malicious user can prevent reward accrual

Depositing staking tokens at a later epoch requires claiming rewards for all epochs since the very first epoch

If the `receiver` is prevented from receiving exercised proceed tokens, exercising options is not possible

Funds can be stolen from the `FixedStrikeOptionTeller` contract by creating put option tokens without providing collateral

Expired signatures with outdated prices can be used to liquidate Party A's positions

Emergency position closing can be griefed by Party A

Depositing and allocating funds for Party B potentially allocates less than anticipated

Liquidating a turned solvent Party A does not credit the profits to Party A

Consecutive symbol price updates can be exploited to drain protocol funds

Inaccurate solvency check during position opening can lead to immediate insolvency

Party B liquidation can expire, causing the liquidation to be stuck

Party B can grief Party A by filling the close request for a limit order with a zero amount

Party B liquidations are not incentivized if the losses exceed the locked liquidation possibly resulting in not liquidating Party B and Party A not receiving the liquidation proceeds

Fully opening a limit quote with down-adjusted locked values could lead to a quote value smaller than the enforced minimum

Fee collector can grief the protocol by withdrawing trading fees that could still need to be returned to Party A

Entitled asset shares are not withdrawn and are lost when minting rollovers

Delisting a rollover queue item reorders an item and prevents the reordered item from being rolled over in the next epoch

Updating carousel vault rollover queue item sets the wrong index

Adversary can trigger a regular end epoch for a null epoch and cause premium vault users to lose funds

`Carousel.mintRollovers` potentially mints `0` shares and can grief rollover queue

Null epoch prevents carousel rollover

Risk-free hedge if depeg is triggered at the start of the epoch

Arbitrum sequencer downtime lasting before and beyond epoch expiry prevents triggering depeg

Inability to claim collateral

Decreasing a position without a swap path is susceptible to slippage

Underestimated gas estimation for executing withdrawals leads to insufficient keeper compensation

The claimable collateral factor with the key `Keys.claimableCollateralFactorKey` remains unchanged and results in a claimable collateral amount of zero

Depositing in a market with the same long and short tokens will revert

Too few `ICHI` v2 farming reward tokens transferred to the user due to incorrect decimal precision

Failure to withdraw Ichi vault LP tokens to the user

Failure to refund `ICHI` v2 farming reward tokens upon increasing farming position

`SoftVault` accrued interest is not refunded and stuck forever

A liquidator can repay the smaller debt position to fully liquidate a position and receive the full collateral

The maximum size of an `ICHI` vault spell position can be arbitrarily surpassed

Closing an `IchiVaultSpell` position is susceptible to slippage when swapping tokens

Rebase/FoT tokens are not supported as isolated collateral

The total lent amount of a bank is not decremented when a position is liquidated

Squeezing drips from a sender can be front-run and prevented by the sender

Fully repaying a loan transfers debt tokens to zero-address

Repaying loans with small amounts of debt tokens can lead to underflowing in the `roll` function

Executing funded standard proposals can be prevented by a proposal slate with duplicate proposals

Claiming accumulated rewards while the contract is underfunded can lead to a loss of rewards

Calculating new rewards is susceptible to precision loss due to division before multiplication

Claiming rewards from a future not yet existing epoch prevents claiming rewards for those epochs later on

Extraordinary proposals can receive more tokens than eligible

Anyone can use the token spending allowance from another address to rebalance negative Perp PnL

Calculating the Perp short position value uses a potentially unsafe TWAP interval

Redeeming all UXD tokens is not possible if some have been minted via Perp quote minting

Rebalancing a negative Perp PnL via a Uniswap V3 token swap is broken due to the lack of token spending allowance

Rebalancing a negative Perp PnL will fail to deposit to the vault due to decimal precision inconsistencies

Fee accounting for Perp positions is incorrect

Inaccurate Perp debt calculation

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

Borrower can close a credit without repaying debt

Repaying a line of credit with a higher than necessary claimed revenue amount will force the borrower into liquidation

Whitelisted functions aren't scoped to revenue contracts and may lead to unnoticed calls due to selector clashing

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

Lender can reject closing a position

The tier reserved rate is not validated and can surpass `JBConstants.MAX_RESERVED_RATE`

Collected fees can be used by anyone to top-up

Claiming rewards with a pool that has an escrow portion but no escrow pool set will render the escrowed rewards lost

Curve points are not validated to be continuously increasing

A malicious early depositor can manipulate the vault's share price

A paused Aave lending pool will cause a serious denial of service

Duplicate plugins cause multiple counting of `LINK` token balance

Chainlink's `latestRoundData` might return stale or incorrect results

Vault set to the zero-address will break swaps and flash loans in all deployed pools

A "FrontRunning attack" can be made to the `initialize` function

`safeTransfer` function does not check for existence of ERC20 token contract

not able to create claim

The reveal process could brick if `randProvider` stops working

Multiple vote checkpoints per block will lead to incorrect vote accounting

`ERC721Votes`: Token owners can double voting power through self delegation

Creating a new governance proposal can be prevented by anyone

First `ERC4626` deposit can break share calculation

`ERC4626Oracle` oracle calculates the wrong price for vaults with different decimals than their underlying asset

Chainlink oracle calculates the wrong price for ETH nominated pairs

Account liquidation can fail in certain situations

In `Governance.sol`, it might be impossible to activate a new proposal forever after failed to execute the previous active proposal.

TRSRY: front-runnable `setApprovalFor`

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

Owner of `FraxlendPair` can set arbitrary time lock contract address to circumvent time lock

Fraxlend pair deployment can be front-run by a custom pair deployment

FraxlendPair.sol is not fully EIP-4626 compliant

NFT creator sales revenue recipients can steal gas

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

Anyone can create disputes if `contractor` is not set

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

Owner of project NFT has no purpose

transfer() depends on gas consts

The `unwrapETH2LD` use `transferFrom` instead of `safeTransferFrom` to transfer ERC721 token

Migration can permanently fail if user specifies different lengths for `selectors` and `plugins`

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

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

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

Token Change Can Be Frontrun, Blocking Token

Use a safe transfer helper library for ERC20 transfers

Discounted fee calculation is imprecise and calculates less fees than anticipated

Locked splits can be updated

More outstanding reserved tokens are distributed than anticipated leading to less redeemable assets and therefore loss of user funds

Unhandled chainlink revert would lock all price oracle access

Fee is being deducted when Put is expired and not when it is exercised.

`fillOrder()` and `exercise()` may lock Ether sent to the contract, forever

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

[Denial-of-Service] Contract Owner Could Block Users From Withdrawing Their Strike

Putty position tokens may be minted to non ERC721 receivers

`fee` can change without the consent of users

Sending batch withdrawal requests can possibly DoS

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

Users of Migration.sol may forfeit rebase rewards

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

Badger rewards from Hidden Hand can permanently prevent Strategy from receiving bribes

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

Overpayment of native ETH is not refunded to buyer

Accumulated ETH fees of InfinityExchange cannot be retrieved

Malicious governance can use `updateWethTranferGas` to steal WETH from buyers

Protocol fee rate can be arbitrarily modified by the owner and the new rate will apply to all existing orders

Rounding Issues In Certain Functions

Users Might Not Be Able To Purchase Or Redeem SetToken

Misconfiguration of Fees Incentive Might Cause Tokens To Be Stuck In `Booster` Contract

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

First depositor can break minting of shares

RubiconRouter.swapEntireBalance() doesn't handle the slippage check properly

USDT is not supported because of approval mechanism

Inconsistent Order Book Accounting When Working With Transfer-On-Fee or Deflationary Tokens

RubiconRouter: Excess ether did not return to the user

No cap on fees can result in a DOS in BathToken.withdraw()

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

`RubiconMarket` buys can not be disabled if offer matching is disabled

`RubiconMarket.feeTo` set to zero-address can DoS `buy` function

Changing `matchingEnabled` in `RubiconMarket` breaks protocol

Use `call()` instead of `transfer()` when transferring ETH in RubiconRouter

hard-coded slippage may freeze user funds during market turbulence

The check for value transfer success is made after the return statement in _withdrawFromYieldPool of LidoVault

Possible lost msg.value

Withdrawing ETH collateral with max uint256 amount value reverts transaction

Use safeTransferFrom instead of transferFrom for ERC721 transfers

Owner can modify the feeRate on existing vaults and steal the strike value on exercise

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

User's may accidentally overpay in `buyOption()` and the excess will be paid to the vault creator

safeTransferFrom is recommended instead of transfer (1)

amount requires to be updated to contract balance increase (1)

Use of `.send()` May Revert if The Recipient's Fallback Function Consumes More Than 2300 Gas

[WP-H1] A malicious early user/attacker can manipulate the vault's pricePerShare to take an unfair share of future users' deposits

_depositAmount requires to be updated to contract balance increase

SuperVault's leverageSwap and emptyVaultOperation can become stuck

The return value `success` of the get function of the INFTOracle interface is not checked

Chainlink's latestRoundData might return stale or incorrect results

`call()` should be used instead of `transfer()` on an `address payable`

Chainlink's latestRoundData might return stale or incorrect results

StakedCitadel depositors can be attacked by the first depositor with depressing of vault token denomination

StakedCitadel: wrong setupVesting function name

yVault: First depositor can break minting of shares

Wrong calculation for yVault price per share if decimals != 18

Chainlink pricer is using a deprecated API

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