Update the `marketFunds[ ]` mapping with wrong values

DOS for removal of delegates

Wrong percentage for team emission

Adversary can make honest parties unable to retrieve their assertion stakes if the required amount is decreased

The old founder still receiving NFT even after deleting it from the list

The Restriction Manager does not completely implement ERC1404 which leads to account that are supposed to be restricted actually have access to do with their tokens as they see fit

Receiving the rewarder in LMPVault create opportunity for MEV Bots (sandwich attack)

Users will receive more funds than they expect

Losing the tracking of the rewards that come from Destination Vault

`liquidateVaultsForToken()` is not transferring the funds for the swap in `asyncSwapper`

Users/LMPVault could lose their rewards

The `sink` address should not have a `perWalletLimit`

Users are not able to withdraw their funds from `LMPVault`

Missing to change the decimals

PartyB funds could get staked forever

User's funds could get staked for a period of time

Users will be able to open a position with leverage lower than one

User funds are locked forever because no one can complete the liquidation

Users will never receive a profit if the position gets liquidated

attackers will keep stealing the `rewards` from Convex SPELL

missing slippage protection

users could be exposed to big penalties from the Curve Pool

`ShortLongSpell.openPosition()` should not refund token

the core logic of `ShortLongSpell` is breaked

Aura SPELL is not compatible with Balancer pools

Attacker could steal all the `borrowBalance` from Aura SPELL

M-03 wrong token address on `ShortLongSpell.sol`

asking for the wrong address for `balanceOf()`

`getPositionRisk()` will return a wrong value of risk

`StopLossDecrease` are broken when there are price gaps

Users could be arbitrarily ejection from the rollover queue

The rollover queue system will break

Users could avoid the paying `depositFee`

`Emissions` could get locked in the vault forever.

Missing validations for return value of oracle data feed

Precision loss in the state variable `savedTotalUnderlying`

The protocol could not handle multiple vaults correctly

Stuck during the cross-chain rebalancing

Malicious users could break the logic of the rebalancing

`getDecimals()` always call the MainNet

`xChainController` will send funds multiple times to the same vault

Asking for `balanceOf()` in the wrong address

Game players won't be able to ` redeemRewardsGame()`

Vaults push wrong value of `totalUnderlying`

Malicious users could set allocations to a blacklist Protocol and break the rebalancing logic

The vault will send lower values, even if it can provide the required amount from `xChainController`.

the Blacklisted protocols will keep generating rewards

Protocol can't handle rewards of AAVE correctly

The protocol will set wrong allocations to a chain without a protocol (blacklisted)

The vault could leave some funds in protocol X for ever

Vault could `rebalance()` before funds arrive from xChainController

Users could leave some of `ICHI Vault LP` on SPELL

User could bypass the `MaxLTV`

Attacker can deploys vaults with a malicious Staking contract

BeefyAdapter() malicious vault owner can use malicious _beefyBooster to steal the adapter's token

cool down time period is not properly respected for the `harvest` method

Hijacking of node operators minipool causes loss of staked funds

State Transition: Minipools can be created using other operator's AVAX deposit via recreateMinipool

NodeOp funds may be trapped by a invalid state transition

Admin does not have to wait to call `lastResortTimelockOwnerClaimNFT()`

`LPDA` price can underflow the price due to bad settings and potentially brick the contract

Sale contracts can be bricked if any other minter mints a token with an id that overlaps the sale

NFTs mintable after Auction deadline expires

The `_fee()` function is wrongly implemented in the code

Call to declareInsolvent() would revert when contract status reaches liquidation point after repayment of credit position 1

The lender can draw out extra credit token from borrower's account

Variable balance ERC20 support

address.call{value:x}() should be used instead of payable.transfer()

Borrower/Lender excessive ETH not refunded and permanently locked in protocol

Users could get some `DOLA` even if their are on liquidation position

Calling `repay` function sends less DOLA to `Market` contract when `forceReplenish` function is not called while it could be called

gas limit DoS via unbounded operations

The `first in First out` system could be manipulated by the users

The public can’t call `debtWriteOff()` in specific case

Users will receive less than they expect from the `borrow()`

Missing updating of the `unit` value.

StandardPolicyERC1155.sol returns amount == 1 instead of amount == order.amount

Rewards delay release could cause yields steal and loss

Users who deposit in one vault can lose all deposits and receive nothing when counterparty vault has no deposits

`_transferFrom()` can be used to indefinitely increase voting power.

`ERC721Votes`: Token owners can double voting power through self delegation

Use can get unlimited votes

A proposal can be cancelled by anyone if the proposal has exactly proposalThreshold votes

Delegation should not be allowed to address(0)

The quorum votes calculations don't take into account burned tokens

Loss of Veto Power can Lead to 51% Attack

Possible to bypass saleConfig.limitPerAccount

Missing upper limit definition in replaceLenderFee() of HomeFi.sol

transfer() depends on gas consts

Use a safe transfer helper library for ERC20 transfers