Anyone can steal all funds from the `market` due to incorrect health accounting for pending pnl from difference of intent price and market price when multiple intents are used.

`InvariantLib` uses current position for margin check allowing to withdraw collateral while the position decrease is only pending and can cause unexpected immediate user liquidation.

Intent orders are guaranteed to execute, but fees from these orders are not accounted in collateral, allowing user to withdraw all collateral ignoring these pending fees.

When account is liquidated (protected), liquidator can increase account's position to any value up to `2**62 - 1` breaking all market accounting and stealing all market funds.

Some accounts using Intents to trade might be liquidated while healthy or be unliquidatable while being unhealthy.

Liquidations are temporarily blocked if user's pending position close amount is greater than the latest position size.

Anyone can steal all funds from the `market` due to lack of account health accounting for pending pnl from difference of intent price and market price.

Anyone can be operator of any account due to lack of access control in `MarketFactory.updateExtension`

Market coordinator can steal all market collateral by changing adiabatic fees

Market coordinator can liquidate all users in the market

Market coordinator can steal all market collateral by abusing very low value of `scale`

Market coordinator can set `staleAfter` to a huge value allowing anyone to steal all market collateral when there are no transactions for some time

`MultiInvoker` and `Manager` orders execution can be DOS in key moments if AAVE/Compound utilization is at 100%

`MultiInvoker` and `Manager` operations might revert due to assumption of 1 `DSU` = 1 `USDC`

`MultiInvoker`, `Manager` and `Account` unexpected reverts in certain conditions due to AAVE reverting on deposits and withdrawals with 0 amount

`Controller`'s core function of Rebalance will not rebalance when rebalance is needed in some cases, breaking core functionality

Market coordinator can set proportional and adiabatic fees much higher than limited by protocol due to fixed point truncation

Vault global shares and assets change will mismatch local shares and assets change during settlement due to incorrect `_withoutSettlementFeeGlobal` formula

Empty orders do not request from oracle and during settlement they use an invalid oracle version with `price=0` which messes up a lot of fees and funding accounting leading to loss of funds for the makers

Requested oracle versions, which have expired, must return this oracle version as invalid, but they return it as a normal version with previous version's price instead

All transactions to claim assets from the vault will revert in some situations due to double subtraction of the claimed assets in market position allocations calculation.

If referral or liquidator is the same address as the account, then liquidation/referral fees will be lost due to local storage being overwritten after the `claimable` amount is credited to liquidator or referral

Vault and oracle keepers DoS in some situations due to `market.update(account,max,max,max,0,false)`

Vault checkpoints slightly incorrect conversion from assets to shares leads to slow loss of funds for long-time vault depositors

When vault's market weight is set to 0 to remove the market from the vault, vault's leverage in this market is immediately set to max leverage risking position liquidation

Makers can lose funds from price movement even when no long and short positions are opened, due to incorrect distribution of adiabatic fees exposure between makers

The sign of delta hedge amount can be reversed by malicious user due to incorrect condition in `FinanceIGDelta.deltaHedgeAmount`

Utilization rate for bonding curve purposes is calculated for a total of bull and bear usage, which can be abused to steal all vault funds

If the vault's side token balance is 0 or a tiny amount, then most if not all IG Bear trades will revert due to incorrect check of computation error during delta hedge amount calculation

Transferring ERC20 Vault tokens to another address and then withdrawing from the vault breaks `totalDeposit` accounting which is tied to deposit addresses

PositionManager will revert when trying to return back to user excess of the premium transferred from the user when minting position

PositionManager will revert all `mint` attempts when trying to `safeApprove` `dvp` address to spend tokens if it hasn't spent all tokens approved previously

PositionManager will revert all `mint` attempts if actual premium charged is greater than premium calculated from oracle price.

FeeManager `receiveFee` and `trackVaultFee` functions allow anyone to call it with user-provided dvp/vault address and add any arbitrary feeAmount to any address, breaking fees accounting and temporarily bricking DVP smart contract

Trading out of the money options has delta = 0 which breaks protocol assumptions of traders profit being fully hedged and can result in a loss of funds to LPs

Vault max redeem calculations limit redeem amount to the smallest position size in underlying markets which can lead to very small max redeem amount even with huge TVL vault

Liquidator can liquidate user while increasing user position to any value, stealing all Market funds or bricking the contract

Vault leverage can be increased to any value up to min margin requirement due to incorrect `maxRedeem` calculations with closable and `LEVERAGE_BUFFER`

It is possible to open and liquidate your own position in 1 transaction to overcome efficiency and liquidity removal limits at almost no cost

Invalid oracle version can cause the `maker` position to exceed `makerLimit`, temporarily or permanently bricking the Market contract

`KeeperOracle.request` adds only the first pair of market+account addresses per oracle version to callback list, ignoring all the subsequent ones

`KeeperOracle.commit` will revert and won't work for all markets if any single `Market` is paused.

Vault `_maxDeposit` incorrect calculation allows to bypass vault deposit cap

Pending keeper and position fees are not accounted for in vault collateral calculation which can be abused to liquidate vault when it's small

