Users can claim more that their actual allotment

Minting zero tokens when underlyingToken is not Ether in cashIn()

Rewards might be lost due to the error that _updateRewardIndex() might advance lastBalance without advancing index for a token.

PositionAction.decreaseLever() fails to consider the loan fee in Flashlender when calculating loanAmount, as a result, the functionanlity will not work when protocolFee != 0.

Incorrect calculation of `newCumulativeIndex` in function `calcDecrease`

WhenNotPaused modifier in the CDPVault can be bypassed by users

DOS attack to SwapAction.transferAndSwap() when using an ERC20 permit transferFrom.

CDPVault.liquidatePosition() does not scale ```takeCollateral``` with ```tokenScale``, therefore, it might send the wrong amount of collateral to the liquidator when tokenScale ! = 1 ether.

Roles._setRole() cannot delete a role from a user.

Rewards might be lost due to the error that _updateRewardIndex() might advance lastBalance without advancing index for a token.

PositionAction.decreaseLever() fails to consider the loan fee in Flashlender when calculating loanAmount, as a result, the functionanlity will not work when protocolFee != 0.

Incorrect calculation of `newCumulativeIndex` in function `calcDecrease`

WhenNotPaused modifier in the CDPVault can be bypassed by users

DOS attack to SwapAction.transferAndSwap() when using an ERC20 permit transferFrom.

CDPVault.liquidatePosition() does not scale ```takeCollateral``` with ```tokenScale``, therefore, it might send the wrong amount of collateral to the liquidator when tokenScale ! = 1 ether.

During emergency unlock, a call to addToPosition will reduce position.amountWithMultiplier , then the user might loss a lot of reward tokens in the future.

EthenaLib#_sellStakedUSDe() fails to enforce the slippage control using ```minPurchaseAmount``` when borrowToken is DAI. A user might receive less borrowToken than expected.

_claimRewardToken() will update accountRewardDebt even when there is a failure during reward claiming, as a result, a user might lose rewards.

Incorrect Comparison Logic in Post-Operation Checks

PositionMarginProcess.updatePositionFromBalanceMargin() returns the wrong ``changeAmount`` value for the case ``position.initialInUsdFromBalance <= addBorrowInUsd``.

GasProcess.processExecutionFee() calculates ``lossFee`` wrongly (always zero), and keepers might oss some portion of execution fee.

AssetsProcess.deposit() fails to check that the token balance of a user cannot exceed collateralUserCap.

settleFundingFees() might underflow and lead to incorrect huge value for marginDepositedTotal.

When borrowers repay USDS, it is sent to the wrong address, allowing anyone to burn Protocol Owned Liquidity and build bad debt for USDS

Token.updateFounders() might clear the wrong tokenRecipient[baseTokenId], as a result, not all old founders might be deleted.

No slippage protection for Market functions

The price of rsEHT could be manipulated by the first staker

Update in strategy will cause wrong issuance of shares

Incorrect flag results to _hasFallbackToggled always set to false on createMultipleSettlement.

An allocator might allocate ``voiceCredits`` without any limit, exceeding ``maxVoiceCreditsPerAllocator`` due to forgetting to increase allocator.voiceCredits.

QVBaseStrategy._qv_allocate() does not calculate _allocator.voiceCreditsCastToRecipient[_recipientId] correctly, as a result, the votes for each recipient and thus payout for each recipient will not be calculated correctly.

The settle feature will be broken if attacker arbitrarily transfer collateral tokens to the PerpetualAtlanticVaultLP

The peg stability module can be compromised by forcing lowerDepeg to revert.

Users can get immediate profit when deposit and redeem in `PerpetualAtlanticVaultLP`

`UniV3LiquidityAMO::recoverERC721` will cause `ERC721` tokens to be permanently locked in `rdpxV2Core`

Change of `fundingDuration` causes "time travel" of `PerpetualAtlanticVault.nextFundingPaymentTimestamp()`

LMPVaultRouterBase.mint() will double charge a user when the user sends asset tokens using eth (msg.value > 0), and then a stealer can steal the extra payment.

