Availability of deposit invariant can be bypassed

Lack of slippage and deadline during withdraw and deposit

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

`depositQueue.queue` in `AccountingManager` can be flooded causing a DoS

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

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

Incorrect deployment / missing contract will break functionality

V3Vault is not ERC-4626 compliant

`Vault.mintYieldFee` FUNCTION CAN BE CALLED BY ANYONE TO MINT `Vault Shares` TO ANY RECIPIENT ADDRESS

Any fee claim lesser than the total `yieldFeeBalance` as unit of shares is lost and locked in the `PrizeVault` contract

`VaultFactory` allows deployment of vaults with non-authentic `TwabController` and `PrizePool`

Lack of Slippage Protection in `withdraw`/`redeem` Functions of the Vault

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

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

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

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

Minter / Staker / Spender roles can never be revoked`..,

Constraints of dailyAllowanceReplenishTime and allowanceRemaining during mint() can be bypassed by using alias accounts & safeTransferFrom()

Burner role can not be revoked

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

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

Stuck rewards in `FeeSplitter` contract

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

Users staking via the `SurplusGuildMinter` can be immediately slashed when staking into a gauge that had previously incurred a loss

Wrong ProfitManager in GuildToken, will always revert for other types of gauges leading to bad debt

ProfitManager's "creditMultiplier" calculation does not count undistributed rewards; this can cause value losses to users

Anyone can prolong the time for the rewards to get distributed

The price of rsEHT could be manipulated by the first staker

Lack of slippage control on LRTDepositPool.depositAsset

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

`MinterContract::payArtist` can result in double the intended payout

Soft Restricted Staker Role can withdraw stUSDe for USDe

Test addresses and incorrect interface in code prevent integration with UniswapV3 and Camelot

Due to extremely short `votingDelay` and `votingPeriod`, governance is practically impossible.

`ODSafeManager#allowSAFE()` cannot be executed either by the proxy contract or any other address.

All tokens can be stolen from `VirtualAccount` due to missing access modifier

LMPVault is not 4626 compatible

`Vault.mintYieldFee` FUNCTION CAN BE CALLED BY ANYONE TO MINT `Vault Shares` TO ANY RECIPIENT ADDRESS

Any fee claim lesser than the total `yieldFeeBalance` as unit of shares is lost and locked in the `PrizeVault` contract

`VaultFactory` allows deployment of vaults with non-authentic `TwabController` and `PrizePool`

Lack of Slippage Protection in `withdraw`/`redeem` Functions of the Vault

CLOCK_MODE() will not work properly for Arbitrum or Optimism due to block.number

Wrong consideration of blockformation period causes incorrect votingPeriod and votingDelay calculations

Risk of silent overflow in reserves update

Calling `ExpiringMarket.stop` and `ExpiringMarket.isClosed` functions cannot pause any functionlities of the market

`feeRecipient` can be set to address(0) even if `feeMantissa` is more than zero

Staking rewards can be drained

Fee on transfer token not supported

Bad implementation in minter access control for `RabbitHoleReceipt` and `RabbitHoleTickets` contracts

Inflation of ggAVAX share price by first depositor

Users may not be able to redeem their shares due to underflow

wrong reward distribution between early and late depositors because of the late syncRewards() call in the cycle, syncReward() logic should be executed in each withdraw or deposits (without reverting)

`requireNextActiveMultisig` will always return the first enabled multisig which increases the probability of stuck minipools

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

Use of `payable.transfer()` Might Render ETH Impossible to Withdraw

Reentrancy in LiquidStakingManager.sol#withdrawETHForKnow leads to loss of fund from smart wallet.

Calling `updateNodeRunnerWhitelistStatus` function always reverts