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

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

Rebalance will be completely dossed if OKX commision rate goes beyond the fee limits

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

`withdraw_liquidity` lacks slippage protection

Amplifiers can't be ramped allowing loss of funds from the pool

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

Unspent gas fees are always refunded to the `FeePayer()` which leads to incorrect refunds if the `FeeGranter()` paid for the fees

Nibiru's bank coin to EVM balance tracking logic is completely broken for rebasing tokens and would lead to leakage/loss of funds when converting

ERC20 Transfer Fails With Non-Compliant Tokens Missing Return Values

Zero rates on new quoted tokens allow an attacker to take an interest free quota

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

`BalancerOracle::update()` can return stale price

Honest users could be permanently DOS'd from withdrawing their vested tokens/rewards

Lack of Slippage Control in `AuraVault::deposit` and `AuraVault::mint` Functions Can Lead to Unexpected Financial Losses for Users

`PendleLPOracle::_fetchAndValidate` uses Chainlink's deprecated `answeredInRound`

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

`PositionActionPendle.sol#_onWithdraw` does not have slippage parameter minOut set.

No way to cancel l1 -< l2 messages

Address aliasing is wrongfully applied even to EOAs

`ExponentiationImpl::pow()` returns 0 for 0^0

There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` function

SettlementSignatureVerifier is missing check for duplicate validator signatures

_onTransferReceived() does not work as intended

Mitigation for inflation attacks is wrongly placed

Hardcoded stale duration for all assets breaks pricing logic making core functionalities un-processable

Axelar cross chain token transfers balance tracking logic is completely broken for rebasing tokens and the transfers of these type of tokens can be exploited

Taker of bid offer will loss assets without any benefit if he calls the DeliveryPlace::settleAskMaker() for partial settlement.

`WrappedNativeToken` Can Only Work in `NativeToken` Mode

There is No `msg.value` check in `depositTokens`, causing potential token stuck

Incorrect `isApprovedForAll` check in the `NukeFund.nuke()` function.

Excess ETH from `forgingFee` can get stuck in `EntityForging` under certain situations

The time available for a canceled withdrawal should not impact future unstaking processes

Incorrectly assigned `decimal1` parameter upon decoding

Zero rates on new quoted tokens allow an attacker to take an interest free quota

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

`BalancerOracle::update()` can return stale price

Honest users could be permanently DOS'd from withdrawing their vested tokens/rewards

Lack of Slippage Control in `AuraVault::deposit` and `AuraVault::mint` Functions Can Lead to Unexpected Financial Losses for Users

`PendleLPOracle::_fetchAndValidate` uses Chainlink's deprecated `answeredInRound`

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

`PositionActionPendle.sol#_onWithdraw` does not have slippage parameter minOut set.

`LiquidationBranch::checkLiquidatableAccounts()` executes `for` loop with wrong values, causing array out of bounds to be recovered, the program will not work as expected

`ERC1155Voucher#transferERC20()` & `VouchFaucet#transferERC20()` would never work for USDT

User may lose funds when creating Nexus account or executing user operations

Factory deployments won't work correctly on the ZKsync chain

Incompatibility with Multisig Wallets in `TempleGold::send` Function

Protocol is incompatible with FOT tokens in multiple instances

`OptionTokenV4#_exerciseVe()`& `OptionTokenV4#_exerciseLp()` both lack any slipage protection

A malicious user can steal money out of the vault and other users

`PanopticFactory` uses spot price when deploying new pools, resulting in liquidity manipulation when minting

LibUsdOracle is completely broken for the to-deploy L2 chain

Some users would be stuck on the L1 and not be able to migrate their Beans to the L2

The `LibWeth` hardcodes the `WETH` address which makes it incompatible on the to-deploy L2 chain

`BeanL1RecieverFacet#recieveL1Beans()` would never work

ETH/USD 1 hour period is too large for Optimism/Base L2 Chains and too small for Arbitrum/Avalanche leading to consuming stale price data.

