The amount of `xezETH` in circulation will not represent the amount of `ezETH` tokens 1:1

Incorrect withdraw queue balance in TVL calculation

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

DOS of `completeQueuedWithdrawal` when ERC20 buffer is filled

stETH/ETH Feed being used opens up to 2 way deposit<->withdrawal arbitrage

Malicious users can exploit a flaw in `mintBatch()` to mint large amounts of tokens, with very little cost

Roles within any `Edition` contract can never be granted/revoked

Signature malleability- anyone can acknowledge or unacknowledge an edge from someone else's node

A malicious user can DoS the `acknowledgeEdge` and `unacknowledgeEdge` function by front-running

The excess funds sent to Edition will be lost, since `_refundExcess` has a logical flaw

`Edition.mintBatch()` will always revert due to using `msg.value` in a loop

GoatV1Pair does not work when fee-on-transfer tokens are used, leading to DoS of contract

V3Utils.execute() does not have caller validation, leading to stolen NFT positions from users

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

AutoRange execution can be front-ran to avoid protocol fee, causing loss for protocol

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

Incorrect liquidation fee calculation during underwater liquidation, disincentivizing liquidators to participate

Complete DoS of every DVP's minting and burning, due to insufficient access controls within FeeManager::trackVaultFee.

The refunding feature in the PositionManager contract will always revert due to insufficient approval

Whenever swapPrice > oraclePrice, minting via PositionManager will revert, due to not enough funds being obtained from user.

A malicious user can bypass limit order trading fees via cross-function re-entrancy

During liquidation, global position data is updated with the wrong price

A user can bypass the locking of tokens in announced orders, by unlocking it in the LimitOrder contract

Incorrect underflow-prevention logic when updating `marginDepositedTotal` which can lead to underflow and brick the system