AbstractRewarder.queueNewRewards() will transfer ``(newRewards + queuedRewards)`` instead of ``newRewards`` reward tokens, as a result, the extra ``queuedRewards`` tokens will not be accounted and lost to the contract forever.

AbstractRewarder.notifyRewardAmount() does not calculate the leftover reward correctly when totalSupply() == 0 .

Collateral can be locked in BigBang contract when `debtStartPoint` is nonzero

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

twTAP.claimAndSendRewards() will claim the wrong amount for each reward token due to the use of wrong index.

[HB02] `BalancerStrategy.sol`: `_withdraw` withdraws insufficient tokens

`extractTAP()` function can allow minting an infinite amount in one week, leading to a DoS attack in `emitForWeek()`

averageMagnitude in TapiocaOptionBroker is updated wrongly

Potential loss of value in YieldBox's `depositETHAsset()`

RestakeToken function is not permissionless

Lack of slippage protection can lead to significant loss of user funds

updatePeriod() less mint HERMES

MarketUtils.getPoolValueInfo() does not use !maximize when evaluating impactPoolUsd, leading to wrong logic of maximizing or minimizing the pool value.

MarketUtils.getFundingAmountPerSizeDelta() has a rounding logical error.

PositionUtils.validatePosition() uses ``isIncrease`` instead of ``false`` when calling isPositionLiquidatable(), making it not work properly for the case of ``isIncrease = true``.

Unintentionally register a non-relevant DSN name owner

Incorrect implementation of RecordParser.readKeyValue()

HexUtils.hexStringToBytes32() and HexUtils.hexToAddress() may return incorrect results

setCollateralEscrowBeacon() has no access control, so anybody can change ``collateralEscrowBeacon``.

DOS attack to deployAndDeposit()

A malicous user can manipulate the amount of collateral for a borrower.

There is a race condition between updateCommitment() and acceptCommitment().

withdraw() has no access control, so a malicous user can use it to front-run repayLoanFull(), repay(), and liquidateLoanFull().

PrivatePool owner can steal all ERC20 and NFT from user via arbitrary execution

Transaction revert if the baseToken does not support 0 value transfer when charging changeFee

Loss of funds for traders due to accounting error in royalty calculations

`changeFeeQuote` will fail for low decimal ERC20 tokens

EthRouter can't perform multiple changes

Reward accounting is incorrect in BathBuddy contract

_redeemMoneyMarketIfRequired() will always overwithdraw from money market tokens, leading to losing some opportunities to earn from the money markets (losing of funds).

convertFromStorage() fails to use rounding-up when converting a negative storedCashBalance into signedPrimeSupplyValue.

AccountAction#withdraw() might fail when one of the other money markets (Compound, Aave, or Euler) fails temporarily.

Residual ETH unreachable and unuitilized in SafEth.sol

Wrong check condition for setLimit() because it fails to recognize the real effective ohm minting limit is ohmLimit + circulatingOhmBurned!

The useLoan() function (Dutch auction) will fail for some tokens when the price of the NFT becomes zero.

_decreaseCurrentMinted() does not revise currentMinted() correctly, as a result, a wrong mint limit might be enforced on a vault.

First depositor attack: first (early depositors) can steal funds from later depositors.

A liquidator can gain not only collateral, but also can reduce his own debt!

DOS attack to getHatLevel()

``pullFunds()`` might give the wrong account for ``savedTotalUnderlying``.

MainVault.deposit() fails to enforce the deposit maxium for white-listed depositors in training

Nobody can deposit when getVaultBalance() < reservedFunds

Users might claim more rewards than they deserve, leading loss of rewards to later claimers

Decimal issue with `` userRewardDebts`` might lead to over-claim/under-claim of rewards

User can lose up to whole stake on vault withdrawal when there are funds locked in the strategy

``lastFeeOperationTime`` is not modified correctly in function ``_updateLastFeeOpTime()``, resuling a much slower decay model for borrowing base rate

boundedSub() might fail to return the result that is bounded to prevent overflows

getNextFundingAmountPerSize() has a divide-before-multiply precision loss problem.

DOS attack to function ``_accruePremiumAndExpireProtections()`` due to iteration through all active protections.

