`RFPSimpleStrategy` Winning bidder can front-run the `_allocate()` transaction and change the `proposalBid` with `registerRecipient()`.

`QVSimpleStrategy._allocate()` does not update `allocator.voiceCredits` as expected, causing the upper limit of `maxVoiceCreditsPerAllocator` to be ineffective.

Wrong implementation of `RFPSimpleStrategy#setMilestones()`

`QVBaseStrategy._qv_allocate()` mistakenly included `_allocator.voiceCreditsCastToRecipient[_recipientId]`, causing `_recipient.totalVotesReceived` to increase.

`distribute()` may be distributed in unexpected proportions due to the lack of guarantee that `distribute()` is executed after all `allocate()`.

`RFPSimpleStrategy` does not work when configured with `useRegistryAnchor == true`

Fee on transfer token is not supported properly.

Wrong implementation of `NOT_ENOUGH_FUNDS` check in `_distribute()`.

`QVSimpleStrategy` cannot fund pools with NATIVE token due to lack of `receive() external payable {}` method.

`QVBaseStrategy.reviewRecipients()`'s voting mechanism lacks a record of the voting target content (the recipient state it targets), resulting in different starting states for votes after the recipient state changes.

`settle(address(0))` can result in incorrect `assets` and `shares` due to a miscalculation that mistakenly treats the global account as a local account.

New orders should request for a new oracle version at `currentTimestamp` (the next whole hour) instead of the current time (`block.timestamp`)

Protocol's fee is claimed by the factory, but there is no way to move tokens out.

`_accumulateFunding()` maker will get the wrong amount of funding fee.

`Liquidation` should not put the market into a worse state (more bad debt).

`OracleVersion latestVersion` of `Oracle.status()` may go backwards when updating to a new oracle provider and result in wrong settlement in `_processPositionLocal()`.

Lack of access control for `mintRebalancer()` and `burnRebalancer()`

Uniswap v3 pool token balance proportion does not necessarily correspond to the price, and it is easy to manipulate.

`getOwnValuation()` can easily be manipulated to trigger `rebalance()`.

Wrong Oracle feed addresses

`StableOracleDAI` is improperly implemented.

UniV3 Router's `ExactInputParams` must have a deadline set. Leaving it at the default value of 0 will result in a revert.

`USSDRebalancer.SellUSSDBuyCollateral()` dose not works as it always reverts at L201

Incorrect arithmetic expression will cause `BuyUSSDSellCollateral()` to revert as it attempts to facilitate a swap with a zero amount.

Oracle price should be denominated in DAI instead of USD

Using the collateral assets' oracle price at 100% of its value to mint USSD without a fee can be used for arbitrage.

`BuyUSSDSellCollateral()` relies on the settings and assumption about the value of certain collateral

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

`BuyUSSDSellCollateral()` may revert due to underflow when DAI depeg

Lack of Redeem Feature

The rather harsh requirement of `tokenAmount` makes it inapplicable for certain tokens

Lack of sanity check for `stoptime`

`rescueERC20` should allow the payer to claw back overpaid amount

Unnecessary precision loss in `_recipientBalance()`

[WP-M1] getRewards() can be triggered by external parties which will result in the rewards not be tracking properly by the system

`FeeBuyback` native token can not be rescued

Unsafe ERC20 methods

Flashloan `TEL` tokens to stake and exit in the same block can fake a huge amount of stake with minimal material cost

Bull can prevent `settleContract()`

Bull can `transferPosition()` to `address(0)` and the original order can be matched again

`withdrawToken()` should be able to specify the `recipient` in calldata

Unbounded `_unlockTime` allows the attacker to get a huge `stakedTimeBonus` and dominate the voting

`queue()` should increase `proposalsPassed` instead of `proposalsCreated`

Using `ERC721.transferFrom()` instead of `safeTransferFrom()` may cause the user's NFT to be frozen in a contract that does not support ERC721

An update gap in Chainlink's feed can malfunction the whole market

