`payWithERC20()` exposes `from`, allowing an attacker to drain users

`createCommonProjectIDAndDeploymentRequest()` hardcodes request id index to 0, leading to lost requests for users

Attacker can call `submitDeploymentRequest()` and never deploy anything, DoSing users who have paid fees

Signatures are missing nonce and can be reused

Signatures missing some parameters being vulnerable to attackers using them coupled with malicious parameters

`SymmVesting::_addLiquidityProcess()` reverts whenever `lpVestingPlan.lockedAmount() + lpAmount < unlockedAmount`

`Vesting::resetVestingPlans()` can be frontrun by a user leading to double spending

`Leverager::isLiquidateable()` `base` calculation is incorrect when `base >= pos.initCollateralValue`

Base calculation in `Leverager::isLiquidateable()` is incorrect as the max leverage may be smaller

Strategy main ticks are set according to the tick in slot0, leading to incorrect allocation and loss of funds

Multihop swaps are impossible to use in the `Leverager`, leading to losses for users

`Leverager::withdraw()` repays incorrect amount due using amountOut1 instead of amountOut0

`Vault::withdraw()` withdraws too much liquidity leading to idle capital and loss of fees

`Vault::_calcDeposit()` will overflow for low priced tokens

`ReserveLogic::_updateIndexes()` assumes the utilization rate was constant the whole time when calculating the new borrows

Strategy main ticks are not symmetric when the tick spacing is one due to incorrect isLowerSided inequality

Secondary position in the Strategy unallocated capital due to incorrect tick allocation

`Strategy::checkPoolActivity()` incorrect check leads to vulnerable price

`Strategy::checkPoolActivity()` does not look as far back as it should

`totalCdsDepositedAmountWithOptionFees` is incorrectly reduced in `CDSLib::withdrawUser()`, leading to stuck option fees

`treasury.updateYieldsFromLiquidatedLrts()` updates the yield in the current chain, but collateral may be in the other chain

Borrower withdrawing at a loss will cause losses for cds depositors that only withdraw after the price recovers

Total cds deposited amount is incorrectly modified when cds depositor is at a loss, leading to stuck USDa

Nonce is not stored in `CDS:withdraw()`, allowing `excessProfitCumulativeValue` signatures to be reused

Cds withdrawer can steal other user/delay submitting`excessProfitCumulativeValue` due to missing signing info

Cds depositors profit up to the strike price is not redeemable as the total cds deposited amount is not increased

Cds depositor profit is never taxed as the tax is only applied on the option fees

Type 1 borrower liquidation will incorrectly add cds profit directly to `totalCdsDepositedAmount`

Mismatch between liquidation amount and total available reduction will lead to stuck collateral on liquidations

Liquidation profit is never given to cds depositors who will take these losses

`borrowing::withdraw()` at a loss will increase downside protected and misscalculate option fees

Cds amounts to reduce from each chain are incorrect and will lead to the inability to withdraw cds in one of the chains

Concurrency issues will overwrite omnichainData and users will not be able to withdraw

`borrowing::liquidate()` sends the wrong liquidation index to the destination chain, overwritting liquidation information and getting collateral stuck

Malicious user can call `borrowing::calculateCumulativeRate()` any number of times to inflate debt rate as `lastEventTime` is not updated

`CDS::updateDownsideProtected()` is missing access control, allowing anyone to increase `downsideProtected` and DoS cds withdrawals, making funds stuck

`Treasury::totalInterestFromLiquidation` can not be withdrawn

`strikePrice` is not validated on `borrowing::depositTokens()` and can be sent as the same price as the deposit to exploit

Missing downside protection as the borrower always has to pay the full USDa amount

Late abond holders steal USDa amount from liquidations from earlier abond holders

`BorrowLib::redeemYields()` burns abond from `msg.sender` but calculates yield from `user`, leading to exploits

`CDSLib::withdrawUserWhoNotOptedForLiq()` tax is not stored in the treasury

Borrower deposit, withdraw, deposit will reinit `omniChainData.cdsPoolValue`, getting profit stuck for cds depositors

