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

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

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

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

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

Missing `ERC20Method` validation at destination allows non-transfer tx to be handled as transfers.

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

Users won't liquidate positions because the logic used to calculate the liquidator's profit is incorrect

Fragmentation fee is not taken if user compensates with newly created position

`executeBuyCreditMarket` returns the wrong amount of cash and overestimates the amount that needs to be checked in the variable pool

Users can not to buy/sell minimum credit allowed due to exactAmountIn condition

Multicall does not work as intended

Incomplete TVL Calculation in `AerodromeConnector::_getPositionTVL` Function.

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

`_getPositionTVL` of `UNIv3Connector` wrongly assumes ownership of all liquidity of the provided ticks inside `positionManager`.

Numerous errors when calculating the TVL for the MorphoBlue connector

`veMav` token in `MaverickConnector` does NOT have an existing oracle, so staking Mav would always lead to DoS for TVL calculation

`AccountingManager#totalWithdrawnAmount` should reflect tokens actually transferred to users, instead of expected transfers

The `TVLHelper.sol#getTVL` function is DOSed by the `under collateralized connector`, and as a result, many parts of the protocol may be DOS.

The total deposit amount limit in `AccountingManager.sol` can be bypassed

Lack of function to claim reward in `AaveConnector`

Balancer flashloan contract can be DOSed completely by sending 1 wei to it

Due to missing health factor and hardcoded balance checks on Dolomite, a borrow position can be opened by withdrawing more than the supplied balance leading to possible unwanted liquidations

Lack of functionality for `claimFees` calls to the Aerodrome Pool causes the connector to lose its deserved fees

Camelot and Aerodrome Connector TVL susceptible to manipulation attack

`revokeVestingSchedule` incorrectly update total supply and checkpoints

`revokeVestingSchedule` will not completely remove users voting power

`ZivoeITO`'s `claimAirdrop` will be impacted by the new `zSTT` and `zJTT` minting. Users will receive less rewards than they should.

Borrowers could skip at least one period of interest payment when paying off the loan in full and end up paying less interest

Push tokens to `OCL_ZVE` could revert most of the time due to allowance check

`forwardYield` of `OCL_ZVE` can be denied and skipped for another 30 days

`OCY_Convex_A` and `OCY_Convex_C` `claimRewards` can be bricked by poison reward token

Position Manager providing the wrong strike when storing user's position data

Borrower has no way to update `maxTotalSupply` of `market` or close market.

A malicious user can avoid unfavorable score updates after alpha/multiplier changes, resulting in accrual of outsized rewards for the attacker at the expense of other users

Prime.sol - User can claim Prime token without having any staked XVS, because his `stakedAt` isn't reset whenever he is issued an irrevocable token.

DoS and gas griefing of calls to Prime.updateScores()

The settle feature will be broken if attacker arbitrarily transfer collateral tokens to the PerpetualAtlanticVaultLP

`ReLPContract` wrongfully assumes protocol owns all of the liquidity in the UniswapV2 pool

The peg stability module can be compromised by forcing lowerDepeg to revert.

Bond operations will always revert at certain time when `putOptionsRequired` is true

Users can get immediate profit when deposit and redeem in `PerpetualAtlanticVaultLP`

_curveSwap: getDpxEthPrice and getEthPrice is in wrong order

reLP() mintokenAAmount the calculations are wrong.

`sync` function in `RdpxV2Core.sol` should be called in multiple scenarios to account for the balance changes that occurs

User can avoid paying high premium price by correctly timing his bond call

User that delegate eth to `RdpxV2Core` will incur loss if his delegated eth fulfilled by decaying bonds

Overflow can still happened when calculating `priceX8` inside `poolMatchesOracle` operation

Unused funds are not returned and not counted in `GeVault`

User can steal refunded underlying tokens from `initRange` operation inside `RangeManager`

User can prevent liquidation by enter another market that have low supply and borrow activity

Rounding error in `WUSDA` can result in loss of user funds, especially when manipulated by an attacker

