The calculation of `totalAssets()` could be wrong if `operatorFeeAmount` > 0, this can cause potential loss for the new depositors

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

User can earn rewards by frontrunning the new rewards accumulation in Ron staking without actually delegating his tokens

Auctions cannot proceed to the SUCCEEDED state

`SecondSwap_Marketplace` vesting listing order affects how much the vesting buyers can claim at a given step

Rounding error in stepDuration calculations.

Underflow in `claimable` DOSing `claim` Function

Outdated penalty fee gets charged if the penalty fee has changed since listing

Missing option to remove tokens from the `isTokenSupport` mapping can result in huge financial loss for users and the protocol

Reentrancy Vulnerability Allows Bypass of Cooldown, Leading to Unfair Reward Extraction Through Flash Loan

Exposed `_removeCredIdPerAddress` & `_addCredIdPerAddress` allows anyone to cause issues to current holders as well as upcoming ones

`shareBalance` bloating eventually blocks curator rewards distribution

Refunds sent to incorrect addresses in certain cases

Attacker can lock up winner rewards in the Prize Manager contract by several ways during call of `propagateRaffleWinner` in Ticket Manager

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

The maximum number of generations is infinite

Wrong minting logic based on total token count across generations

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

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

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

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

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

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

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

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

Users can increase their balances without token deposits

User cap amounts can be breached to DoS other users depositing

Availability of deposit invariant can be bypassed

`AccountingManager::resetMiddle` will not behave as expected

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

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

First depositor can make subsequent depositor lose all of her or his deposit

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

If a winner is blacklisted on any of the tokens they can't receive their funds

Owner can incorrectly pull funds from contests not yet expired