`omniChainData.totalAvailableLiquidationAmount` is never reduced on cds withdrawal, leading to stuck collateral

Liquidation will reduce total cds deposited amount, leading to incorrect option fees

Accumulated profit/losses by the cumulative value is not dealt with in `borrowingLiquidation::liquidationType1()`, leading to losses

Malicious user will inflate/deflate `previousData.cdsPoolValue` as it pleases, DoSing withdrawals or bypassing 20% ratio

`borrowing::calculateCumulativeRate()` is called after the deposit/withdrawal, leading to incorrect debt amounts

`borrowing::_getDownsideFromCDS()` does not update downside protected on the amount available, DoSing withdrawals

`borrowLiquidation::liquidationType1()` fails for 100% LTV value

Interest generated by last bond will not go to anyone when liquidating as there is no bond amount to collect it

Interest generated from bonds deposited into external protocol is not accounted for correctly and will be stuck

`GlobalVariables::oftOrCollateralReceiveFromOtherChains()` calculates the fee as if it was the same in both chains, which is false

`GlobalVariables::oftOrCollateralReceiveFromOtherChains()` always charges twice the collateral on `COLLATERAL_TRANSFER`, which is not needed

`Treasury::yieldsFromLiquidatedLrts()` are not withdrawable and are stuck

`Treasury.noOfBorrowers` can be set to 0 by looping wei deposit<->withdrawals and DoS withdrawals and reset borrower debt

`CDSLib::calculateCumulativeRate()` incorrectly only increment the local option fees when there are cds deposits

`FluidLocker::_getUnlockingPercentage()` incorrectly divides one of the components of the formula by `S`, leading to always having `80%` penalty

`FluidLocker::_getUnlockingPercentage()` uses 540 instead of `540 days` leading to stuck funds as the unlocking percentage will be bigger than `100%` and underflow

`Fontaine` never stops the flows to the tax and recipient, so the buffer component of the flows will be lost

An attacker may DoS user Fluid balance increases by frontrunning `FluidLocker::claim()` calls and calling `EP_PROGRAM_MANAGER::batchUpdateUserUnits()` directly

`FluidLocker::_getUnlockingPercentage()` divides before multiplying, suffering a significant precision error

A malicious user may unlock instantly all the funds from the `FluidLocker` when no one is staking in the Tax pool

User to sell the last supply will make the exchange contribution forever stuck

`GoodDollarExchangeProvider::mintFromExpansion()` will change the price due to a rounding error in the new ratio

Malicious user may frontrun `GoodDollarExpansionController::mintUBIFromReserveBalance()` to make protocol funds stuck

`GoodDollarExpansionController::mintUBIFromExpansion()` expansion rate will not match the expected due to delays when calling it

`TradingLimits::update()` incorrectly only rounds up when `deltaFlowUnits` becomes 0, which will silently increase trading limits

`totalEarnings` is incorrect when withdrawing after ending which will withdraw too many funds leaving the `Vault` insolvent

The amount withdrawn by an user does not discount the fee paid which will leave funds stuck when calling `LidoVault::VaultEndedWithdraw()`

Attacker will DoS `LidoVault` up to 36 days which will ruin expected apr for all parties involved

Lido slashing after requesting the ending withdrawal will affect the stETH shares / eth, leading to some users inability to withdraw

Withdrawing after a slash event before the vault has ended will decrease `fixedSidestETHOnStartCapacity` by less than it should, so following users will withdraw more their initial deposit

`Listings::cancelListings()` overcharges extra funds from the user and will get them stuck

Malicious users will exploit the fact that `ProtectedListings::adjustPosition()` does not take a checkpoint and reduce their debt

The protocol will become insolvent and some nfts will be forever stuck

Users will steal excess funds from the Vault due to `VaultPoolLib::redeem()` not always decreasing `self.withdrawalPool.raBalance` and `self.withdrawalPool.paBalance`

Anyone can trigger `VaultLib::_liquidatedLp()` which does not call `lvRedeemRaWithCtDs()` with the correct amount and will lead to incorrect withdrawals and stuck funds

Admin new issuance or user calling `Vault::redeemExpiredLv()` after `Psm::redeemWithCt()` will lead to stuck funds when trying to withdraw

