The redeem fee is paid by the protocol, instead of the user

Malicious users can DoS the redeem limit by creating non-executable orders and withdrawing immediately

Collateral can get stuck in the minting contract under certain conditions or be accounted as profit

The user can send tokens to any address by using two bridge transfers, even when transfers are restricted.

Improper Transfer Restrictions on Non-Bridged Tokens Due to Boolean Bridged Token Tracking, Allowing a DoS Attack Vector

Missing reentrancy protection in the OracleLess contract can be used to drain the contract

Hash collision of the orderId can lead to fund loss in multiple ways

Malicious users can create malicious orders on behalf of users which have approved allowances to the StopLimit/OracleLess contracts

Malicious users can drain Bracket.sol's assets through a combination of OracleLess and Bracket dummy/malicious orders

Tokens with blacklist can be used to permanently DoS the OracleLess contract and freeze all funds within it

OracleLess doesn't implement a minimum size order, as well as no maximum pending queue size which can lead to a permanent DoS

Protocol admin / Pool Owner will not be able to offboard/delist an asset without breaking liquidations and other core functionalities

SuperPool isn't fully compliant with ERC 4626

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Missing disapproval check in `LockManager.sol::approveUSDPrice` allows simultaneous approval and disapproval of a price proposal

Executor can steal all funds from public vault when a new module is set

`SNXConnector.sol` TVL calculation is incorrect.

`AccountingManager::resetMiddle` will not behave as expected

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

In Dolomite, when opening a borrow position, the holding position in the Registry will never be updated due to the removePosition flag being set to true

`AccountingManager#totalWithdrawnAmount` should reflect tokens actually transferred to users, instead of expected transfers

Withdrawals in AccountManager are prone to DOS attacks.

Base tokens accumulated from withdraw fees can't be transferred to/from the NoyaFeeReceiver and will remain stuck

The total deposit amount limit in `AccountingManager.sol` can be bypassed

Attacker can increase the length of `withdrawQueue` by withdrawing 0 amount of tokens frequently

`performanceFeeReceiver` cannot mint any performance fee shares even if TVL is dropped by only a very tiny amount

lzSend() forwards all of the contract balance as the native gas fee but the excess won't be always returned

If a curve pool which CurveConnector uses is killed the vault manager can't close the position leading to loss of funds

In the `Gearboxv3` connector the health factor of the account is never considered

Maverick Connector uses ETH as liquidity for some of the Maverick pools, but NOYA isn't equipped to handle ETH in its vaults without handling conversion to/from WETH in the connector

Due to missing health factor and hardcoded balance checks on Dolomite, a borrow position can be opened by withdrawing more than the supplied balance leading to possible unwanted liquidations

Design flaw and mismanagement in vault licensing leads to double counting in collateral ratios and positions collateralized entirely with kerosine

Kerosene collateral is not being moved on liquidation, exposing liquidators to loss

Users can get their Kerosene stuck until TVL becomes greater than Dyad's supply

Unable to withdraw Kerosene from `vaultmanagerv2::withdraw` as it expects a `vault.oracle()` method which is missing in Kerosene vaults

No incentive to liquidate small positions could result in protocol going underwater

No incentive to liquidate when CR <= 1 as asset received < dyad burned

retryMessage unable to handle edge cases.

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

Tokens can't be removed as a collateral without breaking liquidations and other core functions

Epochs are incorrectly accounted for when queueing and settling them with EigenLayer leading to a DoS of the protocol's withdrawal functionalities

FighterFarm:: reroll won't work for nft id greator than 255 due to input limited to uint8

Can mint NFT with the desired attributes by reverting transaction

All claimed rewards will be lost for the users using the account abstraction wallet

LayerZeroEndpoint.send() in L1Sender.sol may revert if the user does not provide enough native gas as specified

Due to missing checks on minimum gas passed through LayerZero, executions can fail on the destination chain

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

Unrestricted claiming of fees due to missing balance updates in `FeeSplitter`

Unauthorized Access to setCurves Function

Curves::_buyCurvesToken(), Excess of Eth received is not refunded back to the user.

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete

Rewards can be drained because of lack of access control

Missing deadline check allow pending transactions to be maliciously executed

Fees are hardcoded to 3000 in ExactInputSingleParams