`MultiInvoker._latest` will return `latestPrice = 0` when latest oracle version is invalid causing liquidation to send 0 fee to liquidator or incorrect order execution

`MultiInvoker._latest` calculates incorrect closable for the current oracle version causing some liquidations to revert

It is possible to frontrun liquidations with self liquidation with high strain value to clear warning and keep unhealthy positions from liquidation

`Borrower`'s `modify`, `liquidate` and `warn` functions use stored (outdated) account liabilities which makes it possible for the user to intentionally put him into bad debt in 1 transaction

Bad debt liquidation doesn't allow liquidator to receive its ETH bonus (ante)

In some situations the liquidation can become unprofitable for liquidators, keeping unhealthy positions

During oracle provider switch, if previous provider feed stops working completely, oracle and market will be stuck with user funds locked in the contract

`Vault.update(anyUser,0,0,0)` can be called for free to increase `checkpoint.count` and pay smaller keeper fee than necessary

MultiInvoker liquidation action will revert most of the time due to incorrect closable amount initialization

MultiInvoker liquidation action will revert due to incorrect closable amount calculation for invalid oracle versions

Invalid oracle version can cause the vault to open too large and risky position and get liquidated due to using unadjusted global current position

`liquidatePartyA` requires signature which doesn't have nonce, making possible unfair liquidation and loss of funds for all parties

`liquidatePositionsPartyA` limits partyB loss to partyB allocated balance, which can lead to inflated partyB balance and loss of funds for protocol users

Position closure might always revert in some cases due to allocatedBalances being unsigned, preventing the user from closing its positions

Position value can fall below minimum acceptable quote value when partially closing positions requested to be closed in full

MultiAccount `depositAndAllocateForAccount` function doesn't scale the allocated amount correctly, failing to allocate enough funds

Wrong calculation of solvency in `fillCloseRequest` prevents the position from being closed even if the user is solvent after position closure

Oracle request timestamp and pending position timestamp mismatch can make most position updates invalid

PythOracle `_recordPrice()` function incorrectly treats `expo` (exponent) from `PythStructs.Price` which can lead to protocol malfunction and loss of funds after oracle switch

Invalid oracle versions can cause desync of global and local positions making protocol lose funds and being unable to pay back all users

It is possible to open and liquidate your own position in 1 transaction to overcome efficiency and liquidity removal limits at almost no cost

PythOracle `commit()` function doesn't require (nor stores) pyth price publish timestamp to be after the previous commit's publish timestamp, which makes it possible to manipulate price to unfairly liquidate users and possible stealing protocol funds

During oracle provider switch, if it is impossible to commit the last request of previous provider, then the oracle will get stuck (no price updates) without any possibility to fix it

Bad debt (shortfall) liquidation leaves liquidated user in a negative collateral balance which can cause bank run and loss of funds for the last users to withdraw

liquidatePositionsPartyB can be used by malicious liquidator to liquidate only select positions which artificially inflates partyA upnl and allows to steal funds

PartyA and PartyB nonce is not incremented in any of the liquidation functions which can lead to all protocol funds being stolen in some cases

Position closure and position liquidations might always revert in some cases due to allocatedBalances being unsigned, preventing the user from closing its positions or finishing liquidation

Any user can avoid paying most of the protocol fees on short positions, and can unknowingly pay very high fee on long positions

partyA or partyB can be unexpectedly liquidated immediately after opening position if low LIMIT price is provided in the quote

Fees are not returned to partyA from locked quotes if partyB is liquidated

partyA is forever stuck with open positions and partyB is stuck forever in liquidation status if liquidatePositionsPartyB is not called within 2 * liquidationTimeout seconds window

Some actions are allowed on partyB when corresponding partyA is liquidated allowing to steal all protocol funds

Suspended partyB can use another partyA to transfer fraudlent funds via artificial profit/loss

Re-entrancy with multiple smaller bugs can be used to borrow large amount and lock it in the account

If oracle is set for ERC777 token, re-entrancy is possible to steal all LToken funds

Any borrower with bad debt can be liquidated multiple times to lock funds in the lending pair

Project funds can be drained by reusing signatures, in some cases

With most functions in VaultTracker.sol, users can call them only once after maturity has been reached.

ZcToken.withdraw will send user 0 tokens if called after maturity deadline but before market is set mature

[PNM-001] `PARENT_CANNOT_CONTROL` can be bypassed by maliciously unwrapping parent node

It is possible to create fake ERC1155 NameWrapper token for subdomain, which is not owned by NameWrapper

If PARENT_CANNOT_CONTROL is set on subdomain, it can be unwrapped then wrapped by its owner and then parent can control it again before the expiry

BytesUtil.compare returns wrong result on some strings longer than 32 characters

Proposal which started buyout which fails is able to settle migration as if its buyout succeeded.

Any fractions deposited into any proposal can be stolen at any time until it is commited

Fund will be stuck if a buyout is started while there are pending migration proposals

Steal NFTs from a Vault, and ETH + Fractional tokens from users.

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

Migration::withdrawContribution falsely assumes that user should get exactly his original contribution back

```migrateFractions``` may be called more than once by the same user which may lead to loss of tokens for other users