The EXPIRED judgment does not include the current block

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

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 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

Incorrect Comparison Logic in Post-Operation Checks

An attacker can DoS a coinswap pool

Calculating reward in `exitLateById` is not right

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