User withdrawals can be griefed via indirect vault deposits

Users lose profit in `mintRollovers` from incorrect variable used

Funds can be stolen because of incorrect update to `ownerToRollOverQueueIndex` for existing rollovers

Earlier users in rollover queue can grief later users

`depositFee` can be bypassed via deposit queue

Stuck emissions for nullified epochs

Minting queue deposits / rollovers fails after ~24.5k enrollments as it exceeds arbitrum gas limit

No way to remove dust orders in the rollover queue

Incorrect shares accounting cause liquidations to fail in some cases

Broken Operator Mechanism: Just 1 malicious / compromised operator can permanently break functionality

Migrator contract lacks sufficient permissions over vault positions

Slashing fails if claims revert

Audit Report

Slashing can be frontrun

Curve is not guaranteed to be monotonically increasing

Insufficient input validation of `escrowPortion` and `escrowPool`

Rewards distribution may be frontrun

Use `safeTransferFrom()` instead of `transferFrom()` for outgoing erc721 transfers

Funds can be held hostage due to uncapped fee

Unsafe casting of user amount from `uint256` to `uint128`

Hardcoded USD pegs can be broken

Calculated `token0TVL` may be zero under certain scenarios

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

`UNISWAP_FEE` is hardcoded which will lead to significant losses compared to optimal routing

Expiration calculation overflows if call option duration ≥ 195 days

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

SpeedBumpPriceGate: Excess ether did not return to the user

MerkleResistor: zero coinsPerSecond will brick tranche initialization and withdrawals

Malicious token reward could disable withdrawals

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

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

yVaultLPFarming: No guarantee JPEG currentBalance > previousBalance

Controller: Strategy migration will fail

Oracle data feed is insufficiently validated.

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

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

ERC20 transferFrom return values not checked

Funds cannot be withdrawn in `CoreCollection.withdraw`

Ineffective Handling of FoT or Rebasing Tokens

CoreCollection: Starting index is pseudo-randomly generated, allowing for gameable NFT launches

Differing percentage denominators causes confusion and potentially brick claims

LenderPool: Principal withdrawable is incorrectly calculated if start() is invoked with non-zero start fee

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

Interest accrued could be zero for small decimal tokens

`AnyswapFacet` can be exploited to approve arbitrary tokens.

Should prevent users from sending more native tokens in the `startBridgeTokensViaCBridge` function

LibSwap: Excess funds from swaps are not returned

DexManagerFacet: batchRemoveDex() removes first dex only

cBridge integration fails to send native tokens

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

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

WhitelistPeriodManager: Improper state handling of exclusion removals

WhitelistPeriodManager: Improper state handling of exclusion additions

Improper Upper Bound Definition on the Fee

Owners have absolute control over protocol

Incompatibility With Rebasing/Deflationary/Inflationary token

Wrong slippage check

ThecosomataETH: Oracle price can be better secured (freshness + tamper-resistance)

[WP-H3] `saleRecipient` can rug buyers

Masterchef: Improper handling of deposit fee

[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

Repeated Calls to Shelter.withdraw Can Drain All Funds in Shelter

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

Unconstrained fee

deposit() function is open to reentrancy attacks

A Single Malicious Trusted Account Can Takeover Parent Contract

Medium: Consider alternative price feed + ensure _minLockPeriod > 0 to prevent flash loan attacks

`Vault.withdraw` mixes normalized and standard amounts

Vault: Swaps at parity with swap fee = withdrawal fee

Vault: Withdrawals can be frontrun to cause users to burn tokens without receiving funds in return

Anyone Can Arbitrarily Call `FSDVesting.updateVestedTokens()`

FSDVesting: Claiming tributes should call FSD token's corresponding functions

`initialBalance` for native token is wrong

reward tokens could get lost due to rounding down

Understanding the fee growth mechanism (why nearestTick is unsuitable)

ConcentratedLiquidityPool: initialPrice should be checked to be within allowable range

ConcentratedLiquidityPool: rangeFeeGrowth and secondsPerLiquidity math needs to be unchecked

ConcentratedLiquidityPool: secondsPerLiquidity should be modified whenever pool liquidity changes

ConcentratedLiquidityPool: incorrect feeGrowthGlobal accounting when crossing ticks

`ConcentratedLiquidityPoolManager`'s incentives can be stolen

Wrong usage of `positionId` in `ConcentratedLiquidityPoolManager`

ConcentratedLiquidityPoolHelper: getTickState() might run out of gas

Cannot claim reward

`Vault.withdraw` mixes normalized and standard amounts

Vault: Swaps at parity with swap fee = withdrawal fee

Vault: Withdrawals can be frontrun to cause users to burn tokens without receiving funds in return

Uninitialized Variable `marketWhitelist` in `RCTreasury.sol`

No ERC20 safe* versions called

Rewards squatting - setting rewards in different ERC20 tokens opens various economic attacks.

Staker.sol: Wrong values returned in edge cases of _calculateFloatPerSecond()

SwappableYieldSource: Missing same deposit token check in transferFunds()

`redeemToken` can fail for certain tokens

Old yield source still has infinite approval

Pool.sol & Synth.sol: Failing Max Value Allowance

Missleading onlyDAO modifiers

DEPLOYER can drain DAOVault funds + manipulate proposal results

BondVault.sol: Possibly unwithdrawable bondedLP funds in claimForMember() + claimRate never zeros after full withdrawals

Dao.sol: Insufficient validation for proposal creation

Block usage of addCuratedPool