Users can claim more that their actual allotment

Creator of one vesting plan can affect vesting plans created by other users.

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Three valid signatures for the same message

Malicious actors can manipulate the `cross_chain_callback` callback

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

In settlement.cairo::receive_cross_chain_msg - the payload_type can be passed by the user, confusing offchain systems

Anyone can manipulate user nonce (nonce_manager) in settlement contract

SettlementSignatureVerifier is missing check for duplicate validator signatures

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

Invalid token address used in `ChakraSettlementHandler::cross_chain_erc20_settlement(...)` leading to invalid transaction creation and event emission

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

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

Bridging from Starknet to Starknet causes mismatch between minted ckrBTC and BTC transferred to MuSig2

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

Loss of incentives if total weight in an epoch is zero

Adding staking instance as nominee before it is created

checkpoint function is not called before staking which can cause loss of rewards for already staked services.

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

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

Incorrect withdraw queue balance in TVL calculation

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

Fetched price from the oracle is not stored in `xRenzoDeposit`

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

Not handling the failure of cross chain messaging