The EXPIRED judgment does not include the current block

If the Covenant signature does not pass , EXPIRED events it will still be executed.

In the create() and redeem() functions, the lastFeeClaimTime is not updated, which leads to incorrect fee calculations.

The joinBalancerPool() function does not return the remaining assets to the user.

bid() will result in a denial of service (DoS) attack if the bidder address is on the blacklist.

In the joinBalancerAndPredeposit() function, the remaining Balancer Pool Tokens are not returned to the user.

It is possible to manipulate the price of the BondToken by constructing a dexPool.

Using LayerZero for synchronizing global states between two chains may lead to overwriting of global states.

In redeemUSDT(), users can arbitrarily set the price parameters.

In the liquidate() function, the remaining gas fee should be allocated to the caller (admin) instead of the user.

The position of calculateCumulativeRate in the depositTokens() and withDraw() functions is incorrect.

Resolver is not initialized in the protocol's keeper

The UsualSP::removeOriginalAllocation() function is missing the update of the user’s reward data.

In the deposit() function, due to the lack of a check on deposit_token, an attacker can use the Mint of any token to replace the Mint of USDC.

The absence of the addExecutorOrderedExecutionOption parameter causes the ordered delivery mode to fail.

Reentrancy check in account_contract can be easily circumvented

Missing permission control in create_oracle and create_pool.

There is a logical error inside the ProtectedListings::adjustPosition() function, which could lead to manipulation of users’ interest.

There is a calculation error inside the calculateCompoundedFactor() function, causing users to overpay interest.

The relist() function lacks a check on listing.created, which allows borrowing money from the listing without incurring interest.

Due to the delay in converting token1 fees into token0 (WETH) fees in beforeSwap(), an attacker can execute a sandwich attack to gain risk-free profits.

InfernalRiftBelow.thresholdCross verify the wrong msg.sender

InfernalRiftBelow.claimRoyalties no verification msg.sender

Users with more than 50% of the voting rights can steal other users' tokens.

The shutdown can still be canceled after execute, causing users to fail to claim tokens.

The tokens (collectionTokens and WETH) used for initializeCollection() to create a liquidity position are permanently locked in Uniswap V4.

The fee set by the setFee() function will not take effect.

The unused tokens from the user’s initialization of UniswapV4‘s pool will be locked in the UniswapImplementation contract.

There is a logical error in the removeFeeExemption() function.

There is a calculation error inside the modifyListings() function.

There is a logical error in the _distributeFees() function, resulting in an unfair distribution of fees.

An attacker can block the execution of CollectionShutdown.execute

In the unlockProtectedListing() function, the interest that was supposed to be distributed to LP holders was instead burned.

Malicious users can exploit createListings() and liquidateProtectedListing() functions in the ProtectedListings contract to replace Listings::createListings() in order to evade paying the tax fee.”

The liquidate() function requires that after liquidation, the position must be in a healthy state. This may result in certain positions never being liquidated if they cannot reach a healthy state, potentially leaving them in limbo.

The getValueInEth function should include a price refresh mechanism to prevent outdated prices from causing financial losses for users.

The liquidationFee should be applied to the profit from the liquidation, rather than to all the assets obtained by the liquidator.

Using forceApprove instead of approve

The issue regarding the missing pause functionality has not been resolved.

There is a calculation error in AuraVault::redeem().

AuraVault inherits AccessControl BUT does not call the _setupRole() function in it's constructor to set the initial roles, this leads to a complete DOS of the important claim function rendering the contract unable to claim rewards

`Flashlender.sol#flashLoan()` should use `mintProfit()` to mint fees. The current implemetation may lead to locked up WETH in PoolV3.

Discrepency b/w the `lastRewadTime` and the `lastAllPoolUpdate` can allow for incorrect reward distribution to pools if `registerRewardDeposit` deposits less assets

The debt in EligibilityDataProvider::requiredUsdValue() needs to be converted into USD; otherwise, it is not a correct value comparison.

In `PositionActionPendle::_onDecreaseLever`, `tokenOut` is implemented incorrectly.

Because of the Asset:Share 1:1 Conversion, if Vault Incur a Loss, the Last User to Withdraw Will Take The Entire Loss

In CDPVault::liquidatePositionBadDebt(), the calculation of `loss` is incorrect.

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

Malicious actor can abuse the minimum shares check in `StakingLPEth` and cause DoS or locked funds for the last user that withdraws

`PositionAction.sol#onCreditFlashLoan` may have leftover tokens after conducting `leverParams.auxSwap`.

AuraVault inherits AccessControl BUT does not call the _setupRole() function in it's constructor to set the initial roles, this leads to a complete DOS of the important claim function rendering the contract unable to claim rewards

Malicious actor can abuse the minimum shares check in `StakingLPEth` and cause DoS or locked funds for the last user that withdraws

Malicious Reputer cause emissions/msgserver/InsertBulkReputerPayload to fail

RemoveDelegateStake/RemoveStake can write negative value

InsertBulkReputerPayload can be DoS

emissions/keeper/GetIdsOfActiveTopics may always return empty array []

When a single node(blockless server) is attacked, the entire chain is attacked.

The malicious node may not execute the http request

The issue of SLOW ABCI METHODS has not been resolved.

The SelectTopNWorkerNonces function lacks a sorting algorithm internally.

topic_rewards/SafeApplyFuncOnAllActiveEpochEndingTopics used the wrong parameters

In the _splitWithdrawRequest() function, there exists an issue that causes both the from and to requestId to be 0

`EtherFiLib::_initiateWithdrawImpl` will revert because rebase tokens transfer 1-2 less wei