A lender can bypass the protection amount limit check by buying more protections.

Front-running attack to lockCapital()

Sandwich attack to accruePremiumAndExpireProtections()

Nobody can deposit anymore after ``_underlyingAmount`` becomes ZERO.

Some protection buyers might not be able to renew their protections due to delayed expiration processing.

Attackers can call UToken.redeem() and drain the funds in assetManager

Some funds might be stuck in the bank contract forever, and nobody can withdraw them

A user who calls IchiVaultSpell.closePosition() might leave some ICHI vault LP tokens in the IchiVaultSpell for other users to steal (lose funds)

A borrower might drain the vault by calling borrow() repeatedly with small borrow amount each time.

IchiVaultSpell.openPosition() will always revert if ICHI Vault Lp Tokens are fees-on-transfer ERC20 tokens.

A partial refund using ``BountyCore.refundDeposit()`` will block ALL future partial/full refunds.

First vault depositor can steal other's assets

Users lose their entire investment when making a deposit and resulting shares are zero

DOS any Staking contract with Arithmetic Overflow

`MultiRewardStaking.changeRewardSpeed()` breaks the distribution

syncFeeCheckpoint() does not modify the highWaterMark correctly, sometimes it might even decrease its value, resulting charging more performance fees than it should

Owner can collect management fees with a new increased fee for previous time period.

`Vault.redeem` function does not use `syncFeeCheckpoint` modifier

VaultController() Missing call DeploymentController.nominateNewDependencyOwner()

`quitPeriod` is effectively always just `1 day`

Multiple accounts can have the same identity

Protocol fees can be withdrawn multiple times in `Erc20Quest`

Users may not claim Erc1155 rewards when the Quest has ended

The collect() function will always TRANSFER ZERO fees, losing _feesPositions without receiving fees!

_ownedTokensIndex is SHARED by different owners, as a result, _removeTokenFromAllTokensEnumeration might remove the wrong tokenId.

Burning a `ERC1155Enumerable` token doesn't remove it from the enumeration

setPendingRedemptionBalance() may cause the user's cash token to be lost

Should Accrue Before Change, Loss of Rewards in case of change of settings

When Public Vault A buys out Public Vault B's lien tokens, it does not increase Public Vault A's liensOpenForEpoch, which would result in the lien tokens not being repaid

Buying out corrupts the slope of a vault, reducing rewards of LPs

Deadlock in valuts with underlying token with less then 18 decimals

Users are unable to mint shares from a public vault using `AstariaRouter` contract when share price is bigger than one

_buyoutLien() does not properly validate the liquidationInitialAsk

Attacker can gain control of counterfactual wallet

Destruction of the `SmartAccount` implementation

Hijacking of node operators minipool causes loss of staked funds

AVAX Assigned High Water is updated incorrectly

Inflation rate can be reduce by half at most if it get called every 1.99 interval.

Coding logic of the contract upgrading renders upgrading contracts impractical

Liquidity providers may lose funds when adding liquidity

First depositor can break minting of shares

Rounding error in buyQuote might result in free tokens

Bypass the delay security check to win risk free funds

`_handleOpenFees` returns an incorrect value for `_feePaid`. This directly impacts margin calculations

Centralization risks: owner can freeze withdraws and use timelock to steal all funds

`_handleDeposit` and `_handleWithdraw` do not account for tokens with decimals higher than 18

A whale user is able to cause freeze of funds of other users by bypassing withdraw limit

Users do not receive owed tokens if `TokenSender` contract cannot cover their owed amount.

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

Use of `payable.transfer()` Might Render ETH Impossible to Withdraw

Anyone can prevent themselves from being liquidated as long as they hold one of the supported NFTs

Dao admin in LiquidStakingManager.sol can rug the registered node operator by stealing their fund in the smart wallet via arbitrary execution.

Compromised or malicious DAO can restrict actions of node runners who are not malicious

Yul `call` return value not checked

call opcode's return value not checked.

Public to all funds escape

Attacker may DOS auctions using invalid bid parameters

`_payoutToken[s]()` is not compatible with tokens with missing return value

beforeTokenTransfer called with wrong parameters in LBToken._burn