`price` can be 0 due to precision loss and further cause `_rebalancePoolsAndExecuteBatchedActions()` to revert

Attacker can steal the accumulated topup fees in the `topupproxy` contract's balance

`exchangeFee` can be escaped

`increaseLock()` should read `userDeposit[_receiver]` instead of `depositsOf[_msgSender()]`

Extend lock period should never result in a decrease of overall rewards (`total length of locked period * shares`)

First user can inflate `pointsPerShare` and cause `_correctPoints()` to revert due to overflow

Front run `distributeRewards()` can steal the newly added rewards

`escrowedReward` will be frozen in the contract if `escrowPool == address(0)` but `escrowPortion > 0`

Expired locks should not continue to earn rewards at the original high multiplier rate

Curve points should be guaranteed to be monotonic increasing

Attacker can manipulate the pricePerShare to profit from future users' deposits

Frontrun `deposit()` can cause the depositor to lose all the funds

Lack of sanity checks for new plugin address in `addPlugin()`

When one of the plugins is broken or paused, `deposit()` or `withdraw()` of the whole Vault contract can malfunction

`_withdrawFromPlugin()` will revert when `_withdrawalValues[i] == 0`

`UniV2LPOracle` will malfunction if token0 or token1's `decimals != 18`

`ChainlinkOracle.sol#getPrice()` The price will be wrong when the token's USD price feed's `decimals != 8`

Tokens received from Curve's `remove_liquidity()` should be added to the assets list even if `_min_amounts` are set to `0`

A malicious early user/attacker can manipulate the LToken's pricePerShare to take an unfair share of future users' deposits

`ERC4626Oracle` Price will be wrong when the ERC4626's `decimals` is different from the underlying token’s decimals

`updateState()` should be called in `depositEth()` and `redeemEth()`

Accounts with ETH loans can not be liquidated if LEther's underlying is set to `address(0)`

`Reserves` should not be considered part of the available liquidity while calculating the interest rate

Turning `isCollateralAllowed[token]` from `true` to `false` with `toggleCollateralStatus()` won't disallow the token to be continued used as collateral

Lack of price freshness check in `ChainlinkOracle.sol#getPrice()` allows a stale price to be used

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

`Twav.sol#_getTwav()` will revert when timestamp > 4294967296

`_updateTwav()` and `_getTwav()` will revert when cumulativePrice overflows

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

Arbitrage on `stake()`

`_storeRebase()` is called with the wrong parameters

Tempus lend method wrongly calculates amount of iPT tokens to mint

Unable to redeem from Notional

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

[H-05] Not minting iPTs for lenders in several lend functions

Pendle Uses Wrong Return Value For `swapExactTokensForTokens()`

Swivel lend method doesn't pull protocol fee from user

`zeroswap/UniswapV2Library.sol` Wrong init code hash in `UniswapV2Library.pairFor()` will break `UniswapV2Oracle`, `UniswapV2Router02`, `SushiRoll`

`lending-market/NoteInterest.sol` Wrong implementation of `getBorrowRate()`

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

Stealing Wrapped Manifest in WETH.sol

WETH.sol computes the wrong totalSupply()

Anyone can set the `baseRatePerYear` after the `updateFrequency` has passed

Transferring any amount of the underlying token to the CNote contract will make the contract functions unusable

Anyone can create Proposal Unigov Proposal-Store.sol

Comptroller uses the wrong address for the WETH contract

AccountantDelegate: sweepInterest function will destroy the cnote in the contract.

`zeroswap/UniswapV2Pair.sol` Token reserves per lp token can be manipulated due to lack of `MINIMUM_LIQUIDITY` when minting the first liquidity with `migrator`

Maker buy order with no specified NFT tokenIds may get fulfilled in `matchOneToManyOrders` without receiving any NFT

Accumulated ETH fees of InfinityExchange cannot be retrieved

Maker order buyer is forced to reimburse the gas cost at any `tx.gasprice`

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

InfinityExchange computes gas refunds in a way where the first order's buyer pays less than the later ones