The lack of slippage protection in `EthenaLib::_sellStakedUSDe()` could lead to sandwich attacks.

The _redeemPT function lacks slippage protection.

The withdrawValue calculation in _calculateValueOfWithdrawRequest is incorrect.

After a liquidator liquidates someone else’s position, it could cause a Denial of Service (DoS) when their own position also needs to be liquidated.

The _getValueOfWithdrawRequest function uses different methods for selecting assets in various vaults.

A failed rewardToken transfer results in a loss for the user

Incorrect Comparison Logic in Post-Operation Checks

An attacker can DoS a coinswap pool

Calculating reward in `exitLateById` is not right

Logical error in the _executeRedeemStakeToken function in RedeemProcess.sol

Logical error in the getPoolIntValue function in LpPoolQueryProcess.sol

The `executeUpdateLeverageRequest` function is missing the operation to update the borrowing fee

When a user opens a short position, there is a lack of checks on the liquidity pool, which can result in the user being unable to realize their profits if they succeed.

In Cross Margin mode, the user’s profit calculation is incorrect.

Logical error in the processExecutionFee function GasProcess.sol

Using the .call() method to refund the refundFee In processExecutionFee may result in excessive gas consumption and potential reentrancy attacks.

Missing executionFee in the function `createWithdrawRequest`

The check for the user’s collateralUserCap is missing params.amount in AssetsProcess::deposit()

The balance.unsettledAmount is missing in the calculations for `getMaxWithdraw` and `isSubAmountAllowed` in UsdPool.sol

Using deprecated interfaces `PUFFER_DEPOSITOR.depositStETH()` causes DOS

Invalid check for repayAmount in `MetapoolRouter::receiveFlashLoan` cause DOS

Checking `RSETH_DEPOSIT_POOL.minAmountToDeposit()` in `RsETHAdapter::_stake()` causes Dos

Checking return share in `_stake()` causes Dos

Burning shares token before calculating in `burnSharesToWithdrawEarnings()` causing error result

Use safeTransferFrom() instead of transferFrom()

Checking for Collateral required in LenderCommitmentGroup_Smart::acceptFundsForAcceptBid is incorrect

`TellerV2::repayLoan()` can be frontrun to profit from an increase in share price

Missing interest when calculating Amount owed for a bid in `LenderCommitmentGroup_Smart::liquidateDefaultedLoanWithIncentive()`

The collateral Token is mistakenly given to the lender when the liquidator call liquidateDefaultedLoanWithIncentive()

`sharesExchangeRate()` may be zero causing Users mint zero shares token in `lenderCommitmentGroupSmart.addPrincipalToCommitmentGroup()`

Calling the wrong function name in `FlashRolloverLoan_G5::_acceptCommitment()` resulted in a Denial of Service (DOS)

Kerosene collateral is not being moved on liquidation, exposing liquidators to loss

Users can get their Kerosene stuck until TVL becomes greater than Dyad's supply

Flash loan protection mechanism can be bypassed via self-liquidations

Incorrect deployment / missing contract will break functionality

Early user can break pool via inflation attack due to no minimum liquidity check in the incentive contract

Incentive accumulation can be sandwiched with additional shares to gain advantage over long-term depositors

Missing `configureClaimableGas()` in the constructor function of `BlastGas`

Reentrancy in `Vesting::claim()` allows draining Vesting pool

In `VaultZapper::_transferTokenInAndApprove`, check the wrong `owner` for the allowance of `spender` over the tokenIn.

Any fee claim lesser than the total `yieldFeeBalance` as unit of shares is lost and locked in the `PrizeVault` contract

An attacker can crash the cluster system by sending an HTTP request with a huge timeout

A cache that times out can be recovered.

[M09] No slippage check in `remove_liquidity` function in omnipool can lead to slippage losses during liquidity withdrawal.

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

First depositor can break staking-rewards accounting

First Liquidity provider can claim all initial pool rewards

DOS of proposals by abusing ballot names without important parameters

SALT staker can get extra voting power by simply unstaking their xSALT

Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

Creation of token whitelisting proposals can be DOS'd

Attack to make ````CurveSubject```` to be a ````HoneyPot````

Unrestricted claiming of fees due to missing balance updates in `FeeSplitter`

Unauthorized Access to setCurves Function

A subject creator within a single block can claim holder fees without holding due to unprotected reentrancy path

onBalanceChange causes previously unclaimed rewards to be cleared

Theft of holder fees when `holderFeePercent` was positive and is set to zero

ERC20TokenEmitter will not work after a certain period of time

Since buyToken function has no slippage checking, users can get less tokens than expected when they buy tokens directly

The quorumVotes can be bypassed

Malicious borrower can decrease Guild holders reward

Broken `NonceVoter` Allows Observer to Halt the Chain

Possible index out of range in GetVoterIndex could cause ballot to never finalize due to panic

An already executed InTxTracker can still be added

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

Funds from reverted transaction may be lost/locked

User not refunded for failed Zeta gas payment in cross chain transaction

Limited Voting Options Allow Ballot Creation Spam

No slippage protection for Market functions

The price of rsEHT could be manipulated by the first staker

Protocol mints less rsETH on deposit than intended

Update in strategy will cause wrong issuance of shares

Attacker can drain all ETH from AuctionDemo when block.timestamp == auctionEndTime

On a Linear or Exponential Descending Sale Model, a user that mint on the last `block.timestamp` mint at an unexpected price.

Delegated votes are locked when owner lock is expired

The sending failure of _lzSend is not considered