`TokenRewardInfo::lastRewardIndex` is also updated in the `SuperDCAStaking::stake(...)` along with the global index without minting the rewards for that period.

Protocol does not support ETH as a pool token

`SuperDCAGuage` can be used in the different pool to steal the rewards of the listed NFP's pool

`SuperDCACashback` does not support USDC with different decimals than 6

New mint rate is set in the `SuperDCAStaking` without updating the global `rewardIndex`

Fee accrued can be stolen by new LPs if fee is collected in one token only or collected in large amount for the other token.

Incorrect check in `Launch::updateParticipation(...)` for min and max token amounts

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

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

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

Incorrect Parameter in `safeTransferFrom(...)` May Result in Theft of User's Claim Amount

Incorrect withdraw queue balance in TVL calculation

Deposits will always revert if the amount being deposited is less than the bufferToFill value

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

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

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

Incorrect deployment / missing contract will break functionality

The highest bidder can cancel all of his bids and claim the Steward License for free

Loss of Tokens Due to Incorrect Fee Deduction in `WooCrossChainRouterV4`

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(...)`

When `DecentBridgeExecutor.execute` fails, funds will be sent to a random address

Users will lose their cross-chain transaction if the destination router do not have enough WETH reserves.

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

`StakingRewardsManager::topUp(...)` Misallocates Funds to `StakingRewards` Contracts

`CouncilMember::burn()` does not update states correctly leading to the loss of tokens to the council members.

Sablier stream update in `CouncilMember.sol` can cause loss of funds if the streamed balance is not withdrawn.

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

`encodedData` argument of `hashStruct` is not calculated perfectly for EIP712 singed messages in `CultureIndex.sol`

Founders will not be able to mint their token share if their assigned token ID is in the hundreds (i.e., 100, 200).

The price of rsEHT could be manipulated by the first staker

Possible arbitrage from Chainlink price discrepancy

Protocol mints less rsETH on deposit than intended

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

Fee-on-transfer tokens aren't supported