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

Attackers can cause winner to loss their raffle amount permanently due to missing access control

Incorrect set up and logic of `referralInfoMap` in `SystemConfig::updateReferrerInfo` function

TokenManager - Unlimited withdraw

Native token withdrawal fails until manually approved

Formulaic Error Rounds Down Causing Total Loss Of Funds For Bid Takers During Abort

`listOffer` Unsafely References Fungible Identifiers

Number of entities in generation can surpass the 10k number

Forger Entities can forge more times than intended

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Invalid validation allows users to unlock early

in `farmPlots()` an underflow in edge case leading to freeze of funds (NFT)

Incompatibility with Multisig Wallets in `TempleGold::send` Function

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Invalid validation allows users to unlock early

in `farmPlots()` an underflow in edge case leading to freeze of funds (NFT)

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Attacker can frontrun to prevent vaults from being removed from the dNFT owner's position

Broken Invariant: highest bidder can cancel bid

Reentrancy in Vesting.sol:claim() will allow users to drain the contract due to executing .call() on user's address before setting s.index = uint128(i)

Attackers can make any user who just made a depositRequest to lose all their depositRequestBalance if called on the current epoch due to `previewClaimDeposit` returning 0.

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

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

Stablecoin currency can still be used by blacklisted users

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

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

All claimed rewards will be lost for the users using the account abstraction wallet

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

No slippage protection for Market functions

Lack of slippage control on LRTDepositPool.depositAsset

Attacker can reenter to mint all the collection supply

A malicious user can avoid unfavorable score updates after alpha/multiplier changes, resulting in accrual of outsized rewards for the attacker at the expense of other users

Sandwich attack to steal all ERC-20 tokens in the Fees contract

Single-step process for critical ownership transfer is risky

Lender fails to giveLoan because of inconsistent length between `loadIds` and `poolIds`

doesn't calculate the current borrowing amount for the provider, including the provider's borrowed shares and accumulated fees due to Inconsistency in collateralRatio calculation

Chainlink's `latestRoundData` may return stale or incorrect result

`getPriceFromChainlink` doesn't implements the sequencer feed check. Therefore doesn't handle when L2 sequencer feeds such as arbitrum sequencer is down in Chainlink feeds causing very outdated and inaccurate prices to still be read from the oracle.