Users Who Queue Withdrawal Before A Slashing Event Disadvantage Users Who Queue After And Eventually Leads To Loss Of Funds For Them

Unauthorized Reallocation in `NudgeCampaign::handleReallocation` and Reward Disruption Vulnerability in `NudgeCampaign::invalidateParticipations`

Lack of deadline check in forwarded request

Potential Uninitialized `entropySlots` Reading in `getNextEntropy`, Causing 0 Entropy Mint

Availability of deposit invariant can be bypassed

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

stETH/ETH Feed being used opens up to 2 way deposit<->withdrawal arbitrage

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

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

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

`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

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

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

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

Value of kerosene can be manipulated to force liquidate users

Incorrect deployment / missing contract will break functionality

Liquidation bonus logic is wrong

A successfully disputed redemption proposal has still increased the redemption fee base rate; exploit to depeg dUSD

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

Funds locked due to missing transfer check

`maxDeposit()` uses `yieldVault.maxDeposit()` but `_depositAndMint()` uses `yieldVault.mint()`

`_maxYieldVaultWithdraw()` uses `yieldVault.convertToAssets()`

Holders array can be manipulated by transferring or burning with amount 0, stealing rewards or bricking certain functions

Withdrawal from NFTs can be temporarily blocked

Distribution can be bricked, and double claims by a few holders are possible when owner calls `LiquidInfrastructureERC20::setDistributableERC20s`

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

Almost all rarity rank combinations cannot be, and are not uniformly, generated

Can mint NFT with the desired attributes by reverting transaction

Fighter created by mintFromMergingPool can have arbitrary weight and element

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

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

Selling will be bricked if all other tokens are withdrawn to ERC20 token

onBalanceChange causes previously unclaimed rewards to be cleared

No slippage protection for Market functions

Users will lose rewards when buying new tokens if they already own some tokens

Possible arbitrage from Chainlink price discrepancy

Malicious users can front-run to cause a denial of service (DoS) for StakedUSDe due to MinShares checks

Borrower can drain all funds of a sanctioned lender

Lack of Balance Validation

An attacker can manipulate the preDepositvePrice to steal from other users.

Reth.sol: Withdrawals are unreliable and depend on excess RocketDepositPool balance which can brick the whole protocol

sFrxEth may revert on redeeming non-zero amount

No slippage protection on `stake()` in SafEth.sol

Residual ETH unreachable and unuitilized in SafEth.sol

Stuck ether when use function `stake` with empty `derivatives`(`derivativeCount` = 0)

DoS due to external call failure

Missing derivative limit and deposit availability checks will revert the whole `stake()` function

`characterModifier` is `uint8` but encodes `1.38e24` different Zalgo distortions.

The range of `iteratePRNG` limits the number of Zalgo distortions

ProfilePicture subprotocol is immutably linked by `subprotocolName` to the CID protocol

Unsafe casting from `uint256` to `uint16` could cause ticket prizes to become much smaller than intended

Possibility to steal jackpot bypassing restrictions in the executeDraw()

``lastFeeOperationTime`` is not modified correctly in function ``_updateLastFeeOpTime()``, resuling a much slower decay model for borrowing base rate

address.call{value:x}() should be used instead of payable.transfer()

Borrower/Lender excessive ETH not refunded and permanently locked in protocol

Protocol withdrawals of collateral can be unexpectedly locked if governance sets the `collateralFactorBps` to 0.

Chainlink oracle data feed is not sufficiently validated and can return stale `price`

An attacker can manipulate each pod and gain an advantage over the remainder Operators

Bad source of randomness

`_payoutToken[s]()` is not compatible with tokens with missing return value

`_payoutEth()` calculates `balance` with an offset, always leaving dust `ETH` in the contract

Governor can rug pull the escrow

StandardPolicyERC1155.sol returns amount == 1 instead of amount == order.amount

Protocol can be easily rug-pulled by the owner

Supply cap of VariableSupplyERC20Token is not properly enforced

Founders can receive less tokens that expected

The governance system can be held hostage by a malicious user

Moving average precision is lost