Users Who Queue Withdrawal Before A Slashing Event Disadvantage Users Who Queue After And Eventually Leads To Loss Of Funds For Them

Incorrect Balance Check in Validator Redelegation Process May Block Legitimate Rebalancing Operations

Unauthorized Reallocation in `NudgeCampaign::handleReallocation` and Reward Disruption Vulnerability in `NudgeCampaign::invalidateParticipations`

The user can send tokens to any address by using two bridge transfers, even when transfers are restricted.

Improper Transfer Restrictions on Non-Bridged Tokens Due to Boolean Bridged Token Tracking, Allowing a DoS Attack Vector

Users can prevent being reallocated by listing to marketplace

AccessControlHooks onQueueWithdrawal() does not check if market is hooked which could lead to unexpected errors such as temporary DoS

`FixedTermLoanHooks` allow Borrower to update Annual Interest before end of the "Fixed Term Period"

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

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

Attacker can increase the length of `withdrawQueue` by withdrawing 0 amount of tokens frequently

AccountingManager has no correct implementations of the core ERC-4626 functions `deposit`, `mint`, `withdraw` and `redeem`

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

First depositor can make subsequent depositor lose all of her or his deposit

Lack of Slippage Controls in retrieveTokensForWithdraw Function

`maxDeposit`, `maxMint`, `maxWithdraw`, and `maxRedeem` functions do not return 0 when they should

`depositQueue.queue` in `AccountingManager` can be flooded causing a DoS

Using the same heartbeat for multiple price feeds

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

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

Kerosene collateral is not being moved on liquidation, exposing liquidators to loss

Incorrect deployment / missing contract will break functionality

Using cached price to create a proposal reduce the efficacity of redemptions for asset peg

oracleCircuitBreaker: Not checking if price information of asset is stale

Owner of a position can prevent liquidation due to the 'onERC721Received' callback

Dangerous use of deadline parameter

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

V3Vault is not ERC-4626 compliant

No `minLoanSize` means liquidators will have no incentive to liquidate small positions

Protocol can be repeatedly gas griefed in `AutoRange` external call

SFrxETHAdapter redemptionQueue waiting period can DOS adapter functions

Adversary can prevent updating price feed addresses by creating poisonous proposals ending in `_confirm`

Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards.

Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

Creation of token whitelisting proposals can be DOS'd

`totalBorrowedCredit` can revert, breaking gauges.

First founder receives less token allocation than expected

Missing debt check lets users start a debt auction of non-existent debt

Incorrect calculations for Surplus Auction creation cause massive surplus imbalances