Wrong implementation of `withdrawAdminFees()` can cause the `adminFees` to be charged multiple times and therefore cause users' fund loss

`PortcalFacet.repayAavePortal()` can trigger an underflow of `routerBalances`

Tokens with `decimals` larger than `18` are not supported

`Minter.sol#startInflation()` can be bypassed

`BkdLocker#depositFees()` can be front run to steal the newly added rewardToken

`Minter.sol#_executeInflationRateUpdate()` `inflationManager().checkpointAllGauges()` is called after InflationRate is updated, causing users to lose rewards

`VE3DLocker.sol` Wrong implementation of inversely traverse for loops always reverts

VotingEscrow's merge and withdraw aren't available for approved users

Owner's delegates should be decreased in `_burn()`

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

Wrong calculation for the new `rewardRate[token]` can cause some of the late users can not get their rewards

Bribe.sol is not meant to handle fee-on-transfer tokens

`BathPair.sol#rebalancePair()` can be front run to steal the pending rebalancing amount

`BathToken.sol#_deposit()` attacker can mint more shares with re-entrancy from hookable tokens

First depositor can break minting of shares

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

Outstanding Amount Of A Pool Reduced Although Tokens Are Not Repaid

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

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

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

Withdrawing ETH collateral with max uint256 amount value reverts transaction

`CrvDepositor.sol` Wrong implementation of the 2-week buffer for lock

[WP-H0] Fake balances can be created for not-yet-existing ERC20 tokens, which allows attackers to set traps to steal funds from future users

Use safeTransferFrom instead of transferFrom for ERC721 transfers

Owner can set the feeRate to be greater than 100% and cause all future calls to `exercise` to revert

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

[WP-H1] Debt can be repaid with a depegged underlyingToken, which can be exploited by arbitrageurs and drives the market price of alToken to match the worst depegged underlyingToken

SpeedBumpPriceGate: Excess ether did not return to the user

`SpeedBumpPriceGate.sol#addGate()` Lack of input validation may casue div by 0 error

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

Many unbounded and under-constrained variables in the system can lead to unfair price or DoS

Critical variables shouldn't be changed after they are set

Missing check in the updateValset function

Admin drains all ERC based user funds using withdrawERC20()

Protocol doesn't handle fee on transfer tokens

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

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

Lender is able to seize the collateral by changing the loan parameters

Mistake while checking LTV to lender accepted LTV

Reentrancy at _requestLoan allows requesting a loan without supplying collateral

[WP-M8] `CompoundHandler#topUp()` Using the wrong function selector makes native token `topUp()` always revert

[WP-M9] `CEthInterface#repayBorrowBehalf()` reading non-existing returns makes `_repayAnyDebt()` with CEther always revert

[WP-M11] `CEthInterface#mint()` reading non-existing returns makes `topUp()` with native token alway revert

Chainlink's latestRoundData might return stale or incorrect results

`_decimalMultiplier` doesn't account for tokens with decimals higher than 18

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

[WP-H0] `xERC4626.sol` Some users may not be able to withdraw until `rewardsCycleEnd` the due to underflow in `beforeWithdraw()`

`UniswapV2PriceOracle.sol` `currentCumulativePrices()` will revert when `priceCumulative` addition overflow

Chainlink's latestRoundData might return stale or incorrect results

Existing user’s locked JPEG could be overwritten by new user, causing permanent loss of JPEG funds

yVault: First depositor can break minting of shares

[WP-H22] Bad debts should not continue to accrue interest

[WP-H9] `_swapUniswapV2` may use an improper `path` which can cause a loss of the majority of the rewardTokens

Chainlink pricer is using a deprecated API

`requiredImprovementRate` can not work as expected when `previousInterestRate` less than 10 due to precision loss

`mintBorrowTicketTo` can be a contract with no `onERC721Received` method, which may cause the BorrowTicket NFT to be frozen and put users' funds at risk

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

Splitter: Anyone can call incrementWindow to steal the tokens in the contract

CoreCollection can be reinitialized

