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

`ChakraSettlement.receive_cross_chain_msg` and `ChakraSettlement.receive_cross_chain_callback` functions do not ensure that receiving `ChakraSettlement` contract's `contract_chain_name` must match `to_chain` corresponding to respective `txid` input though

SettlementSignatureVerifier is missing check for duplicate validator signatures

In Starknet already processed messages can be re-submitted and by anyone

handler's `receive_cross_chain_callback()` will always set the tx_status to `SETTLED` on source chain & burn the tokens (MintBurn Mode) even when the msg fails on destination

A cross-chain message can be initiated with invalid parameters

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

Excessive Authority Granted to Managers in the `ckr_btc.cairo` Contract Presents Significant Management Risks

`Tokens` Are Automatically Whitelisted Upon Creation And Binding Even When `_whiteListEnabled == false`

`Bridge` is unable to transfer ownership and upgrade on `ERC721Bridgeable`

Starknet tokens deposited with use_withdraw_auto can never be withdrawn

Tokens irrecoverable by owner on L1 if not an `ERC721` receiver

Starknet bridge contract does not check if the collection supports IERC721Metadata interface, so the ones that do not implement it will not be able to bridge NFTs

`BeanL1RecieverFacet#recieveL1Beans()` would never work

Arbitrary tokens and data can be bridged to `GnosisTargetDispenserL2` to manipulate staking incentives

Users will lose all ETH sent as `cost` parameter in transactions to and from Optimism

Non-normalized amounts sent via Wormhole lead to failure to redeem incentives

Refunds for unconsumed gas will be lost due to incorrect refund chain ID

The `msg.value` - `cost` for multiple cross-chain bridges are not refunded to users

The `refundAccount` is erroneously set to `msg.sender` instead of `tx.origin` when `refundAccount` specified as `address(0)`

Anchor state registry can be corrupted which will prevent game creation of the same type.

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(...)`

Erroneous probability calculation in physical attributes can lead to significant issues

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)

Can mint NFT with the desired attributes by reverting transaction

Fighter created by mintFromMergingPool can have arbitrary weight and element

High risk quorum bypass by appending extra bytes into the calldata.

When `DecentBridgeExecutor.execute` fails, funds will be sent to a random address

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.

DecentEthRouter.sol#_bridgeWithPayload() - Any refunded ETH (native token) will be refunded to the DecentBridgeAdapter, making them stuck

Missing access control on UTB:receiveFromBridge allows UTB swaps to be executed without spending bridge fees while bypassing fee/swap instruction signature verification

Users can use the protocol freely without paying any fees by calling the `DecentEthRouter::bridgeWithPayload()` function directly.

Persistent Contract Call revert prevents finalizing a ballot

Incorrect calculation to check remaining ratio after reward in StableConfig.sol

Adversary can prevent updating price feed addresses by creating poisonous proposals ending in `_confirm`

DOS of proposals by abusing ballot names without important parameters

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

Attack to make ````CurveSubject```` to be a ````HoneyPot````

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.

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

Rewards can be drained because of lack of access control

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

No incentive to liquidate small positions could result in protocol going underwater

Incorrect calculation of amount of EURO to burn during liquidation

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