Theft of user refunds through `claimRefund` if `refundInfo::walletAddress` is not `20 bytes`

SwapDataZ parameters in `GatewayCrossChain` and `GatewayTransferNative` are not verified resulting in attacker being able to steal user refunds

`GatewaySender::onRevert` functions does not support transferring native tokens

Fees not taken into account in `GatewayTransferNative::onCall` if `targetZRC20 != zrc20`

Unauthorized calls to `GatewayTransferNative::withdraw` allows steal/override user refunds

attacker might create a dummy `targetZRC20/gasZRC20` pair without enough liquidity, causing `targetZRC20 => gasZRC20` swaps to fail

Use of `transferFrom` instead of `safeTransferFrom` fails for some tokens like USDT

Stale `swapDataB.fromTokenAmount` after execution of `swapDataZ` and `gasFee` deduction

Wrong encoding of `BTC` receiver in revert options

Fee bypass in `ValueFacet.removeValueSingle`

Rewards can be skipped when a user withdraws using `ValueFacet::removeValue` and `ValueFacet:removeValueSingle`

Users Who Queue Withdrawal Before A Slashing Event Disadvantage Users Who Queue After And Eventually Leads To Loss Of Funds For Them

Buffer Silently Locks Staked HYPE in Contract Without Using Them For Withdrawals Or Providing A Way To Be Pulled Out Or Moved To L1

Incorrect Balance Check in Validator Redelegation Process May Block Legitimate Rebalancing Operations

Attacker can exploits batch sender role to block result Submissions via fee transfer reversion

`postBatch` lacks duplicate vote checks, allowing reuse of validator proofs and signatures

Submitting requests could be prevented by front-running `postRequest` and submitting same exact request

Attackers can flood solvers with thousands of requests and prevent fee payouts

Users can claim more that their actual allotment

Rounding error in stepDuration calculations.

`buyFee` And `sellFee` Should Be Known Before Purchase

Users can prevent being reallocated by listing to marketplace

LamboFactory can be permanently DoS-ed due to createPair call reversal

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

Calculation for `directionMask` is incorrect

Since the cost of launching a new pool is minimal, an attacker can maliciously consume VirtualTokens.

Attacker can captures `VETH-WETH` depeg profits through a malicious pool, rendering rebalancer useless if VETH Price > WETH Price

VVVVCTokenDistributor::claim function doesn't authorize msg.sender resulting in theft of tokens by front-running

Attacker can DOS raffle creation by canceling all `PRIZE_LOCKED` raffles using `WinnablesTicketManager::cancelRaffle`

`_sendCCIPMessage` function does not check `ccipDestAddress` and `ccipDestChainSelector` arguments allowing anyone to propagate winner to an arbitrary chain and PrizeManager

Double voting using unlocked positions can occur every voting epoch

BribeRewarder uses wrong address to check owner of tokenId

BribeRewarder doesn't check whether current supply is zero resulting in some portion of rewards being lost

`BribeRewarder` calculates rewards incorrectly after entering a new epoch

MlumStaking::_requireOnlyOperatorOrOwnerOf incorrectly assumes msg.sender to be the position owner allowing unauthorized modifications to a position

Malicious `BribeRewarder`s with useless reward tokens can be created to fill rewarders of all voting epochs

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

Players can gain more NFTs benefiting from that past remainder in subsequent locks

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

`LiquidInfrastructureERC20.sol` disapproved holders keep part of the supply, diluting approved holders revenue.

Withdrawal from NFTs can be temporarily blocked

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

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

Users will lose their cross-chain transaction if the destination router do not have enough WETH reserves.

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.

Unrestricted claiming of fees due to missing balance updates in `FeeSplitter`

Unauthorized Access to setCurves Function

Protocol and referral fee would be permanently stuck in the Curves contract when selling a token

onBalanceChange causes previously unclaimed rewards to be cleared

Curves::_buyCurvesToken(), Excess of Eth received is not refunded back to the user.

`ERC20TokenEmitter::buyToken` function mints more tokens to users than it should do

No slippage protection for Market functions

The price of rsEHT could be manipulated by the first staker

Protocol mints less rsETH on deposit than intended