Funds cannot be withdrawn in `CoreCollection.withdraw`

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

Wrong implementation of `NoYield.sol#emergencyWithdraw()`

Wrong returns of `SavingsAccountUtil.depositFromSavingsAccount()` can cause fund loss

Aave's share tokens are rebasing breaking current strategy code

https://github.com/sublime-finance/sublime-v1/blob/46536a6d25df4264c1b217bd3232af30355dcb95/contracts/PooledCreditLine/LenderPool.sol#L404-L406

`NoYield.sol` Tokens with fee on transfer are not supported

[WP-M10] Lack of access control allow anyone to `withdrawInterest()` for any lender

`DropPerSecond` is not updated homogeneously, the rewards emission can be much higher than expected in some cases

[WP-H7] Infinite approval to an arbitrary address can be used to steal all the funds from the contract

DexManagerFacet: batchRemoveDex() removes first dex only

cBridge integration fails to send native tokens

Reputation Risks with `contractOwner`

Anyone can get swaps for free given certain conditions in `swap`.

`msg.value` is Sent Multipletimes When Performing a Swap

`makePayment()` Lack of access control allows malicious `lender` to retrieve a large portion of the funds earlier, making the borrower suffer fund loss

Anyone can call `closeLoan()` to close the loan

Unsafe implementation of `fundLoan()` allows attacker to steal collateral from an unfunded loan

First depositor can break minting of shares

[WP-M10] Wrong formula of `getSharesForAmount()` can potentially cause fund loss when being used to calculate the `shares` to be used in `withdraw()`

[WP-H0] Wrong implementation of `EIP712MetaTransaction`

[WP-H2] `EIP712MetaTransaction.executeMetaTransaction()` failed txs are open to replay attacks

COLLATERAL_MINTER_ROLE can be granted by the deployer of QuantConfig and mint arbitrary amount of tokens

Usage of deprecated Chainlink functions

[WP-M3] `OperateProxy.callFunction()` should check if the `callee` is a contract

[WP-H6] Admin of the upgradeable proxy contract of `Controller.sol` can rug users

[WP-H4] Deleting `nft Info` can cause users' `nft.unpaidRewards` to be permanently erased

[WP-H14] `LiquidityProviders.sol` The share price of the LP can be manipulated and making future liquidityProviders unable to `removeLiquidity()`

[WP-H17] Users will lose a majority or even all of the rewards when the amount of total shares is too large, due to precision loss

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

[WP-H5] `LiquidityFarming.sol` Unbounded for loops can potentially freeze users' funds in edge cases

A `pauser` can brick the contracts

[WP-H23] Improper `tokenGasPrice` design can overcharge user for the gas cost by a huge margin

Possible frontrun on deposits on LiquidityPool

Sending tokens close to the maximum will fail and user will lose tokens

Incentive Pool can be drained without rebalancing the pool

`TimeswapPair.sol#borrow()` Improper implementation allows attacker to increase `pool.state.z` to a large value

`TimeswapConvenience.sol#borrowGivenDebt()` Attacker can increase `state.y` to an extremely large value with a dust amount of `assetOut`

Manipulation of the Y State Results in Interest Rate Manipulation

[WP-H1] Wrong timing of check allows users to withdraw collateral without paying for the debt

`TimeswapPair.sol#mint()` Malicious user/attacker can mint new liquidity with an extremely small amount of `yIncrease` and malfunction the pair with the maturity

[WP-H3] `money-market-contracts/oracle#feed_prices()` delayed transaction may disrupt price feeds

[WP-H0] When transferring tokens not in `whitelist` on Ethereum to Terra with `CrossAnchorBridge.depositStable()`, the funds may get frozen

[WP-H2] `money-market-contracts/contracts/market` `claim_rewards` may revert due to `spend_limit` set on `distributor`

[WP-H4] `anchor_basset_reward` pending yields can be stolen

An offer made after auction end can be stolen by an auction winner

Primary seller can avoid paying the primary fee

