Incorrect Total Assets Calculation in _harvestAndReport Leading to Share Value Manipulation and Irredeemable Assets

Incorrect value used in `buyVotes` function prevents market graduation which leads to loss of funds.

No slippage protection in `sellVotes` function can lead to loss of funds for the seller.

Locker owner can't withdraw more than 20% of his token, even when he uses vesting with maximum time.

`_updateRewards` isn't called in `UsualSP::removeOriginalAllocation()` which leads to loss of funds for the user

Funds can be permanently stuck due to lack of implementation in BoostOwner contract

Protocol can lose 100% of it's claim fee procentage

User signature can be used to claim incentive without his permission leading to loss of funds for a user

`FjordAuction` incorrect `block.timestamp` check allows users to bid after calling `auctionEnd` to claim more tokens than they should

Roles can't be removed from addressses

Incorrect set up and logic of `referralInfoMap` in `SystemConfig::updateReferrerInfo` function

Native token withdrawal fails until manually approved

[H-4] The function `PreMarkets::listOffer` charges an incorrect collateral amount, allowing users to manipulating collateral rates and drain the protocol's funds

The maximum number of generations is infinite

Number of entities in generation can surpass the 10k number

Wrong minting logic based on total token count across generations

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.

`Golden God` Tokens can be minted twice per generation

TraitForgeNft: Generations without a golden god are possible

Invalid validation allows users to unlock early

Single plot can be occupied by multiple renters

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

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

Market Disruption and Financial Loss Post-Liquidation

Functions calling `verifyReport` to verify offchain prices from chainlink will fail

payable Modifier in TradingAccountBranch::createTradingAccountAndMulticall

User may lose funds when creating Nexus account or executing user operations

Incompatibility with Multisig Wallets in `TempleGold::send` Function

TempleGold tokens cannot be recovered when a `DaiGoldAuction` ends with 0 bids

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

Invalid validation allows users to unlock early

Single plot can be occupied by multiple renters

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

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

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

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

Missing enough exogeneous collateral check in `VaultManagerV2::liquidate` makes the liquidation revert even if (DYAD Minted > Non Kerosene Value)

User can get their Kerosene stuck because of an invalid check on withdraw

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

Incorrect deployment / missing contract will break functionality

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

User can cancel his bid and buy NFT only for feeAmount

Since you can reroll with a different fighterType than the NFT you own, you can reroll bypassing maxRerollsAllowed and reroll attributes based on a different fighterType

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

Player can mint more fighter NFTs during claim of rewards by leveraging reentrancy on the `claimRewards() function `

Fighters cannot be minted after the initial generation due to uninitialized `numElements` mapping

NFTs can be transferred even if StakeAtRisk remains, so the user's win cannot be recorded on the chain due to underflow, and can recover past losses that can't be recovered(steal protocol's token)

Can mint NFT with the desired attributes by reverting transaction

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

Fighter created by mintFromMergingPool can have arbitrary weight and element

User can unlock NFTs and withdraw collateral from a leveraged position that they do not own.

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.

Whitelised accounts can be forcefully DoSed from buying curveTokens during the presale

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

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

Unauthorized Access to setCurves Function

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

Missing deadline check allow pending transactions to be maliciously executed

Fees are hardcoded to 3000 in ExactInputSingleParams

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

CultureIndex.sol#dropTopVotedPiece() - Malicious user can manipulate topVotedPiece to DoS the whole CultureIndex and AuctionHouse

It may be possible to DoS AuctionHouse by specifying malicious creators

The price of rsEHT could be manipulated by the first staker

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

Attacker can reenter to mint all the collection supply

Adversary can block `claimAuction()` due to push-strategy to transfer assets to multiple bidders

Auction winner can prevent payments via `safeTransferFrom` callback

Borrower has no way to update `maxTotalSupply` of `market` or close market.

ETH cannot always be unstaked using Rocket Pool

Infinite loop breaks protocol functionality.

The settle feature will be broken if attacker arbitrarily transfer collateral tokens to the PerpetualAtlanticVaultLP

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

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

Centralization Risk for trusted organizers

Insufficient validation leads to locking up prize tokens forever

Fee on transfer tokens will cause users to lose funds

Forcing a borrower to pay a huge debt via the giveLoan()

Hardcoded Router Address May Cause Token Lockup in Non-Standard Networks

Zero address leads to transaction reverts

`Staked` struct is created but never used

`stakerewardV2pool.withdraw()` should check the user's boost lock status.