crvRewardsContract `getReward` can be called directly, breaking vaults `claimRewards` functionallity

ether that deposited trough `_processEthIn` is not considered inside router's `mint` and `deposit` operations

Destination's vault rewards potentially not accounted when `withdraw` or `redeem` is called

Attacker can steal LMPVault's reward by keep transferring LMPVault's share to attacker's another accounts

Users can construct redeem operations to extract more value inside LMPVault that have destination vault with rewards

`liquidateVaultsForToken` is broken due to mistake when performing swap

When `queueNewRewards` is called, caller could transfer tokens more than it should be

`MavEthOracle` price susceptible to reserves manipulation attack

Wrong decimals used when calculating `averagePrice` inside `IncentivePricingStats.updatePricingInfo`

Convex and Aura `getReward` can be called directly, breaking liquidation rows functionality and automation

Calculator's APR can continuously reporting wrong value if first APR result is 0

User can steal tokens by using duplicated ERC20 tokens as parameter in NounsDAOLogicV1Fork.quit

Malicious user can front-run Gauges's `addBribeFlywheel` to steal bribe rewards

TalosBaseStrategy#init() lacks slippage protection

Rerange/rebalance should not use protocolFee as asset for adding liquidity

`unstakeAndWithdraw` inside `BoostAggregator` could lose pendingRewards in certain case

[M-01] Some functions in Talos contracts does not allow user to supply slippage and deadline, which may cause swap revert

RestakeToken function is not permissionless

Chainlink oracle data is not validated, could return unwanted price value.

incorrect calculation of `amountToSellUnits` inside `BuyUSSDSellCollateral()` function

rebalance process incase of buying the collateral, could revert caused by incorrect condition check

`StableOracleWBTC` use wrong chainlink price feed contract address

Incorrect decimals assumption used inside `StableOracleDAI` when dealing with `priceFeedDAIETH` returned price value

Missing `onlyBalancer` modifier for `mintRebalancer()` and `burnRebalancer()` function

`USSD`'s `UniV3SwapInput()` executes swaps without slippage and deadline protection

rebalance process incase of selling the collateral, could revert because of underflow calculation

rebalance process incase of selling the collateral, could revert cause not checking `pathsell.length`

Chainlink oracle data is not validated, could return unwanted `price` value.

Chainlink oracle data call in `AaveLeverageStategyExtension` is not validated, could return unwanted price value.

Accepting loan bid will always revert if ERC20 token that deducts fee on transfer used as the collateral.

updating TellerV2 lender manager will impact existing loan to send repay to previous lender manager

Attacker can front run marketplace creation to create malicious borrow offer

CHALLENGER_REWARD can be used to drain reserves and free mint

need alternative ways for fund transfer in `end()` to prevent DoS

PrivatePool owner can steal all ERC20 and NFT from user via arbitrary execution

`Factory.create`: Predictability of pool address creates multiple issues.

Some offers can't be cancelled

Missing a check for minimum sell amount at make function

BathBuddy contract should implement methods to pause and unpause contract

Fee inclusivity calculations are inaccurate in RubiconMarket

Incorrect calculations can occur when calling `Position._marketBuy` and `Position._marketSell` functions that do not include maker fee in `_fee`

Calling `Position._marketBuy` and `Position._marketSell` functions that calculate `_fee` by dividing by `10000` can cause incorrect calculations

Calling `ExpiringMarket.stop` and `ExpiringMarket.isClosed` functions cannot pause any functionlities of the market

In initial protocol state, user can keep calling `withdrawalRequest()`, but resulting in incorrect `user.withdrawalAllowance`.

Vault can be denied from receiving Funds while rebalancing, also leaving the vault to stuck in `State.WaitingForFunds`.

Calls to inactive vault's `pushTotalUnderlyingToController()` cause rebalance process to stuck

Make withdrawal request before vault become inactive could hold user funds

Adding blacklist protocol could break vault rebalance process