[WP-M5] Royalties can be distribution unfairly among `creatorRecipients` for NFT contracts with non-standard `getRoyalties()` returns

[WP-M6] Inappropriate support of EIP-2981

[WP-H1] Transactions can be replayed when a connectedChain is removed and then reconnected

[WP-H2] When transferring tokens native on SKALE to Ethereum with `TokenManagerERC20.exitToMainERC20()`, the tokens on the schain will be frozen on `TokenManagerERC20`, but they will not receive tokens on Ethereum

[WP-H3] S2S Transfer from the origin schain to another schain with automatic deploy disabled can cause funds to be frozen

TurboRouter: deposit(), mint(), createSafeAndDeposit() and createSafeAndDepositAndBoost() functions do not work

[WP-M2] Wrong implementation of `TurboSafe.sol#less()` may cause boosted record value in TurboMaster bigger than actual lead to `BoostCapForVault` and `BoostCapForCollateral` to be permanently occupied

[WP-H7] `InsuranceFund#syncDeps()` may cause users' fund loss

Assets sent from MarginAccount to InsuranceFund will be locked forever

Liquidations can be run on the bogus Oracle prices

transferBribes could transfer before proposal deadline + Input validation

Wrong slippage check

Changing `bribeVault` in `RewardDistributor.sol` will Lock Current ETH Rewards

[WP-H0] `DEFAULT_ADMIN_ROLE` of `BribeVault` can steal tokens from users' wallets

[WP-H2] Improper control over the versions of distributions' metadata may lead to repeated claims of rewards

isResolverCached() will always return false after removing operator

`NestedFactory.sol#_submitInOrders()` Wrong implementation cause users to be overcharged

Ensure on-chain that cache is synced

[WP-M1] Inappropriate handling of `referralFee` makes collecting Mirror fails without error when `referrerProfileId` is burned

[WP-H3] Imprecise management of users' allowance allows the admin of the upgradeable proxy contract to rug users

Seven ways in which the Owner and Proxy Admin can make users lose funds ("rug vectors")

[WP-H3] `saleRecipient` can rug buyers

[WP-H8] `ConvexStakingWrapper.sol#_calcRewardIntegral` Wrong implementation can disrupt rewards calculation and distribution

[WP-H13] `MasterChef.sol` Users won't be able to receive the `concur` rewards

[WP-H14] `ConvexStakingWrapper`, `StakingRewards` Wrong implementation will send `concur` rewards to the wrong receiver

deposit in ConvexStakingWrapper will most certainly revert

`MasterChef.updatePool()` Fails To Update Reward Variables If `block.number >= endBlock`

[WP-M0] `USDMPegRecovery.sol#provide()` Improper design/implementation make it often unable to add liquidity to the `usdm3crv` pool

[WP-H1] Rewards distribution can be disrupted by a early user

[WP-H2] `ConvexStakingWrapper#deposit()` depositors may lose their funds when the `_amount` is huge

[WP-H16] `MasterChef.sol` A `depositor` can deposit an arbitrary amount without no cost

[WP-H28] `StakingRewards.sol#notifyRewardAmount()` Improper reward balance checks can make some users unable to withdraw their rewards

[WP-H29] `StakingRewards.sol` `recoverERC20()` can be used as a backdoor by the `owner` to retrieve `rewardsToken`

[WP-M17] `USDMPegRecovery.sol#withdraw()` withdraw may often fail

Rewards distribution can be disrupted by a early user

Oracle data feed is insufficiently validated.

`UniV2ClassDex.sol#uniClassSell()` Tokens with fee on transfer are not fully supported

`sNOTE.sol#_mintFromAssets()` Lack of slippage control

Usage of deprecated ChainLink API in `EIP1271Wallet`

Use safeTransfer/safeTransferFrom consistently instead of transfer/transferFrom

Pair creation can be denied

ERC20 return values not checked

`createRJLaunchEvent()` can be called by anyone with 1 Wei of `_token` and stop others from creating RJLaunchEvent with the same token anymore

