Users are unable to withdraw their funds due to the incorrect handling of treasury shares

The liquidation process is not functioning correctly

The protocol fee is not being deducted from the liquidatee's balance during liquidation

The interest rate for debt assets is being incorrectly updated during the liquidation process

The interest rate is incorrectly updated when debt is repaid

The balance calculation is incorrect

Users can receive additional shares in the curated vault

The interest rate for the collateral asset is incorrectly calculated during liquidation

The rewards distribution in the NFTPositionManager is unfair

The repayment process in the NFTPositionManager can sometimes be reverted

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

The traceEnd in BackingManager isn't updating correctly

An attacker can bypass the challenge period during LPP finalization

In some cases, proper CLOCK_EXTENTSION time cannot be ensured to generate the initial instruciton trace

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

When `sellCreditMarket()` is called to sell credit for a specific cash amount, the protocol might receive a lower swapping fee than expected.

The collateral remainder cap is incorrectly calculated during liquidation

Borrower is not able to compensate his lenders if he is underwater

`executeBuyCreditMarket` returns the wrong amount of cash and overestimates the amount that needs to be checked in the variable pool

Users can not to buy/sell minimum credit allowed due to exactAmountIn condition

Multicall does not work as intended

LiquidateWithReplacement does not charge swap fees on the borrower

withdraw() users may can't withdraw underlyingBorrowToken properly

The overflow in the `_calculateStreamedAmount` function can lead to unexpected results.

When the borrower is liquidated, there will be some funds untracked in the market.

Borrowers can profit by borrowing and repaying before the maturity date.

When bad debts are cleared, there will be some untracked funds

The rewards are being distributed incorrectly because the lastConfig is updated inaccurately.

Rewards can disappear when new rewards are distributed in the RewardsController.

The claimable rewards amount for borrowers decreases over time

Checkpoints for total supply and balance are incorrectly updated when revoking the vesting schedule.

Initial depositors are unable to airdrop ZVE tokens correctly in the Initial Tranche Offering

There is an error in the claimRewards function within the OCY_Convex_A and OCY_Convex_C contracts

The addition of liquidity to the Uniswap V2 pool can be reverted because the Uniswap V2 router doesn't use all allowed tokens.

The information of lots with an id greater than 0 will be lost, potentially resulting in a loss of funds for the users.

We are unable to claim gas fees for BlastEMPAM and BlastLinearVesting on Blast

Auction creators have the ability to lock bidders' funds.

Bidders can not claim their bids if the auction creator claims the proceeds.

Auction creators may lose their funds if the quote token behaves like LEND token, reverting on transfer of 0 tokens.

Bidders' funds may become locked due to inconsistent price order checks in MaxPriorityQueue and the _claimBid function.

The auction creator can not claim the Proceeds if some bidders have already claimed their bids.

An auction creator can lose funds in FPAM.

If bidders purchase derivatives in an auction and the expiration date of derivatives has passed, they can not claim base tokens from those derivatives.

Anyone making use of the MagicLP's TWAP to determine token prices will be exploitable.

Users who deposited MIM and USDB tokens into BlastOnboarding may incur losses when the pool is created via bootstrap

Miscalculation in addLiquidity of Router results in unauthorized spending of tokens

User can grief bootstrap process by sending the cap amount of unlocked tokens to it.

MagicLpAggregator doesn't consider the dcimal of MagicLP

There may be excess funds in the PnL pool or bad debt due to the funding fee.

In certain cases, users are unable to settle their orders with the PartialFill trade type.

When `DecentBridgeExecutor.execute` fails, funds will be sent to a random address

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.

When borrowers repay USDS, it is sent to the wrong address, allowing anyone to burn Protocol Owned Liquidity and build bad debt for USDS

First depositor can break staking-rewards accounting

First Liquidity provider can claim all initial pool rewards

Persistent Contract Call revert prevents finalizing a ballot

THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A `decreaseShareAmount` VALUE SUCH THAT THE `virtualRewardsToRemove` IS ROUNDED DOWN TO ZERO

No proposal time limit traps sponsors of unpopular proposals

changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehand

Unauthorized Access to setCurves Function

Protocol and referral fee would be permanently stuck in the Curves contract when selling a token

Selling will be bricked if all other tokens are withdrawn to ERC20 token

onBalanceChange causes previously unclaimed rewards to be cleared

Stuck rewards in `FeeSplitter` contract

Curves::_buyCurvesToken(), Excess of Eth received is not refunded back to the user.

Withdrawing with amount = 0 will forcefully set name and symbol to default and disable some functions for token subject

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete

The userGaugeProfitIndex is not set correctly, allowing an attacker to receive rewards without waiting

Users staking via the `SurplusGuildMinter` can be immediately slashed when staking into a gauge that had previously incurred a loss

Wrong ProfitManager in GuildToken, will always revert for other types of gauges leading to bad debt

Users can deflate other markets Guild holders rewards by staking less priced token

Replay attack to suddenly offboard the re-onboarded lending term

`totalBorrowedCredit` can revert, breaking gauges.

ProfitManager's "creditMultiplier" calculation does not count undistributed rewards; this can cause value losses to users

Rounding errors can cause ERC20RebaseDistributor transfers and mints to fail for underflow

Incorrect calculations in debtCeiling

LendingTerm::debtCeiling() can return wrong debt as the min() is evaluated incorrectly

Anyone can prolong the time for the rewards to get distributed

Malicious borrower can decrease Guild holders reward

Partial transfers are still possible, leading to incorrect storage updates, and the calculated account premiums will be significantly different from what they should be

Owner cannot withdraw all interest due to wrong calculation of accrued interest in WithdrwaCarry

Users will lose rewards when buying new tokens if they already own some tokens

Redemptions are inconsistent with other cdp's operations

`fetchPrice` can return different prices in the same transaction

Incorrect decimal usage in score calculation leads to reduced user reward earnings

A malicious user can avoid unfavorable score updates after alpha/multiplier changes, resulting in accrual of outsized rewards for the attacker at the expense of other users

All tokens can be stolen from `VirtualAccount` due to missing access modifier

When using BaseBranchRouter as a router on the 'Arbitrum' branch, we are unable to invoke the 'callOutAndBridge' function.

```trancheTokenAmount``` should be rounded UP when proceeding to a withdrawal or previewing a withdrawal.

Underflow in updateTranscoderWithFees can cause corrupted data and loss of winning tickets.

The peg stability module can be compromised by forcing lowerDepeg to revert.

reLP() mintokenAAmount the calculations are wrong.