Potential Out of Gas due to unbounded loop in `refund` function

Refund function can be halted completely by malicious user (contract) by reverting

Lack of `maxBuyUser` and `maxBuyCreator` value check corresponding to `idoAmount` value

Potential Congestion due to lack of `batchingInterval` and `maxTransfersPerBatch` modification Function in `OutgoingQueue` Contract

Rebase token, increasing or decreasing, resulting Potential Locked token in `tokenExclusionManager` or Last user unable to `claimRemovedTokens`

OOG on `claimRemovedTokens` loop due to potential large gap between `lastClaimedUserId` and `_currentSnapshotId`

Incomplete `TokenWhitelistManagement` implementation

Transferring ownership of a Portfolio is not updated (reflected) on `PortfolioInfolList`

Lack of possible changes on various gas variables

Adversary can block any `exit` due to `preCheck` reached `cap` by using flash-loan

Performance Fee calculation potential revenue loss on changing `performanceFee` value

Create Pool in Mock Distribution is missing validations; allowing duplicates, wrong decreaseInterval value and payoutStart value

The `editPool()` lacks a sanity check on the `payoutStart` parameter leading to incorrect or unfair reward distributions

LayerZeroEndpoint.send() in L1Sender.sol may revert if the user does not provide enough native gas as specified

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

Insufficient Gas Limit Specification for Cross-Chain Transfers in _buildCCIPMessage() method. WrappedTokenBridge.sol #210

Possible DOS on deposit(), withdraw() and unstake() for BridgeReth, leading to user loss of funds

Instant arbitrage opportunity through rETH and stETH price discrepancy

borrowRateMaxMantissa should be specific to the chain protocol is being deployed to

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

Single-step process for critical ownership transfer is risky

Liquidation Is Prevented Due To Strict Implementation of Liqudation Bonus

staleCheckLatestRoundData() does not check the status of the Arbitrum sequencer in Chainlink feeds.

DSC protocol can consume stale price data or cannot operate on some EVM chains

DSC Mint will either return true or revert, thus checking `minted` status in `mintDcs` is unnecessary

Fee-on-transfer tokens aren't supported

[H-01] Lack of emergency withdraw function when no arbiter is set

Fixed `i_arbiterFee` can prevent payment

`tokenContract`is always an unsafe input, for fairness, it is recommended to add a whitelist for token

Add an optional deadline parameter for dispute process

`MagnetarV2#burst` double counts `msg.value` for `TOFT_WRAP` operation, making the transaction revert unless the user overpays

`DirectBuyIssuer`'s getOrderEscrow amount didn't updated after `_fillOrderAccounting`

Adversary manipulate the middle path when calling `execute_dca_order`, resulting user loss, benefiting the attacker

`StableOracleWBTC`'s is using ETH/USD priceFeed, resulting less USSD on minting with WBTC collateral

Missing crucial modifier on `mintRebalancer` and `burnRebalancer` functions

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

StableOracleWBTC using BTC/USD chainlink oracle to price WBTC which have a potential problematic issue if WBTC depegs

Loss of funds for traders due to accounting error in royalty calculations

`changeFeeQuote` will fail for low decimal ERC20 tokens

Missing derivative limit and deposit availability checks will revert the whole `stake()` function

First depositor can manipulate which causes expensive or inflate share price

Unsafe `approve()` function resulting in failed transfer for certain ERC20 token (USDT)

Repeating `rebalanceBasket` can increase `totalUnRedeemedRewards`, thus `redeemRewards` more than they suppose to have

Refund a Deposit will failed because of unbounded `deposits` array.

current `refundDeposit` design may cause a `claimBounty` experience bad for winner

Protocol fees can be withdrawn multiple times in `Erc20Quest`

MultisigManager may not be able to add a valid Multisig

`saleReceiver` and `feeReceiver` can steal refunds after sale has ended

Use of `payable.transfer()` Might Render ETH Impossible to Withdraw

`createStream` didn't check if time is already passed can result instant withdrawal for recipient

Protocol can be DoS-ed, because of large `deposits` array index

`checkOrder` external function will block Auction process

Reward tokens mismanagement can cause users losing rewards

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

Attacker may DOS auctions using invalid bid parameters

address.call{value:x}() should be used instead of payable.transfer()

Owner can transfer all ERC20 reward token out using function recoverERC20

Protocol withdrawals of collateral can be unexpectedly locked if governance sets the `collateralFactorBps` to 0.

Bidder lost asset If auction is cancelled

Auction's `firstBidTime` already initiated before any user bid the Auction lead to miss-information and shorten auction duration

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

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

Supply cap of VariableSupplyERC20Token is not properly enforced

Harpie use transferFrom for ERC721 instead of safeTransferFrom

It should not submit a project with no total budget. Requires at least one task with cost > 0

Missing upper limit definition in replaceLenderFee() of HomeFi.sol