[WP-H0] In the case of Single Asset Entry, new liquidity providers will suffer fund loss due to wrong formula of ΔRo

[WP-H2] Transferring `quoteToken` to the exchange pool contract will cause future liquidity providers to lose funds

[WP-H1] The value of LP token can be manipulated by the first minister, which allows the attacker to dilute future liquidity providers' shares

[WP-H5] `L1Migrator.sol#migrateETH()` dose not send `bridgeMinter`'s ETH to L2 causing ETH get frozen in the contract

[WP-M0] `MINTER_ROLE` can be granted by the deployer of L2LivepeerToken and mint arbitrary amount of tokens

[WP-M1] `BURNER_ROLE` can burn any amount of L2LivepeerToken from an arbitrary address

[WP-M2] `DEFAULT_ADMIN_ROLE` can approve arbitrary address to spend any amount from the `L1Escrow` contract

[WP-H3] `L1Migrator.sol#migrateETH()` Improper implementation of `L1Migrator` causing `migrateETH()` always reverts, can lead to ETH in `BridgeMinter` getting stuck in the contract

[WP-M4] Unable to use `L2GatewayRouter` to withdraw LPT from L2 to L1, as `L2LPTGateway` does not implement `L2GatewayRouter` expected method

Initial pool deposit can be stolen

backdoor in `withdrawRedundant`

[WP-H24] Wrong design/implementation of permission control allows malicious/compromised Registry or Factory admin to steal funds from users' wallet balances

[WP-H27] `IndexTemplate.sol#compensate()` will most certainly fail

[WP-H29] `Vault#setController()` owner of the Vault contracts can drain funds from the Vault

[WP-H30] A malicious/compromised Registry or Factory admin can drain all the funds from the Vault contracts

[WP-H33] `IndexTemplate.sol` Wrong implementation allows lp of the index pool to resume a locked `PayingOut` pool and escape the responsibility for the compensation

[WP-H36] Admin of the index pool can `withdrawCredit()` after `applyCover()` to avoid taking loss for the compensation paid for a certain pool

[WP-H39] `PoolTemplate.sol#resume()` Wrong implementation of `resume()` will compensate overmuch redeem amount from index pools

[WP-M17] `Vault.sol` Tokens with fee on transfer are not supported

Unbounded iteration over all indexes (2)

[WP-H12] `forceUnsponsor()` may open a window for attackers to manipulate the `_totalShares` and freeze users' funds at a certain deposit amount

deposit() function is open to reentrancy attacks

Vaults with non-UST underlying asset vulnerable to flash loan attack on curve pool

[WP-H0] Late users will take more losses than expected when the underlying contract (`EthAnchor`) suffers investment losses

[WP-H2] `NonUSTStrategy.sol` Improper handling of swap fees allows attacker to steal funds from other users

[WP-M8] `totalUnderlyingMinusSponsored()` may revert on underflow and malfunction the contract

[WP-H9] Centralization Risk: Funds can be frozen when critical key holders lose access to their keys

Vault can't receive deposits if underlying token charges fees on transfer

unsponsor, claimYield and withdraw might fail unexpectadly

`TimeswapPair.sol#borrow()` Improper implementation allows attacker to increase `pool.state.z` to a large value

`TimeswapConvenience.sol#borrowGivenDebt()` Attacker can increase `state.y` to an extremely large value with a dust amount of `assetOut`

Manipulation of the Y State Results in Interest Rate Manipulation

[WP-H1] Wrong timing of check allows users to withdraw collateral without paying for the debt

`TimeswapPair.sol#mint()` Malicious user/attacker can mint new liquidity with an extremely small amount of `yIncrease` and malfunction the pair with the maturity

Malicious early user/attacker can malfunction the contract and even freeze users' funds in edge cases

`_safeMint` Will Fail Due To An Edge Case In Calculating `tokenId` Using The `_generateNewTokenId` Function

A vault can be locked from MarketplaceZap and StakingZap

The return value of the _sendForReceiver function is not set, causing the receiver to receive more fees