Mismatch in the `BRIDGE` address between the `BeanL1RecieverFacet` and `BeanL2MigrationFacet` contracts prevents the migration of Beans to L2

incorrect price for negative ticks due to lack of rounding down

Liquidity manipulation is possible when trading

Chainlink's `latestRoundData` might return stale or incorrect results

Missing disapproval check in `LockManager.sol::approveUSDPrice` allows simultaneous approval and disapproval of a price proposal

`SophonFarming#depositStEth()`'s implemetation in regards to recevied `stETH` tokens should be similar to `SophonFarming#_ethTOstEth()`

`UniETHAdapter#_stake()` , `RsETHAdapter#_stake()` & `UniETHAdapter#_requestWithdrawal()` all lack any slippage or deadline mechanism whatsoever

Use of CREATE method is suspicious of reorg attack

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

Withdrawals can be locked forever if recipient is a contract

Pending withdrawals prevent safe removal of collateral assets

Incorrect exchange rate provided to Balancer pools

Lack of slippage and deadline during withdraw and deposit

`calculateTVL` may run out of gas for modest number of operators and tokens breaking deposits, withdrawals, and trades

`SNXConnector.sol` TVL calculation is incorrect.

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

PendleConnector.sol::supply doesn't pass a valid slippance protection min

`totalAssets()`, and thus `convertToShares()` and `convertToAssets()`, may revert, in violation of ERC-4626

Chainlink connector doesn’t check for the Min / Max prices returned

`Keepers` does not implement EIP712 correctly on multiple occasions

Lack of Slippage Controls in retrieveTokensForWithdraw Function

Stale price can be used in `getValueFromChainlinkFeed` function

Noya is not compatible with tokens whose balance changes outside of transfers causing funds to get stuck in the contract

`CurveConnector` will be non-functional on Arbitrum & Polygon due to the improper integration with Convex Boosters on these chains

Balancer flashloan contract can be DOSed completely by sending 1 wei to it

Camelot and Aerodrome Connector TVL susceptible to manipulation attack

Using the same heartbeat for multiple price feeds

`PendlingConnector::depositIntoMarket()` `PendlingConnector::burnLP()` and are missing slippage control parameters.

Transfers/Approvals on some tokens that are meant to be integrated would not work in protocol

No incentive to liquidate small positions could result in protocol going underwater

Incorrect deployment / missing contract will break functionality

No incentive to liquidate when CR <= 1 as asset received < dyad burned

Large amounts of points can still be minted virtually without any cost

Protocol's functionality can end up being broken based on the asset being used

`PanopticFactory` uses spot price when deploying new pools, resulting in liquidity manipulation when minting

```LibWstethEthOracle::getWstethEthPrice``` returns wrong ```wstETH/ETH``` price in some conditions impacting system operations

Protocol unintentionally implements an asymmetric method of calculating the price difference

Storage can be bloated with low liquidtiy positions

oracleCircuitBreaker: Not checking if price information of asset is stale

Factory::create() is vulnerable to reorg attacks

`_getReferencePoolPriceX96()` will show incorrect price for negative tick deltas in current implementation cause it doesn't round up for them

Asymmetric calculation of price difference

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

`_getUniswapTwapWei()` will show incorrect price for negative ticks cause it doesn't round up for negative ticks.

Fees are hardcoded to 3000 in ExactInputSingleParams

Removal of approved token from token manager can lead to unintended liquidation of vaults

No slippage protection for Market functions

Possible arbitrage from Chainlink price discrepancy

Update in strategy will cause wrong issuance of shares

ETHCrowdfundBase.sol#processContribution - Impossible to finalize crowdfund because of minContribution check

PartyGovernanceNFT advertises but does not honor the ERC-4906 standard

Auction winner can prevent payments via `safeTransferFrom` callback

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

Message channels can be blocked resulting in DoS

Depositors could lost all their depositted tokens (including the hTokens) if their address is blacklisted in one of all the depositted underlyingTokens

Builtins that access literal lists cannot be compiled

