Theft of initial bonds from proposers who are using smart wallets

Loss of bond amounts on re-org attacks

Anyone can freeze future withdrawals and any L2->L1 messaging due to mismatch between the VM-viewed block number and the user supplied block number.

Attacker can amplify a rounding error in MagicLP to break the I invariant and cause malicious pricing

Anyone making use of the MagicLP's TWAP to determine token prices will be exploitable.

Permanent loss of yield for stakers in reward pools due to precision loss.

MagicLpAggregator always returns lower than correct answer, leading to arbitrage loss

A user's tokens could be locked for an extended duration beyond their intention and without their control

Loss of assumed functionality of the Onboarding contract in a highly-sensitive area

Miscalculation in addLiquidity of Router results in unauthorized spending of tokens

Pumps are not updated in the shift() and sync() functions, allowing oracle manipulation

Treating of BLOCK_TIME as permanent will cause serious economic flaws in the oracle when block times change

Long term denial of service due to lack of fees in Well

Due to bit-shifting errors, reserve amounts in the pump will be corrupted, resulting in wrong oracle values

Due to slot confusion, reserve amounts in the pump will be corrupted, resulting in wrong oracle values

Memory corruption in getBytes32FromBytes() can likely lead to loss of funds

Offchain name resolution would fail despite the located DNS resolver being fully functional

Invalid addresses will be accepted as resolvers, possibly bricking assets

Admin does not have to wait to call `lastResortTimelockOwnerClaimNFT()`

Draw organizer can rig the draw to favor certain participants such as their own account.

Protocol safeguards for time durations are skewed by a factor of 7. Protocol may potentially lock NFT for period of 7 years.

A whale user is able to cause freeze of funds of other users by bypassing withdraw limit

`PrePOMarket.setFinalLongPayout()` shouldn't be called twice.

Manager can get around min reserves check, draining all funds from Collateral.sol

Users do not receive owed tokens if `TokenSender` contract cannot cover their owed amount.

User can pass auction recovery health check easily with flashloan

UniswapV3 tokens of certain pairs will be wrongly valued, leading to liquidations.

Attacker can drain pool using executeBuyWithCredit with malicious marketplace payload.

Data corruption in NFTFloorOracle; Denial of Service

Users can be locked out of providing Uniswap V3 NFTs as collateral

During oracle outages or feeder outages/disagreement, the `ParaSpaceFallbackOracle` is not used

Centralization risk: admin can with rug the project by removing asset and price manipulation on oracle.

NFTFloorOracle's assets will use old prices if added back after removal

When users sign a credit loan for bidding on an item, they are forever committed to the loan even if the NFT value drops massively.

Attacker can abuse victim's signature for marketplace bid to buy worthless item

Bad debt will likely incur when multiple NFTs are liquidated.

Rewards are not accounted for properly in NTokenApeStaking contracts, limiting user's collateral.

Oracle does not treat upward and downward price movement the same in validity checks, causing safety issues in oracle usage.

Pausing assets only affects future price updates, not previous malicious updates.

Price can deviate by much more than maxDeviationRate

Oracle will become invalid much faster than intended on non-mainnet chains

MintableIncentivizedERC721 and NToken do not comply with ERC721, breaking composability

Reentrancy in LiquidStakingManager.sol#withdrawETHForKnow leads to loss of fund from smart wallet.

GiantLP with a transferHookProcessor cant be burned, users' funds will be stuck in the Giant Pool

Incorrect accounting in SyndicateRewardsProcessor results in any LP token holder being able to steal other LP tokens holder's ETH from the fees and MEV vault.

Giant pools can be drained due to weak vault authenticity check

Dao admin in LiquidStakingManager.sol can rug the registered node operator by stealing their fund in the smart wallet via arbitrary execution.

GiantMevAndFeesPool.previewAccumulatedETH function: "accumulated" variable is not updated correctly in for loop leading to result that is too low

dETH / ETH / LPTokenETH can become depegged due to ETH 2.0 reward slashing.

Calling `updateNodeRunnerWhitelistStatus` function always reverts

Incorrect checking in _assertUserHasEnoughGiantLPToClaimVaultLP

MED: Funds are not claimed from syndicate for valid BLS keys of first key is invalid (no longer part of syndicate).

Medium: User receives less rewards than they are eligible for if first passed BLS key is inactive

Medium: Giant pools are prone to user griefing, preventing their holdings from being staked.

Medium: Vaults can be griefed to not be able to be used for deposits