`NFTXMarketplaceZap.sol#buyAnd***()` should return unused weth/eth back to `msg.sender` instead of `to`

transfer return value is ignored

SHOULD CHECK RETURN DATA FROM CHAINLINK AGGREGATORS

Unused ERC20 tokens are not refunded, and can be stolen by attacker

ERC20 return values not checked

`totalSupply` may exceed `LibBasketStorage.basketStorage().maxCap`

Function `joinTokenSingle` in `SingleTokenJoin.sol` and `SingleTokenJoinV2.sol` can be made to fail

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

Malicious tickets can lead to the loss of all tokens

`createPromotion()` Lack of input validation for `_epochDuration` can potentially freeze promotion creator's funds

Contract does not work with fee-on transfer tokens

`cancelPromotion()` Unable to cancel unstarted promotions

Wrong implementation of `NoYield.sol#emergencyWithdraw()`

Wrong returns of `SavingsAccountUtil.depositFromSavingsAccount()` can cause fund loss

Aave's share tokens are rebasing breaking current strategy code

https://github.com/sublime-finance/sublime-v1/blob/46536a6d25df4264c1b217bd3232af30355dcb95/contracts/PooledCreditLine/LenderPool.sol#L404-L406

`NoYield.sol` Tokens with fee on transfer are not supported

[WP-M10] Lack of access control allow anyone to `withdrawInterest()` for any lender

`makePayment()` Lack of access control allows malicious `lender` to retrieve a large portion of the funds earlier, making the borrower suffer fund loss

Anyone can call `closeLoan()` to close the loan

Unsafe implementation of `fundLoan()` allows attacker to steal collateral from an unfunded loan

`YearnVault.sol#pull()` will most certainly fail

AaveVault does not update TVL on deposit/withdraw

Wrong implementation of `performanceFee` can cause users to lose 50% to 100% of their funds

`UniV3Vault.sol#collectEarnings()` can be front run

`ChiefTrader.sol` Wrong implementation of `swapExactInput()` and `swapExactOutput()`

ts.tokens sometimes calculated incorrectly

Wrong calculation of excess depositToken allows stream creator to retrieve `depositTokenFlashloanFeeAmount`, which may cause fund loss to users

Improper implementation of `arbitraryCall()` allows protocol gov to steal funds from users' wallets

Storage variable unstreamed can be artificially inflated

LockeERC20 is vulnerable to frontrun attack

Timelock can be bypassed

`AuctionBurnReserveSkew.getPegDeltaFrequency()` Wrong implementation can result in an improper amount of excess Liquidity Extension balance to be used at the end of an auction

Frontrunning in UniswapHandler calls to UniswapV2Router

`MovingAverage.setSampleMemory()` may broke MovingAverage, making the value of `exchangeRate` in `StabilizerNode.stabilize()` being extremely wrong

theft of system profit

`MixinTransfer.sol#transferFrom` Wrong implementation can potentially allows attackers to reverse transfer and cause fund loss to the users

Wrong design/implementation of freeTrial allows attacker to steal funds from the protocol

Potential economic attack on UDT grants to the referrer

Malicious user can get infinite free trial by repeatedly refund and repurchase right before the freeTrial ends

Support of different ERC20 tokens

Refund mechanism doesn't take into account that key price can change

_totalSupply not updated in _transferMint() and _transferBurn()

Improper Upper Bound Definition on the Fee

Controller does not raise an error when there's insufficient liquidity

An attacker can steal funds from multi-token vaults

`YaxisVaultAdapter.sol#withdraw()` will most certainly fail

`setGuardian()` Wrong implementation

Improper implementation of slippage check

Excessive `require` makes the transaction fail unexpectedly

Missing `_token.approve()` to `curvePool` in `setZapConfig`

No slippage control on `deposit` of IbbtcVaultZap.sol

isResolverCached() will always return false after removing operator

`NestedFactory.sol#_submitInOrders()` Wrong implementation cause users to be overcharged

Ensure on-chain that cache is synced