Attackers will steal the reserve from the `Vault` by receiving `ra` in `FlashSwapRouter::__swapDsforRa()`

Users redeeming early will withdraw `Ra` without decreasing the amount locked, which will lead to stolen funds when withdrawing after expiry

Users repurchasing will transfer funds to the vault without tracking the `Ra` deposited which will leave stuck `Ra` in the `Psm`

Users redeeming with `Ds` in the `Psm` will not decrease the correct amount of locked `Ra`, leading to stolen funds on withdrawals

`VaultPoolLib::reserve()` will store the `Pa` not attributed to user withdrawals incorrectly and leave in untracked once it expires again

`FlashSwapRouter` assumes the `Psm`'s `Ra:Ds+Ct` ratio is 1:1 which might not be the case and will lead to loss of funds for users of the router

Lack of slippage protection in the `VaultLib` will lead to MEV and users will take losses

Admin will not be able to only pause deposits in the `Vault` due to incorrect check leading to DoSed withdrawals

Admin will not be able to upgrade the smart contracts, breaking core functionality and rendering the upgradeable contracts useless

Withdrawing all `lv` before expiry will lead to lost funds in the Vault

Rebasing tokens are not supported contrary to the readme and will lead to loss of funds

`VaultLib::__addLiquidityToAmmUnchecked()` does not deal with the remaining amounts not sent to the amm, losing them

Malicious user will make prize stuck harming the winner/protocol due to `WinnablesTicketManager::cancelRaffle()/propagateRaffleWinner()` not validating `prizeManager` and `chainSelector`

`WinnablesTicketManager::refundPlayers()` will not decrease `_lockedETH` leading to stuck `ETH` for the protocol

Malicious user will completely DoS the protocol and waste all LINK tokens of the protocol

`WinnablesPrizeManager::setCCIPCounterpart()` allows the admins to freely send messages from other contracts which will steal all `WinnablesPrizeManager` funds

`WinnablesTicket` admin will set itself role `1` to mint tickets and steal prizes

Users buying too many tickets will DoS them and the protocol if they are the winner due to OOG

Depositing to another receiver othan than `msg.sender` will lead to stuck funds by increasing `avgStart` without claiming

Attackers will reset `avgStart` of any user making rewards stuck for longer and get lost to savings

Reward rate rounding error will cause significant loss of funds for all users

Frozen/paused Market that is harvested from in StakedEXA will DoS deposits leading to loss of yield

Setting a new market will make depositing to the market impossible when harvesting, DoSing deposits

Market utilization ratio near 100% will DoS deposits as harvest tries to withdraw and reverts

Anyone will DoS setting a new rewards duration which harms the protocol/users as they will receive too much or too little rewards

Having no deposits in `StakedEXA` will lead to stuck rewards when harvesting

Liquidating maturies with unassigned earnings will not take into account floating assets increase leading to loss of funds

Liquidations will leave dust when repaying expired maturities, making it impossible to clear bad debt putting the protocol at a risk of insolvency

Liquidator will leave a pool with unassigned earnings on `Market::clearBadDebt()` free to claim for anyone when the repaid maturity is not the last

Some bad debt will not be cleared when it should which will cause accrual of bad debt decreasing the protocol's solvency

`DrawManager::finishDraw()` may hand out more rewards than the reserve if RNG requests fail

Vault portion calculation in `PrizePool::getVaultPortion()` is incorrect as `_startDrawIdInclusive` has been erased

`Claimable` is vulnerable to return gas bomb attacks, DoSing claiming for all other winners

Witnet is not available on some networks listed

`Claimer::claimPrizes()` fee is incorrect and incurs very signficant costs whenever it is frontrunned

Winners in `Claimable` may game claimer bots by claiming the prize when the `beforeHook` is called on the hook

DoSed liquidations as `PrizeVault::liquidatableBalanceOf()` does not take into account the `mintLimit` when the token out is the asset

`PrizeVault::deposit/mint()` will always revert due to lossy deposits in yield vaults due to rounding errors when the yield buffer is depleted

