Reward manipulation vulnerability in StabilityPool

NFTs Get Permanently Locked in Stability Pool After Liquidation

LendingPool deposits do not work with CurveVault due to lack of funds

Liquidation Cannot Be Closed Even With Healthy Position Due To Strict Debt Check

There is no logic checking for RAACNFT price staleness before minting it

LendingPool.getUserDebt returns outdated value and can lead to liquidation failure

Missing Liquidity Rebalancing in Repayments and Liquidations Leading to Inefficient Liquidity Management

The endAuction function attempts to send native tokens to the StabilityPool, which does not support

`FeeCollector::updateFeeType` wrong fee share validation leads to impossible update for some fee types

Incorrect Timestamp Tracking in RAACHousePrice contract

not adding `claimable` balance to the total assets in `_harvestAndReport` can cause losses.

Inflated `totalAssets` in `StrategyMainnet`, `StrategyArb`, and `StrategyOp` Contracts

Users can list assets with price < 1 ERC20 (ETH, WETH), leading to potential DoS vulnerability.

Lack of output validation in `LLMOracleCoordinator::respond` allows empty responses and potential fee exploitation by oracles.

`LLMOracleCoordinator::request` lacks a check for non-empty `task.input`, making `assertValidNonce` easier to pass due to reduced uniqueness

[H-01] Auction tokens will be lost forever when auction ends without bids

Liquidation doesn't account for penalty when calculating collateral to give, allowing users to profit by borrowing and self-liquidating

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

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Invalid validation allows users to unlock early

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

Players can gain more NFTs benefiting from that past remainder in subsequent locks

Incorrect withdraw queue balance in TVL calculation

Incorrect calculation of queued withdrawals can deflate TVL and increase ezETH mint rate

PrincipalToken is not ERC-5095 compliant

Missing deadline check allow pending transactions to be maliciously executed

Lack of slippage control on LRTDepositPool.depositAsset

Incorrect slippage protection on deposits

Missing minimum token amounts in the emergency contract functions allows MEV bots to take advantage of the protocols emergency situation

Incorrect state transition may cause vault in stuck

`transferSAFEOwnership()` does not fully transfer ownership

Test addresses and incorrect interface in code prevent integration with UniswapV3 and Camelot

[H-01] Lack of emergency withdraw function when no arbiter is set

Check price != 0 before interacting with IERC20

Use assembly to check for `address(0)`

Use nested `if` statements instead of logical AND (`&&`)

Use predefined address instead of `address(this)`

Function `_settleClaim()` Call Will Fail As `connext.xcall` Does Not Include Relayer Fee

Due to inappropriately short `votingPeriod` and `votingDelay`, it is near impossible for the governance to function correctly.

`clubNft` will be lost if caller doesn't implement `ERC721 Receiver`(i.e if caller unable to handle incoming Erc721 Token)

First Depositor/Eairly Depositors can effectively steal funds from later users

```approve()``` Could Be Front-Runned

A Malicious User Can Front-runned And Settels First Auction Even Before Bidding Starts For It.

Fee on transfer tokens will not behave as expected

Use of unsafe ERC20

Incorrect Assumption of Stablecoin Market Stability

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

Hacked owner or malicious owner can immediately steal all assets on the platform