Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

Pause and unpause functions are inaccessible

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

Claimable gauge distributions are locked when `killGaugeTotally` is called

Caching `totalSupply` leading to incorrect reward calculation

DOS attack by delegating tokens at MAX_DELEGATES = 1024

First liquidity provider of a stable pair can DOS the pool

`claim` function lacks slippage controls for `amount0` and `amount1` returned by `pool.burn` function call

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

Lack of slippage and deadline during withdraw and deposit

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

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

Lack of Slippage Controls in retrieveTokensForWithdraw Function

setFees doesn't collect previous fees before changing fee values

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

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

Repayments and liquidations can be forced to revert by an attacker that repays miniscule amount of shares

Lack of safety buffer in `_checkLoanIsHealthy` could subject users who take out the max loan into a forced liquidation

Holders array can be manipulated by transferring or burning with amount 0, stealing rewards or bricking certain functions

`LiquidInfrastructureERC20.sol` disapproved holders keep part of the supply, diluting approved holders revenue.

Distribution can be bricked, and double claims by a few holders are possible when owner calls `LiquidInfrastructureERC20::setDistributableERC20s`