The Restriction Manager does not completely implement ERC1404 which leads to account that are supposed to be restricted actually have access to do with their tokens as they see fit

Missing slippage parameter on Uniswap `addLiquidity()` function

A malicious early depositor can manipulate the `LP-Token` price per share to take an unfair share of future user deposits

If a winner is blacklisted on any of the tokens they can't receive their funds

Signature missing nonce & expiration deadline

Potential DOS due to Gas Exhaustion Due to Large Array Iteration in `_distribute` Function

Sandwich attack to steal all ERC-20 tokens in the Fees contract

Fee on transfer tokens will cause users to lose funds

WETH staking rewards accumulated before the first staker deposits remain unutilized and stuck in the `Staking` contract

No expiration deadline leads to losing a lot of funds

Single-step process for critical ownership transfer is risky

Pragma non-specification can lead to non-functional / corrupted contract when deployed on Arbitrum

Zero address leads to transaction reverts

Lender fails to giveLoan because of inconsistent length between `loadIds` and `poolIds`

Rounding error risk in borrow() function in Lender.sol

Unnecessary If condition in update() of Staking.sol

Lender.sol: The error being `PoolConfig` in most cases is completely a downside of protocol as users can't know the reasons to why their transaction failed

Setter functions not checking if value changed

staleCheckLatestRoundData() does not check the status of the Arbitrum sequencer in Chainlink feeds.

DSC protocol can consume stale price data or cannot operate on some EVM chains

All of the USD pair price feeds doesn't have 8 decimals

Lack of fallbacks for price feed oracle

Too many DSC tokens can get minted for fee-on-transfer tokens.

Pragma isn't specified correctly which can lead to nonfunction/damaged contract when deployed on Arbitrum

Use `==` instead for `<=` for `uints` when comparing for `zero` values

High - Funds can be lost if any participant is blacklisted

Constructor of `Escrow` should make sure that `buyer`, `seller`, `arbiter` are different from each other.

Rounding error in `WUSDA` can result in loss of user funds, especially when manipulated by an attacker

MavEthOracle.sol's current implementation is massively prone to manipulation

Axelar cross chain token transfers balance tracking logic is completely broken for rebasing tokens and the transfers of these type of tokens can be exploited

Hubble assumes stablecoins never depeg

No `minAnswer/maxAnswer` Circuit Breaker Checks while Querying Prices in Oracle.sol

Wagmi assumes only one UniV3 pool exists for a pair of tokens

Chainlink's `latestRoundData` may return stale or incorrect result

Lack of Chainlink's `minAnswer/maxAnswer` Circuit Breaker Checks while Querying Prices in PriceOracle.sol

Possibility of Stale Data Usage in the PriceOracle Contract

Users Funds could get stucked in protocol due to the dependency on epoch settling before Pending Deposit/Redemption are processed

USSD.sol: Missing Access Control in `mintRebalancer` and `burnRebalancer` Functions

Missing Deadline Checks in USSD Contract

USSDRebalancer.sol: Price Manipulation Vulnerability

Inactive ethOracle in StableOracleDAI Contract

Missing Check for Stale Data in StableOracle Contracts

Incorrect Price Calculation in Stable Oracles (WETH, WBTC, DAI) when Aggregator Hits minAnswer

StableOracleWBTC use BTC/USD chainlink oracle to price WBTC which is problematic if WBTC depegs

Invoke Library: Lack of Return Value Checks in ERC20 operations

AaveLeverageStrategyExtension: Usage of Deprecated Chainlink API puts Protocol at Risk

Protocol doesn't completely protect itself from `LTV = 0` tokens

Incorrect `blocksPerYear` constant in `WhitepaperInterestRateModel`

Claiming accumulated rewards while the contract is underfunded can lead to a loss of rewards

Calculating new rewards is susceptible to precision loss due to division before multiplication

FootiumClub and FootiumPlayer do not comply with ERC721, breaking composability

Limited support to a specific subset of ERC20 tokens

Undesired behaviour of chainlink feeds when sequencer is down

The Oracle data feed still lacks sufficient validation.