Freezing of funds - Hacker can prevent users withdraws in giant pools

GiantPool should not check ETH amount on withdrawal

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

Direct theft of buyers ETH funds.

Protocol can be easily rug-pulled by the owner

Hacked owner or malicious owner can immediately steal all assets on the platform

All orders which use expirationTime == 0 to support oracle cancellation are not executable.

Pool designed to be upgradeable but does not set owner, making it unupgradeable

Yul `call` return value not checked

Attacker can steal any funds in the contract by state confusion (no preconditions)

Attacker may DOS auctions using invalid bid parameters

Incompatibility with fee-on-transfer/inflationary/deflationary/rebasing tokens, on both base tokens and quote tokens, with varying impacts

addCredit / increaseCredit cannot be called by lender first when token is ETH

Borrower can craft a borrow that cannot be liquidated, even by arbiter. 

Repaying a line of credit with a higher than necessary claimed revenue amount will force the borrower into liquidation

Lender can trade claimToken in a malicious way to steal the borrower's money via claimAndRepay() in SpigotedLine by using malicious zeroExTradeData

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

Reward can be over- or undercounted in `extendPledge` and `increasePledgeRewardPerVote`

Fees charged from entire theoretical pledge amount instead of actual pledge amount

Pausing `WardenPledge` contract, which takes effect immediately, by its owner can unexpectedly block pledge creator from calling `closePledge` or `retrievePledgeRewards` function

Owner can transfer all ERC20 reward token out using function recoverERC20

Gas limit check is inaccurate, leading to an operator being able to fail a job intentionally

Gas price spikes cause the selected operator to be vulnerable to frontrunning and be slashed

LayerZeroModule miscalculates gas, risking loss of assets

MEV: Operator can bribe miner and steal honest operator's bond amount if gas price went high

Attacker can force chaotic operator behavior

HolographERC20 breaks composability by forcing usage of draft proposal EIP-4524

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

MED: isOwner / onlyOwner checks can be bypassed by attacker in ERC721/ERC20 implementations

MED: leak of value when interacting with an ERC721 enforcer contract

MED - Incorrect implementation of ERC721 may have bad consequences for receiver

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

Outstanding reserved tokens are incorrectly counted in total redemption weight

Reserved token rounding can be abused to honeypot and steal user's funds

Redemption weight of tiered NFTs miscalculates, making users redeem incorrect amounts - Bug #1

Deactivated tiers can still mint reserve tokens, even if no non-reserve tokens were minted. 

Wrong implementation of function `LBPair.setFeeParameter` can break the funcionality of LBPair and make user's tokens locked

Attacker can steal entire reserves by abusing fee calculation

Calling `swapAVAXForExactTokens` function while sending excess amount cannot refund such excess amount

After proposed 0.8.0 upgrade kicks in, L2 finalizeInboundTransfer might not work.

If L1GraphTokenGateway's outboundTransfer is called by a contract, the entire msg.value is blackholed, whether the ticket got redeemed or not.

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

Direct theft of buyers ETH funds.

Protocol can be easily rug-pulled by the owner

Hacked owner or malicious owner can immediately steal all assets on the platform

All orders which use expirationTime == 0 to support oracle cancellation are not executable.

Pool designed to be upgradeable but does not set owner, making it unupgradeable

Yul `call` return value not checked

A "FrontRunning attack" can be made to the `initialize` function

Rewards delay release could cause yields steal and loss

frxETHMinter.depositEther may run out of gas, leading to lost ETH

sfrxETH: The volatile result of previewMint() may prevent mintWithSignature from working

Permanent freeze of vested tokens due to overflow in _baseVestedAmount

Supply cap of VariableSupplyERC20Token is not properly enforced

PartyGovernance: Can vote multiple times by transferring NFT in same block as proposal

A majority attack can easily bypass Zora auction stage in OpenseaProposal and steal the NFT from the party.

A majority attack can steal precious NFT from the party by crafting and chaining two proposals

Attacker can list an NFT they own and inflate to zero all users' contributions, keeping the NFT and all the money

Attacker can force AuctionCrowdfunds to bid their entire contribution up to maxBid

Early contributor can always become majority of crowdfund leading to rugging risks.

TRSRY: front-runnable `setApprovalFor`

`activateProposal()` need time delay

Inconsistency in staleness checks between OHM and reserve token oracles

TRSRY susceptible to loan / withdraw confusion

Heart::beat() could be called several times in one block if no one called it for a some time

Protocol's Walls / cushion bonds remain active even if heart is not beating