A reserve's `d_supply` is incorrectly updated and stored after flash loan execution

Potentially sensitive issue - disclosed privately

Removing a pool from the reward zone leads to the loss of ungulped emissions

Potentially sensitive disclosure - 5

Division before multiplications may cause division by zero DOS during low backstop supply

Missing update_rz_emis_data Calls in draw and donate Functions Lead to Incorrect Emissions Distribution

Missing reserve interest accrual prior to backstop take rate update leads to incorrect backstop_credit computation

Flash Loans Allow Borrowing From Frozen Pools, Bypassing Security Controls

Public `ServiceNft::updateImpact` call leads to cascading issue

ValidatorRegistry::validatorScore/getPastValidatorScore allows validator to earn full rewards without actually engaging with the protocol

Launched tokens are vulnerable to flashloan attacks forcing premature graduation, allowing reward manipulation

Attacker can prevent user from executing application registered through `initFromToken()` in `AgentFactoryV4`.

Functions in FERC20 can't be invoked

BondingTax has invalid slippage implementation

`AgentDAO::_castVote` doesn't check the array of votes emitted, which determine the number of battles fought in `EloCalculator.sol`, allowing the user to increase the ELO of a contribution unfairly, inflating the maturity/impact of `ServiceNFTs`

battleElo is at risk of underflow revert, which may DOS voting

Founder has to double-stake during migration with the initial LP locked in the old veToken

MsgCreate2 deviates from EVM spec causing a large range of address not reachable

setBeforeSendHook can never delete an existing store due to vulnerable validate

The calculation of `totalAssets()` could be wrong if `operatorFeeAmount` > 0, this can cause potential loss for the new depositors

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

Stable swap pools don't properly handle assets with different decimals, forcing LPs to receive wrong shares

User cannot claim rewards or close_position, due to vulnerable division by zero handling

Logical error in `validate_fees_are_paid` can cause a DoS or allow users to bypass fees if `denom_creation_fee` includes multiple coins including `pool_creation_fee` and the user attempts to pay all fees using only `pool_creation_fee`

Incorrect `slippage_tolerance` handling in stableswap `provide_liquidty` function

Penalty fees can be shared among future farms or expired farms, risks of exploits

In edge cases, create_pool can either be reverted or allow user underpay fees.

When a user single-side deposit into a pool, slippage protection is invalid

Vulnerable liquidity slippage calculation doesn't ensure slippage protection due to unscaled assets sum

Liquidity providers can lose tokens due to disproportionate deposits not being properly handled

Insufficient check on asset decimals input in create_pool allows malicious pool to be created with invalid swap results

No way to cancel l1 -< l2 messages

handle_l1_message may unfairly revert l2 tx with sufficient l1 sender balance, due to vulnerable fee charge implementation

Incorrect totalsupply value will be returned due to erroneous return data decode implementation

Account contract does not gracefully handle panics in called contracts

Missing `lower<upper` check in `mint_position`

Unrevoked approvals allow NFT recovery by previous owner

update_emergency_council_7_D_0_C_1_C_58() updates nft manager instead of emergency council

swapOut functions have invalid slippage check, causing user loss of funds

If liquidity is insufficient, users may need to pay more tokens in swap2

_onTransferReceived() does not work as intended

swap_2 implementation will randomly revert due to improper check, root cause for failed test ethers_suite_uniswap_orchestrated_uniswap_two

`decrPosition09293696` will not work due to incorrect function signature

No related function to set fee_protocol

In some cases, proper CLOCK_EXTENTSION time cannot be ensured to generate the initial instruciton trace

Incorrect withdraw queue balance in TVL calculation

L1::xRenzoBridge and L2::xRenzoBridge uses the block.timestamp as dependency, which can cause issue.

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

BalancerConnector has incorrect implementation of totalSupply, positionTVL and total TVL will be invalid

`NoyaValueOracle.getValue` returns an incorrect price when a multi-token route is used

Numerous errors when calculating the TVL for the MorphoBlue connector

CompoundConnector.sol misses unclaimed rewards in getPositionTVL, resulting in undervalued positionTVL/TVL

Withdrawals in AccountManager are prone to DOS attacks.

The `TVLHelper.sol#getTVL` function is DOSed by the `under collateralized connector`, and as a result, many parts of the protocol may be DOS.

The modifier `onlyExistingRoute` works incorrectly

Incorrect Return Value in `CompoundConnector.getBorrowBalanceInBase()` Affecting TVL Calculation

Missing calls to `_updateTokenInRegistry` leads to incorrect state of tokens in registry

Incorrect modifier condition

In the AerodromeConnector, unclaimed rewards are not included in the calculation of the connectors TVL

Dust donation might DOS all connectors to create new holding positions, by preventing removing existing holding positions

Design flaw and mismanagement in vault licensing leads to double counting in collateral ratios and positions collateralized entirely with kerosine

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

User can get their Kerosene stuck because of an invalid check on withdraw

Incorrect deployment / missing contract will break functionality

User might be able to double withdraw during migration

State transition manager is unable to force upgrade a deployed ST, which invalidates the designed safeguard for 'urgent high risk situation'

Freezed Chain will never be unfreeze since `StateTransitionManager::unfreezeChain` is calling `freezeDiamond` instead of `unfreezeDiamond`.

a huge loss of funds for all the users who try to remove liquidity after swapping got disabled at manipulated price .

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

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

formPOL lacks slippage and deadline protection

When forming POL the DAO will end up stucked with DAI and USDS tokens that cannot handle.

changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehand

PriceFeed is likely to be disabled in times of volatility, causing liquidations and borrows to freeze

Impossible to change managed wallets with `proposeWallets` after first rejection

Missing slippage protection in `liquidity_lockbox::withdraw`

Lack of Balance Validation

In ZetaTokenConsumerTrident. strategy.sol, swapping zeta for other tokens will always revert due to incorrect exactInputSingle router method being used

When updating gas, if one chain fails, the others should continue to be updated instead of being skipped.

The outbound transaction tracker only keeps track of a maximum of two different transaction hashes, preventing cctxs from being efficiently confirmed and blocking the outbound transaction queue

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

PayGasFeeInZetaAndUpdateCctx() is prone to slippage, causing sender overpays the revert gas and lose returned funds

AddToInTxTracker doens't allow permissionless tx validation for Bitcoin chain, InTxTracker permissionless tx validation for Bitcoin chain will always fail

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

Multiple mints can brick any form of `salesOption` 3 mintings

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

Bidder Funds Can Become Unrecoverable Due to 1 second Overlap in `participateToAuction()` and `claimAuction()`

User might be able to double withdraw during migration

State transition manager is unable to force upgrade a deployed ST, which invalidates the designed safeguard for 'urgent high risk situation'

Freezed Chain will never be unfreeze since `StateTransitionManager::unfreezeChain` is calling `freezeDiamond` instead of `unfreezeDiamond`.

DoS and gas griefing of calls to Prime.updateScores()

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

`sync` function in `RdpxV2Core.sol` should be called in multiple scenarios to account for the balance changes that occurs

Lack of Balance Validation

When adding a gauge, its initial value has to be set by an admin or all voting power towards it will be lost

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

User can steal refunded underlying tokens from `initRange` operation inside `RangeManager`

Pumps are not updated in the shift() and sync() functions, allowing oracle manipulation

Single hardcoded cap used for multiple tokens in a pump causing some assets to be more stale, while having no effects on other stable assets

Preset stable prices directly passes to protocol without checking with oracle price