Early user can break `addLiquidity`

Lack of access control allow attacker to `mintFungible()` and `mintSynth()` with other user's wallet balance

`mintSynth()` and `burnSynth()` can be front run

`Synth` tokens can get over-minted

Wrong design/implementation of `addLiquidity()` allows attacker to steal funds from the liquidity pool

Wrong design of `swap()` results in unexpected and unfavorable outputs

LPs of VaderPoolV2 can manipulate pool reserves to extract funds from the reserve.

Tokens with fee on transfer are not supported

Anyone Can Arbitrarily Call `FSDVesting.updateVestedTokens()`

Beneficiary cant get `fairSideConviction` NFT unless they only claim once, and only after it's fully vested

`user.creation` is updated incorrectly when the user tries to extend membership

Unable to claim vesting due to unbounded timelock loop

Contract BasicSale is missing an approve(address(vestLock), 2**256-1) call

Can not update target price

`SwapUtils.sol` Wrong implementation

Overwrite benRevocable

Unchecked transfers

`initialBalance` for native token is wrong

Approved spender can spend too many tokens

The design of `wibBTC` is not fully compatible with the current Curve StableSwap pool

WrappedIbbtcEth contract will use stalled price for mint/burn if updatePricePerShare wasn't run properly

`FeePoolV0.sol#distributeMochi()` will unexpectedly flush `treasuryShare`, causing the protocol fee cannot be properly accounted for and collected

Anyone can extend withdraw wait period by depositing zero collateral

Vault fails to track debt correctly that leads to bad debt

`ReferralFeePoolV0.sol#claimRewardAsMochi()` Array out of bound exception

A malicious user can potentially escape liquidation by creating a dust amount position and trigger the liquidation by themself

Unchecked ERC20 transfer calls

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

Wrong calculation of `erc20Delta` and `ethDelta`

Arbitrary contract call allows attackers to steal ERC20 from users' wallets

Swap.sol implements potentially dangerous transfer

Unused ERC20 tokens are not refunded

Usage of an incorrect version of `Ownbale` library can potentially malfunction all `onlyOwner` functions

`QuickAccManager.sol#cancel()` Wrong `hashTx` makes it impossible to cancel a scheduled transaction

Signature replay attacks for different identities (nonce on wrong party)

Wrong implementation of `CreditLimitByMedian.sol#getLockedAmount()` makes it unable to unlock `lockedAmount` in `CreditLimitByMedian` model

Wrong implementation of `CreditLimitByMedian.sol#getLockedAmount()` will lock a much bigger total amount of staked tokens than expected

`uncommit` sends tokens to the wrong user

The formula of number of prizes for a degree is wrong

`ConcentratedLiquidityPool.burn()` Wrong implementation

`ConcentratedLiquidityPoolManager`'s incentives can be stolen

`ConcentratedLiquidityPosition.sol#burn()` Wrong implementation allows attackers to steal yield

`ConcentratedLiquidityPosition.sol#collect()` Users may get double the amount of yield when they call `collect()` before `burn()`

ConcentratedLiquidityPoolManager.sol#claimReward() and reclaimIncentive() will fail when incentive.token is token0 or token1

Cannot claim reward

Liquidation can be escaped by depositing a Uni v3 position with 0 liquidity

Use of tokenB’s price instead of tokenA in determining account health will lead to protocol mis-accounting and insolvency

`HybridPool`'s reserve is converted to "amount" twice

Overflow in the `mint` function of `IndexPool` causes LPs' funds to be stolen

Index Pool always swap to Zero

IndexPool's INIT_POOL_SUPPLY is not fair.

`IndexPool.mint` The first liquidity provider is forced to supply assets in the same amount, which may cause a significant amount of fund loss

Controller does not raise an error when there's insufficient liquidity

An attacker can steal funds from multi-token vaults

`YaxisVaultAdapter.sol#withdraw()` will most certainly fail

`PostAuctionLauncher.sol#finalize()` Adding liquidity to an existing pool may allows the attacker to steal most of the tokens