Current Tpda liquidations can not deal with upwards yield fluctuations, leading to yield loss in some scenarios

Estimated prize draws in TieredLiquidityDistributor are off due to rounding down when calculating the sum, leading to incorrect prizes

`Requestor` uses `to.transfer()` to withdraw the balance of the creator, but the creator may not be able to receive it

`DrawManager::canStartDraw()` does not take into account failed requests, returning false when it should return true and harms bots

Inconsistent sequencer unexpected delay in DelayBuffer may harm users calling forceInclusion()

Incorrect withdraw queue balance in TVL calculation

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

ETH withdrawals from EigenLayer always fail due to `OperatorDelegator`'s nonReentrant `receive()`

DOS of `completeQueuedWithdrawal` when ERC20 buffer is filled

Withdrawals and Claims are meant to be pausable, but it is not possible in practice

Withdrawals can fail due to deposits reverting in `completeQueuedWithdrawal()`

`LenderCommitmentGroup_Smart` picks the wrong Uniswap price, allowing borrowing at a discount by swapping before withdrawing

Interest rate in `LenderCommitmentGroup_Smart` may be easily manipulated by depositing, taking a loan and withdrawing

Stuck tokens in `TellerV2` if `bid.loanDetails.lendingToken.transferFrom()` fails as `LenderCommitmentGroup_Smart` can not withdraw from `EscrowVault`

`LenderCommitmentGroup_Smart` does not use `SafeERC20`, which could lead to DoS or permanently loss funds

`LenderCommitmentGroup_Smart::burnSharesToWithdrawEarnings()` wrong exchange rate due to burning `poolSharesToken` before calculating it

Drained lender due to `LenderCommitmentGroup_Smart::acceptFundsForAcceptBid()` `_collateralAmount` by `STANDARD_EXPANSION_FACTOR` multiplication

`LenderCommitmentGroup_Smart::liquidateDefaultedLoanWithIncentive()` will lead to stuck collateral in `LenderCommitmentGroup_Smart`

Interest rate in `LenderCommitmentGroup_Smart` does not take into account the currently taken loan which will could lead to huge loans with very small interest rates

Issue #497 'Add parameter to lender accept bid for MaxMarketFee' from previous audit is still present

Incorrect selector in `FlashRolloverLoan_G5::_acceptCommitment()` does not match `SmartCommitmentForwarder::acceptCommitmentWithRecipient()`

`FlashRolloverLoan_G5` will fail for `LenderCommitmentGroup_Smart` due to `CollateralManager` pulling collateral from `FlashRolloverLoan_G5`

`FlashRolloverLoan_G5` will not work for certain tokens due to not setting the approval to `0` after repaying a loan

Missing `__Ownable_init()` call in `LenderCommitmentGroup_Smart::initialize()`

`LenderCommitmentGroup_Smart` does not use `mulDiv` when converting between token and share amounts, possibly leading to DoS or loss of funds

`LenderCommitmentGroup_Smart` does not handle fee on transfer tokens correctly, leading to loss of funds

`LenderCommitmentGroup_Smart_test::addPrincipalToCommitmentGroup/burnSharesToWithdrawEarnings()` are vulnerable to slippage attacks

`LenderCommitmentGroup_Smart` will not work for some `Uniswap` pools due to `sqrtPriceX96` overflow

`Edition` referrer never receives any fee, which goes to the `mint` referrer instead

`Edition::mintBatch(address[] calldata receivers_, ...)` calculates incorrect fees for minters

`TitlesGraph::checkSignature()` modifier does not implement EIP712 correctly as the `data` argument is not hashed in `ACK_TYPEHASH`

Manipulated `edge.acknowledged` due to signature applying both to `TitlesGraph::acknowledgeEdge()` and `TitlesGraph::unacknowledgeEdge()`

`TitlesGraph::checkSignature()` modifier is vulnerable to signature malleability, allowing the manipulation of `edge.acknowledged`

`TitlesGraph` upgradeability will not work as it is not deployed behind a proxy

`owner` of `FeeManager` is set to `TitlesCore`, which can not perform `onlyOwner` functions

`Edition::transferWork()` does not change the fee receiver to the new `creator`

