Unrestricted Changes to Token Settings Allow Artists to Alter Critical Features

Reentrancy Vulnerability Allows Bypass of Cooldown, Leading to Unfair Reward Extraction Through Flash Loan

Signature replay in `createArt` allows to impersonate artist and steal royalties

`PhiFactory:claim` Potentially Causing Loss of Funds If `mintFee` Changed Beforehand

Refunds sent to incorrect addresses in certain cases

Incorrect Fee Handling Prevents Protocol from Updating Fees

Attacker can DOS user from selling shares of a credId

PhiNFT1155 contracts continue sending fees/royalties to old protocol destination address

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

Owner of a cancelled Sablier stream will be elegible for a full amount reward claim, due to a revert in `FjordStaking::onStreamCanceled(...)`

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

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

Invalid validation in _farmPlots function allowing a malicious user repeated farming without locked funds

Users can farm on zero-tax land if the landlord locked tokens before the LandManager deployment

Violation of Invariant Allowing DSSs to Slash Unregistered Operators

The operator can create a `NativeVault` that can be silently unslashable.

Delayed Slashing Window and Lack of Transparency for Pending Slashes Could Lead to Loss of Funds

Slashing’s will Always Fail In Some Cases

Not upadting `_totalAuctionTokenAllocation` when removing last auction config at cooldown leads to wrong accounting of `_totalAuctionTokenAllocation` and permanent lock of auction tokens

Changes to vesting period is not handled inside `_getVestingRate`

TempleGold tokens cannot be recovered when a `DaiGoldAuction` ends with 0 bids

The amount of `xezETH` in circulation will not represent the amount of `ezETH` tokens 1:1

Incorrect withdraw queue balance in TVL calculation

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

Incorrect calculation of queued withdrawals can deflate TVL and increase ezETH mint rate

Potential Arbitrage Opportunity in the xRenzoDeposit L2 contract

Deposits will always revert if the amount being deposited is less than the bufferToFill value

Not handling the failure of cross chain messaging

Lack of slippage and deadline during withdraw and deposit

Withdrawals and Claims are meant to be pausable, but it is not possible in practice

Users can lose access to funds due to minimum withdrawal limits.

Exploitation of the receive Function to Steal Funds

Lack of update when modifying pool fee

First depositor inflation attack in `PendlePowerFarmToken`

Malicious user can stake an amount which causes zero curStakeAtRisk on a loss but equal rewardPoints to a fair user on a win

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

Since you can reroll with a different fighterType than the NFT you own, you can reroll bypassing maxRerollsAllowed and reroll attributes based on a different fighterType

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

Player can mint more fighter NFTs during claim of rewards by leveraging reentrancy on the `claimRewards() function `

Fighters cannot be minted after the initial generation due to uninitialized `numElements` mapping

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

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)

Constraints of dailyAllowanceReplenishTime and allowanceRemaining during mint() can be bypassed by using alias accounts & safeTransferFrom()

Fighter created by mintFromMergingPool can have arbitrary weight and element

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

First Liquidity provider can claim all initial pool rewards

changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehand

DOS of proposals by abusing ballot names without important parameters

Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards.

If there is only one USDS borrower, he can never be liquidated

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

swap fees going to the liquidation pool manager contract will be accounted for as part of the liquidation amount

Divergence in the pricing method for collateral within the `calculateMinimumAmountOut()` may result in vaults transitioning into an uncollateralized state after executing swaps.

Incorrect calculation of amount of EURO to burn during liquidation

Removing assets in the `TokenManager` leads to major issues

Removal of approved token from token manager can lead to unintended liquidation of vaults

Incorrect value returned by position() function

Incorrect amounts of ETH are transferred to the DAO treasury in `ERC20TokenEmitter::buyToken()`, causing a value leak in every transaction

Once EntropyRateBps is set too high, can lead to denial-of-service (DoS) due to an invalid ETH amount

CultureIndex.sol#dropTopVotedPiece() - Malicious user can manipulate topVotedPiece to DoS the whole CultureIndex and AuctionHouse

Bidder can use donations to get VerbsToken from auction that already ended.

`encodedData` argument of `hashStruct` is not calculated perfectly for EIP712 singed messages in `CultureIndex.sol`

removedLiquidity can be underflowed to lock other user's deposits

`GMXVault` can be blocked by a malicious actor

Incorrect Execution Fee Refund address on Failed Deposits or withdrawals in Strategy Vaults

`emergencyPause` does not check the state before running && can cause loss of funds for users

Setter functions for core GMX contracts

Missing minimum token amounts in the emergency contract functions allows MEV bots to take advantage of the protocols emergency situation

Inaccurate Fee Due to missing lastFeeCollected Update Before feePerSecond Modification

emergencyResume does not handle the afterDepositCancellation case correctly

Lenders can escape the blacklisting of their accounts because they can move their MarketTokens to different accounts and gain the WithdrawOnly Role on any account they want

When withdrawalBatchDuration is set to zero lenders can withdraw more then allocated to a batch

Borrower has no way to update `maxTotalSupply` of `market` or close market.

Borrowers can escape from paying half of the penalty fees by closing the market, and those remaining penalty fees will be covered by the lender who withdraws last

Borrower can drain all funds of a sanctioned lender

Function WildcatMarketController.setAnnualInterestBips allows for values outside the factory range

`create2WithStoredInitCode()` does not revert if contract deployment failed

Blocked accounts keep earning interest contrary to the WhitePaper

Users can avoid liquidation while being under the primary liquidation ratio if on the last short record

Flag can be overriden by another user

Combining shorts can incorrectly reset the shorts flag

Incorrect check for cRation_MAX

Lack of Duplicate ID Check in combineShorts Function

Partial filled short does not reset liquidation flag after user gets fully liquidated, meaning healthy position will still be flagged if the rest of the order gets filled.

Missing minimum and maximum deposit checks for bridge contract interactions

Event in secondaryLiquidation could be misused to show false liquidations

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

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

Users can get immediate profit when deposit and redeem in `PerpetualAtlanticVaultLP`

`UniV3LiquidityAMO::recoverERC721` will cause `ERC721` tokens to be permanently locked in `rdpxV2Core`

`sync` function in `RdpxV2Core.sol` should be called in multiple scenarios to account for the balance changes that occurs

Voters from VotingEscrow can vote infinite times in vote_for_gauge_weights() of GaugeController

If governance removes a gauge, user's voting power for that gauge will be lost.

Tokens with less than 18 decimals allow for draining of funds

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

During refinance() new Pool balance debt is subtracted twice

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Fee on transfer tokens will cause users to lose funds

Token spending by Uniswap router doesn't get approved

No expiration deadline leads to losing a lot of funds

Lender contract can be drained by re-entrancy in `seizeLoan`

Rounding error risk in borrow() function in Lender.sol

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.

The arbiter should not be either the buyer or the seller.

Lack of slippage protection can lead to significant loss of user funds