Reward Distribution Delay Vulnerability

Potential Reversion of the `addLiquidity` Function

Unfair Liquidation

The `maxTimesLeverage` of the Vault and the `maxLevTimes` of the LendingPool

Infinite Loop

`secondaryPosition.tickLower` could be same with `secondaryPosition.tickUpper`

Insufficient Decimal

Improper Transfer Restrictions on Non-Bridged Tokens Due to Boolean Bridged Token Tracking, Allowing a DoS Attack Vector

Incorrect Token Amount Tracking in updateParticipation Function

Incorrect Reward Claim Logic in FeeCollector::claimRewards Causes Denial of Service

Treasury Balance Tracking Bypass in FeeCollector

Treasury Contract Deposit Function Can Be Frontrun To Deny Protocol Operations

Emergency revoke in RAACReleaseOrchestrator will freeze revoked RAAC tokens in orchestrator

Token Accounting Mismatch Between tick() and mintRewards() in RAACMinter

Pending fee not cleared and overwritten by updates via updateFeeType()

`FeeCollector::updateFeeType` wrong fee share validation leads to impossible update for some fee types

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

The `_pairedLpTokenToPodLp` function could be reverted.

Incorrect calculation of `FraxlendPairCore.sol::prevUtilizationRate`

Whitelist Actions Should Update All Vaults

Incorrect `_updateAssetMetadataFromVault` function

POD Can Not Buy or Sell

Incorrect Slippage Application

Initial Liquidity Could Be Paided.

# Missing `Bracket::_createOrder()::existingOrderId` Check

# Missing `OracleLess::createOrder()::msg.sender` Check

# Missing `OracleLess.sol::createOrder()::orders.length` Check.

Minting zero tokens when underlyingToken is not Ether in cashIn()

Inconsistent Fee Calculation Leads to pay user more then intended !

Missing Slippage Protection in Vote Selling

# Invalid `marketFunds[profileId]`(sellVotes())

# Anyone Can Get Ether from This Contract

# Incorrect Fee Calculation

PreRun attacker can steal projectToken from any KYC address.

Inadequate Restriction on Compromised Addresses Fails to Protect User Data Integrity

Early Claimers will lose their rewards for the later valid epochs of a distribution and remaining funds will be locked in the contract forever !

Due To The `minWithdrawalAmount` check Users Who Want To Withdraw Wont Be Able To Queue Their Token Withdrawals On Some Amounts

Vultisig whitelisting can be bypassed by anyone

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

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

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)

Auction contract could be paused maliciously !

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

Test addresses and incorrect interface in code prevent integration with UniswapV3 and Camelot

Pools will fail to handle fee-on-transfer token accounting accurately

Malicious lender can scam borrower by increasing the interest way too much after loan being issued and take borrower's collateral.

The peg stability module can be compromised by forcing lowerDepeg to revert.

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

If a winner is blacklisted on any of the tokens they can't receive their funds

Owner can incorrectly pull funds from contests not yet expired

Centralization Risk for trusted organizers

Insufficient validation leads to locking up prize tokens forever

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

Chainlink oracle will return the wrong price if the aggregator hits `minAnswer`

Zero address check for tokens

Pragma isn't specified correctly which can lead to nonfunction/damaged contract when deployed on Arbitrum

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.

Contract Can Be Deployed Without Funds.

There's no functionalities for redeeming DAI for USSD in the contract.