Malicious actors can manipulate the `cross_chain_callback` callback

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

settlement.cairo doesn't process callback correctly leading to CrossChainMsgStatus marked as SUCCESS even if it failed on destination chain

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

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

Incorrect withdraw queue balance in TVL calculation

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

V3Vault::transform does not validate the `data` input and allows a depositor to exploit any position approved on the transformer

Risk of reentrancy `onERC721Received` function to manipulate collateral token configs shares

V3Oracle susceptible to price manipulation

Permit functions inside JalaRouter02 will not work

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

formPOL lacks slippage and deadline protection

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

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

User can mint dollars even if the price is beyond the mintPriceThreshold

Function WildcatMarketController.setAnnualInterestBips allows for values outside the factory range