`shareBalance` bloating eventually blocks curator rewards distribution

`SettlementBranch._fillOrder` does not guarantee the collateral of a position is enough to pay the future liquidation fee.

`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

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

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

The TX of the AuctionHouse#`refundBid()` called by the bidders, who are not winner, would be DOSed

formPOL lacks slippage and deadline protection

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

Wrong Implementation of `LiquidationPool::empty` excludes holder with pending stakes when decreasing a position, resulting in exclusion from asset distribution

A depositor of the GMXVault can bypass paying the fee when the depositor deposit into the GMXVault.

Unhandled DoS when access to Chainlik oracle is blocked

Possible DOS on deposit(), withdraw() and unstake() for BridgeReth, leading to user loss of funds

Lack of essential stale check in oracleCircuitBreaker()

User will lose collateral in the exact case `cRatio == minimumCR`

Missing slippage parameter on Uniswap `addLiquidity()` function

Overflow can still happened when calculating `priceX8` inside `poolMatchesOracle` operation

Sandwich attack to steal all ERC-20 tokens in the Fees contract

User can steal reward tokens if the Staking contract uses tokens with different decimals

Constructor of `Escrow` should make sure that `buyer`, `seller`, `arbiter` are different from each other.

The `msg.value` of Native ETH (in the form of the `msg.value` of WETH) would not be tracked and just stuck in the LMPVaultRouter if a user deposit the `amount` of WETH (`vault.asset()`) and send the `msg.value` of Native ETH at the same time when the user call the LMPVaultRouterBase#`deposit()`

Lack of validation to check whether or not the return value would be a stale price data

Lack of scaling the decimals precision in the AccountFacet#`depositAndAllocateForPartyB()`, which lead to a misaccounting

A PartyB manager can not remove (revoke) a PartyB's address even if the PartyB's address is a malicious address

Lack of a refund logic of the excess fee, which lead to an unexpected result that the excess fee of the caller will be stuck forever in the FootiumAcademy contract

A borrower/lender or liquidator will fail to withdraw the collateral assets due to reaching a gas limit

Zero reward rate calculation impedes low-decimals token distributions

A malicious user can create and enlist too many deposit queues at row cost, which lead to reverting the transaction because of reaching the block gas limit

A transaction of calling the the DepositManagerV1# `fundBountyNFT()` may be reverted despite the actual number of NFTs deposited (funded) has not reached the `nftDepositLimit` yet.

Vault fees can be set to anything when initilizing

Malicious Users Can Drain The Assets Of Vault. (Due to not being ERC4626 Complaint)

Price will not always be 18 decimals, as expected and outlined in the comments

`safeTransferMany()` doesn't actually use safe transfer

Lack of check whether the caller of `withdrawToken()` function is the Bull or not