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

Inconsistency across multiple repaying functions causing lender to pay extra fees.

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

Number of entities in generation can surpass the 10k number

Wrong minting logic based on total token count across generations

Forger Entities can forge more times than intended

Imprecise token age calculation results in an incorrect nuke factor, causing users to claim the wrong amount

`Golden God` Tokens can be minted twice per generation

Discrepancy between nfts minted, price of nft when a generation changes & position of `_incrementGeneration()` inside `_mintInternal()` & `_mintNewEntity()`

Incorrect check against golden entropy value in the first two batches

removedLiquidity can be underflowed to lock other user's deposits

`_validatePositionList()` does not check for duplicate tokenIds, allowing attackers to bypass solvency checks

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A `decreaseShareAmount` VALUE SUCH THAT THE `virtualRewardsToRemove` IS ROUNDED DOWN TO ZERO

It may be possible to DoS AuctionHouse by specifying malicious creators

Lack of Balance Validation

removedLiquidity can be underflowed to lock other user's deposits

`_validatePositionList()` does not check for duplicate tokenIds, allowing attackers to bypass solvency checks

User funds can be lost in favor of Zeta protocol during a CCTX due to contracts being paused

No slippage protection for Market functions

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

The RandomizerVRF and RandomizerRNG not produce hash value.

Soft Restricted Staker Role can withdraw stUSDe for USDe

Inconsistency across multiple repaying functions causing lender to pay extra fees.

addGlobalToken() localAdress could be overwritten

TWO DIFFERENT TRANSACTIONS CAN RESULT IN THE SAME `txnHash` VALUE THUS BREAKING THE APPROVAL PROCESS OF TRANSACTION MINTING

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

Incorrect precision assumed from RdpxPriceOracle creates multiple issues related to value inflation/deflation

_curveSwap: getDpxEthPrice and getEthPrice is in wrong order

Lack of Balance Validation

Return value of low level `call` not checked.

BORROWERS CAN AVOID LIQUIDATIONS, IF ERC777 TOKEN IS CONFIGURED AS AN `emissionToken`

Its not possible to liquidate deprecated market

Fee-on-transfer tokens aren't supported

High - Funds can be lost if any participant is blacklisted

Constructor of `Escrow` should make sure that `buyer`, `seller`, `arbiter` are different from each other.

Check price != 0 before interacting with IERC20

Reentrancy guard and nonReentrant modifier not required.

Typos

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

`drawManager` CAN BE SET TO A MALICIOUS ADDRESS

Unintended or Malicious Use of Prize Winners' Hooks

IF THE UNDERLYING ASSET IS A FEE ON TRANSFER TOKEN IT COULD BREAK THE INTERNAL ACCOUNTING OF THE VAULT

`extractTAP()` function can allow minting an infinite amount in one week, leading to a DoS attack in `emitForWeek()`

Missing deadline checks allow pending transactions to be maliciously executed

TapiocaOptionBroker::newEpoch - An epoch can be skipped leading for unclaimed tap to distribute to be lost

It is not possible to execute actions that require ETH (or other protocol token)

setWeight() Logic error

RestakeToken function is not permissionless

liquidateAccount will fail if transaction is not included in current block

anchorTime() will not work properly on Optimism due to use of block.number

function `restructureCapTable()` in Equity.sol not functioning as expected

DOS of market operations with malicious offers

REENTRANCY ATTACK POSSIBLE IF THE `_feeTo` IS A MALICIOUS CONTRACT IN `FeeWrapper._chargeFeePayable()` FUNCTION

Low level calls to accounts with no code will succeed in `FeeWrapper`

Zero reward rate calculation impedes low-decimals token distributions

Potential infinite loop in `_borrowLimit` function

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