Unassigned pool earnings can be stolen when a maturity borrow is liquidated by depositing at maturity with 1 principal

`Market` is vulnerable to inflation attacks

Profitable liquidations and accumulation of bad debt due to earnings accumulator not being triggered before liquidating

Users may reduce their post liquidation health factor by splitting assets in several markets

`TARGET_HEALTH` calculation does not consider the adjust factors of the picked seize and repay markets

`Market::liquidate()` will not work when most of the liquidity is borrowed due to wrong liquidator `transferFrom()` order

Incorrect previewed `totalFloatingBorrowAssets()` on liquidations due to not taking into account repaid maturities

Utilization rates are 0 when average assets are 0, which may be used to game maturity borrows / deposits / withdrawals

Expired maturities longer than `FixedLib.INTERVAL` with unaccrued earnings may be arbitraged and/or might lead to significant bad debt creation

`rewardData.releaseRate` is incorrectly calculated on `RewardsController::config()` when `block.timestamp > start` and `rewardData.lastConfig != rewardData.start`

If a maturity expires before an account handles borrow of the RewardsController, it will not have it's share, leading to lost rewards

In `ZivoeRewards::rewardPerToken()`, in periods where `totalSupply = 0` rewards will be forever lost

`OCC_Modular::amountOwed()` calculates `lateFee` incorrectly if more than 1 payment was missed

`OCL_ZVE::pushToLockerMulti()` assumes router will always pull all the balance, leading to DoS

`ZivoeYDL::earningsTrancheuse()` always assumes that `daysBetweenDistributions` have passed, which might not be the case

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

Stuck fees in `MarketFactory` as there is no function to withdraw them

Drained oracle fees from market by depositing and withdrawing immediately without triggering settlement fees

Rewards incorrectly use new stake amount when calculating rewards from previous periods

Lost rewards in `LMPVault` when withdrawing underlying from destination vaults

Anyone can claim rewards from the rewarders to the destination vaults, DoSing `LiquidationRow` and possibly leading to stuck tokens

Lost rewards claimed in `LiquidationRow` as the `swap()` function is not delegate called to in `liquidateVaultsForToken()`

Lost rewards when the supply is `0`, which always happens if the rewards are queued before anyone has `StakeTracker` tokens

`previewRedeem()` is not ERC4626 compliant and might cause unexpected losses for users

No more fees minted to sink due to inflated ratio when `totalSupply()` is very low

[HF06] `BaseTOFT.sol`: `retrieveFromStrategy` can be used to manipulate other user's positions due to absent approval check.

Exercise option cross chain message in the (m)TapiocaOFT will always revert in the destination, losing debited funds in the source chain

TOFT and USDO Modules Can Be Selfdestructed

Attacker can block LayerZero channel due to missing check of minimum gas passed

All assets of (m)TapiocaOFT can be stealed by depositing to strategy cross chain call with 1 amount but maximum shares possible

TOFT `removeCollateral` can be used to steal all the balance

TOFT in (m)TapiocaOft contracts can be stolen by calling removeCollateral() with a malicious removeParams.market

A user with a TapiocaOFT allowance >0 could steal all the underlying ERC20 tokens of the owner

triggerSendFrom() will send all the ETH in the destination chain where sendFrom() is called to the refundAddress in the LzCallParams argument

Rebalancing mTapiocaOFT of native token forces admin to pay for rebalance amount

mTapiocaOFT can't be rebalanced because the Balancer in tapiocaz-audit calls swapETH() or swap() of the RouterETH but does not forward ether for the message fee

It's possible to borrow, redeem, transfer tokens and exit markets with outdated collateral prices and borrow interest

Delegate rewards system is unfair to delegates with less tokens and reduces decentralization

time-sensitive contracts deployed on zkSync

Possibility to steal jackpot bypassing restrictions in the executeDraw()

Attacker can gain control of counterfactual wallet

wrong reward distribution between early and late depositors because of the late syncRewards() call in the cycle, syncReward() logic should be executed in each withdraw or deposits (without reverting)

any duration can be passed by node operator

slashing fails when node operator doesn't have enough staked `GGP`