`setPool` can be called by anyone

`allocator.voiceCerdits` is not used in `QVSimpleStrategy` which the alloactor can vote unlimited times

since `_allocator.voiceCreidtsCastToReceipeints+=totalCredits` is wrong and will be infliated not like the spec

Both Partys can make `CloseQuote` revert by deallocate their funds and allowing the closing/liquidations to go threw

no check for exipred Price Timestamp like in PartyB which can cause price staleness

PartyA can control liquidations in `liquidatePartyA`

FeeCollector can get ouf WithdrawCooldown in `receiveTradingFees`

`liquidatePendingPositionsPartyA` dosnt give fee back when PartyA has positions in pending and instead liquidates them which should'nt happen

If liquiation is not called in few blocks/timestmaps PartyB other positions can't be liquidated and funds will stuck in ` liquidatePositionsPartyB`

no check on timestamp for latestRoundData

oracle has no check if the sequencer is alive

Some positions wont be able to be liquidated becuase of mistake in the code

2 oralces (wbgl,dai) oracle dont work and revert

Sandwitch attack will happen because no check on slippage

in `getOwnValution` we dont use a twap variable but instead use a not protected manipulates price

If `token1=Dai` the rebalance mostly wont work with high USSD value

Attackers can control how rebalance happens by changing balances

We can profit from public and burn mint function

DAI can be overshoot causing a USSD depegg

`LatestRoundata` timestamp is not valiated

slippage set to 0 it can cause users to get sandwiched

keepers might have to pay more fees and not get reimbursed

If block range it big and adl dosnt use currentblock in the order it will cause issues

When `rewardToken` is erc1155/erc777,an attacker can reenter and cause funds to be stuck in the contract forever

DOS risk if enough tokens are minted in Quest.claim can lead, at least, to transaction fee lost

An attacker can block the contract and cause a dos to users with usdc

Since when a loan is cleared rollable=true an attacker can do many diffrent thinks with that like rolling over loan with frontrunning and getting more debt with out paying collateral

Since when a loan is cleared `rollable=true` an attacker can do many diffrent thinks with that like rolling over loan with frontrunning and getting more debt with out paying collateral

`requireNextActiveMultisig` will always return the first enabled multisig which increases the probability of stuck minipools

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

Assets may be lost when calling unprotected `AutoPxGlp::compound` function

Attacker may DOS auctions using invalid bid parameters

There is no input validation on `withdrawToken()` so an attacker can input any address as `from` and cause loss of funds

Protocol withdrawals of collateral can be unexpectedly locked if governance sets the `collateralFactorBps` to 0.

Proposals can be bricked and Auctions stalled by bad settings

Builder can halve the interest paid to a community owner due to arithmetic rounding

Division rounding can make fraction-price lower than intended (down to zero)

Use of `payable.transfer()` may lock user funds

ORACLE DATA FEED CAN BE OUTDATED YET USED ANYWAYS WHICH WILL IMPACT ON PAYMENT LOGIC

`fillOrder()` and `exercise()` may lock Ether sent to the contract, forever

Able to mint any amount of PT

Use `safeTransfer()`/`safeTransferFrom()` instead of `transfer()`/`transferFrom()`

The check for value transfer success is made after the return statement in _withdrawFromYieldPool of LidoVault