When a buyOrder is completed the NFT will be locked in the contract forever

Loans with TaxTokenReceipts as collateral can't be liquidated

The TaxTokensReceipt NFTs can't be utilized by a buy order

The MixOracle::getPrice() function will revert for some pairs, and return completely incorrect price in the rest of the cases

Last lenders to a defaulted loans which utilizes TaxTokensReceipt NFT as collateral, won't be able to withdraw their collateral.

When a loan is extended a lender may loose part of the interest he is owed

In certain scenarios borrowers will pay more fees for extending their loans than they are supposed to.

Lender may loose part of the interest he has accrued if he makes his lend offer perpetual after a loan has been extended by the borrower

Unused parameters in DebitaV3Loan::extendLoan() results in the function reverting in certain cases

Lenders and Borrowers that should receive incentives for creating orders that are matched, won't receive incentives in certain cases

A borrower may pay more interest that he has specified, if orders are matched by a malicious actor

Cancelation and matching of lend orders can be dossed

If no borrow and lend orders are matched during an epoch, the rewards for that epoch will be locked in the contract forever

No restrictions in DebitaIncentives.sol allows malicious users to farm rewards by creating and matching lend and borrow orders with 0 APR

Subtraction in `variance()` will revert due to underflow

Platform fees withdrawal will sweep oracle agents earned fees

Request responses and validations can be mocked leading to extraction of fees and/or forcing other generators to lose their fees by making them outliers

Users can list assets with price < 1 ERC20 (ETH, WETH), leading to potential DoS vulnerability.

Creators of boosts can't withdraw the funds they deposit into boosts

A boost can be created in such a way that the Boost protocol doesn't receive any fees.

The protocol won't work correctly with fee on transfer tokens

The formula for charging interest on reserved assets, charges much more than it should

Malicious users that reserve NFTs, can adjust their protectedPositions, and pay much less interest rate that they should

Users who modify their listings will pay more tax than they should, when modifying only the floorMultiplier

LV token holders receive proportional fees, when they shouldn't

If not all users have requested to redeem their LV tokens, some PA tokens will be locked in the protocol forever

RA amount is not updated properly in Vault::redeemEarlyLv()

RA amount is not updated properly in Psm::redeemRaWithDs()

FlashSwapRouter::emptyReserve() and FlashSwapROuter::emptyReservePartial() functions return incorrect values

Psm::repurchase() doesn't update the RA accounting correctly

The UUPS proxie standard is implemented incorrectly, making the protocol not upgradeable

Functions that should be called trough a proxy contract implement the notDelegated modifier

The ModuleCore::issueNewDs() function will revert if the totalSupply of LV tokens is 0

The protocol claims to support rebasing tokens, however accrued rewards will be lost

Creation of raffles can be DOSed, making the whole protocol obsolete

A malicious user can lock the prize for winning a raffle provided by the admin when a raffle is canceled

If a raffle has been canceled and users were refunded their AVAX, the admin won't be able to withdraw any AVAX accumulated from ticket sales

An admin can guarantee that an address he controls is the winner of the raffle

Admin can set the winner of the raffle to an address of his choosing

Roles can't be revoked

`mintToken()`, `mintWithBudget()`, and `forge()` in the `TraitForgeNft` Contract Will Fail Due to a Wrong Modifier Used in `EntropyGenerator.initializeAlphaIndices()`

Number of entities in generation can surpass the 10k number

Wrong minting logic based on total token count across generations

Funds can be locked indefinitely in NukeFund.sol

There is no slippage check in the `nuke()` function.

Forger Entities can forge more times than intended

Pause and unpause functions are inaccessible

NFTs mature too slowly under default settings.

Discrepancy between nfts minted, price of nft when a generation changes & position of `_incrementGeneration()` inside `_mintInternal()` & `_mintNewEntity()`

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

[H-01] Miscalculation in `_farmPlots` function could lead to a user unable to unstake all NFTs

Invalid validation in _farmPlots function allowing a malicious user repeated farming without locked funds

Users can farm on zero-tax land if the landlord locked tokens before the LandManager deployment

Voting for a pool will always revert

Rewards are calculated as distributed even if there are no voters, locking the rewards forever

Users can double vote

Adding genuine BribeRewarder contract instances to a pool in order to incentivize users can be DOSed

Potential issues with the ``BribeRewarder.sol`` contract, when the reward token is a Weird ERC20 token

Transfer of ILOPool NFT token to different account allows for users to bypass the pool's `maxCapPerUser` invariant

`AccountingManager::resetMiddle` will not behave as expected

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

Withdrawals in AccountManager are prone to DOS attacks.

`totalAssets()`, and thus `convertToShares()` and `convertToAssets()`, may revert, in violation of ERC-4626

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

AccountingManager has no correct implementations of the core ERC-4626 functions `deposit`, `mint`, `withdraw` and `redeem`

`maxDeposit`, `maxMint`, `maxWithdraw`, and `maxRedeem` functions do not return 0 when they should

`AccountingManager` contract's `previewDeposit`, `previewMint`, `previewWithdraw`, and `previewRedeem` functions are not compliant with EIP-4626 standard

Dust donation might DOS all connectors to create new holding positions, by preventing removing existing holding positions

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Inability to perform partial liquidations allows huge positions to accrue bad debt in the system

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

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

Attacker can frontrun to prevent vaults from being removed from the dNFT owner's position

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

Liquidating positions with bounded Kerosen could be unprofitable for liquidators

Revoking user's vesting doesn't remove all of the user's votes

Revoking user vesting DOSes the last withdrawers

Rewards in the different ZivoeRewards implementations can be diluted by a malicious user

If the reward token in ZivoeRewards and ZivoeRewardsVesting is a token with less than 18 decimals, rewards may get stuck in the contract

Rewards are calculated as distributed even if there are no stakers, locking the rewards forever

Incorrect setting of lotId, makes the whole protocol obsolete

Overflow in curate() function, results in permanently stuck funds

Unsold tokens from a FPAM auction, will be stuck in the protocol, after the auction concludes

PrincipalToken is not ERC-5095 compliant

Malicious user can stake an amount which causes zero curStakeAtRisk on a loss but equal rewardPoints to a fair user on a win

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

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

A malicious user can game the system to increase his chances of winning a round

Attack to make ````CurveSubject```` to be a ````HoneyPot````

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

Unauthorized Access to setCurves Function

Protocol and referral fee would be permanently stuck in the Curves contract when selling a token

onBalanceChange causes previously unclaimed rewards to be cleared

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

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

Malicious users can honeypot other users by minting all the ``EURO`` tokens that the vault's ``collateralRate`` allows right before sale

`costInEuros` calculation will incur precision loss due to division before multiplication

Lack of Minimum Amount Check in `SmartVaultV3::mint`, `SmartVaultV3::burn`, and `SmartVaultV3::swap` Can Result in Loss of Fees

The quorumVotes can be bypassed

The implementation of ``updateFounders()`` introduces different vulnerabilities based on the scenario it is called in.

Attacker can drain all ETH from AuctionDemo when block.timestamp == auctionEndTime

getPrice `salesOption` 2 can round down to the lower barrier, skipping the last time period

Auction winner can prevent payments via `safeTransferFrom` callback

The peg stability module can be compromised by forcing lowerDepeg to revert.

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

Borrower can use Refinance to cancel auctions so they can extend their loan indefinitely

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Using forged/fake lending pools to steal any loan opening for auction

Stealing any loan opening for auction through others' lending pool

Token spending by Uniswap router doesn't get approved

getUnderlyingPrice may return stale data