Malicious actors can manipulate the `cross_chain_callback` callback

There is no refund mechanism in `ChakraSettlement.processCrossChainCallback` or `ChakraSettlementHandler.receive_cross_chain_callback` function

Inconsistent Handler Validation Behavior in Cairo ERC20Handler's Cross-Chain Callback

Anyone can manipulate user nonce (nonce_manager) in settlement contract

Settlement contract is mistakenly used for the handler contract when assigning ReceivedCrossChainTx struct

inconsistency in sender address when creating cross chain messages on Starknet can lead to loss of funds

Wrong usage of transaction originator address instead of caller address

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

SettlementSignatureVerifier's required_validators is not updated, resulting in a low or high number of signatures being required

Dust donation might DOS all connectors to create new holding positions, by preventing removing existing holding positions

Incorrect bad debt accounting can lead to a state where the `claimFeesBeneficial` function is permanently bricked and no new incentives can be distributed, potentially locking pending and future protocol fees in the `FeeManager` contract

Liquidating chaining can be achieved by liquidating token collateral with the highest `collateralFactor`

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

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

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

FighterFarm:: reroll won't work for nft id greator than 255 due to input limited to uint8

Can mint NFT with the desired attributes by reverting transaction

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

DoS in `MergingPool::claimRewards` function and potential DoS in `RankedBattle::claimNRN` function if called after a significant amount of rounds passed.

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 depositor can break staking-rewards accounting

THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A `decreaseShareAmount` VALUE SUCH THAT THE `virtualRewardsToRemove` IS ROUNDED DOWN TO ZERO

Incorrect assumption in PoolMath.sol can cause underflow when zapping is used

SALT staker can get extra voting power by simply unstaking their xSALT

Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

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

Unauthorized Access to setCurves Function

If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsolete

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

The RandomizerVRF and RandomizerRNG not produce hash value.

Artist signatures can be forged to impersonate the artist behind a collection