`pump` functionality and purpose can be completely bypassed by lockers, completely avoiding the intention of the protocol to add buy pressure

Deposits on long one leverage vault don't actually finalize the flow, leading to a Denial of Service (DoS)

Users can borrow more assets than they have deposited as collateral

NFTs Get Permanently Locked in Stability Pool After Liquidation

RToken is Not Interest Bearing Due to Broken Liquidity Index Calculation

Interest Accrual Failure Due to Incorrect Scaling in RToken Implementation

RToken.transferFrom() Does Not Scale User Balances Due to Stale Liquidity Index

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

Inconsistent Scaling in RToken Transfer Functions

Lack of incentives for users to call LendingPool::initiateLiquidation allows extensive delay between when health factor dropped below threshold and when grace period starts

Dynamic emissions schedule based on system utilization doesn’t work

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

Adversary can win proposals with voting power as low as 4%

Incorrect Credit Capacity Validation in `VaultRouterBranch.redeem` Enables Locked Collateral Drainage

Unclaimed Rewards Loss Due to Missing Validation in `VaultRouterBranch.stake()`

If Auction Fails, Some Bond Holders Each Period Will Never Be Able To Receive Coupon Payments Owed To Them

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

Old router retains token allowance after update

Users can claim more that their actual allotment

maxSellPercent can be buypassed by selling previously bought vestings at a later time