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

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

not adding `claimable` balance to the total assets in `_harvestAndReport` can cause losses.

Inflated `totalAssets` in `StrategyMainnet`, `StrategyArb`, and `StrategyOp` Contracts

Missing Router Update Mechanism in StrategyMainnet Contract

Old router retains token allowance after update

[H-01] Auction tokens will be lost forever when auction ends without bids

The `SuperPool` vault is not strictly ERC4626 compliant as it should be

The `SuperPool.sol` contract is supposed to have `Pausable` functions, but none have the modifier

Griefer can DOS the `SuperPool` creation and make it very expensive for other users

`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

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

Pause and unpause functions are inaccessible

NFTs mature too slowly under default settings.

`Golden God` Tokens can be minted twice per generation

Each generation should have 1 "Golden God" NFT, but there could be 0

TraitForgeNft: Generations without a golden god are possible

Incorrect check against golden entropy value in the first two batches

Insufficient checks to confirm the correct status of the sequencerUptimeFeed

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

When `sellCreditMarket()` is called to sell credit for a specific cash amount, the protocol might receive a lower swapping fee than expected.

Corruptible Upgradability Pattern

Minting "works" is supposed to refund excess ETH, but it doesn't

Editions::mintBatch function will always revert

CREATE opcode works differently in the zkSync chain

`CREATE2` address collision during pool deployment allows for complete draining of the pool

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

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

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)

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

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