Cross-Chain Signature Replay Attack Due to User-Supplied `domainSeparator` and Missing Deadline Check

Lack of deadline check in forwarded request

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

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

Anyone can manipulate user nonce (nonce_manager) in settlement contract

In settlement.cairo::receive_cross_chain_msg - the message will always be marked with Status::SUCCESS

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

A cross-chain message can be initiated with invalid parameters

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

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

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

Position's owed fees should allow underflow but it reverts instead, resulting in locked funds

Missing `lower<upper` check in `mint_position`

Unrevoked approvals allow NFT recovery by previous owner

`get_fee_growth_inside` in `tick.rs` should allow for `underflow`/`overflow` but doesn't

_onTransferReceived() does not work as intended

The Bridging Process will revert if the Collection is matched on the destination chain and not matched on the source chain

Infinite loop breaks whitelist removal funtionality on L2

Starknet tokens deposited with use_withdraw_auto can never be withdrawn

There is No `msg.value` check in `depositTokens`, causing potential token stuck

Upon the transfer of an escrowed NFT from the bridge to the user on StarkNet, the escrow status remains unaltered, failing to be reset

Incorrect function signatures in `_callBaseUri` break `baseURI` functionality

_disableInitializers is missing in Bridge’s constructor

Inadequate Checking of `isIncreasing` when trader adjusts position size

Positive PnL is lost for all parties when liquidating an account, potentially causing that the MarginCollateralRecipient ends up receiving way less USD value than what it could have received.

`SettlementBranch._fillOrder` does not guarantee the collateral of a position is enough to pay the future liquidation fee.

Incorrect logic for checking isFillPriceValid

Market Disruption and Financial Loss Post-Liquidation

Insufficient checks to confirm the correct status of the sequencerUptimeFeed

A malicious User can DOS all offchain orders making them unexecutable and leaving the protocol in an insolvent state. Also all offchain Trades can also be DOSed for honest parties that do not meet the fillorder requirements (no try and catch)

QA Report - 0xStalin - Low Severities

Offchain orders are not cancelled after the account has been liquidated

Functions calling `verifyReport` to verify offchain prices from chainlink will fail

Liquidation of accounts collateral not posible because some chainlink price feed doesn't exist or are marked as medium risk by chainlink

Attacker can abuse the system by modifying the collateral of pending orders

Updating the maxFundingVelocity should update the funding rate as well

Deleting CollateralTypes from the CollateralLiquidationPriority allows traders to be liquidated for free and getting back their full collateral as if they were not liquidated.

Incompatibility with Multisig Wallets in `TempleGold::send` Function

Malicious user can prevent `rewardData.perodfinish` from ending by calling `TempleGoldStaking::distributeRewards()` before the end of the reward duration when no starter is set.

Incorrect Comparison Logic in Post-Operation Checks

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

incorrect price for negative ticks due to lack of rounding down

Vaults can become immune from liquidation by setting `vault.recipient` to a blacklisted quote token address

Availability of deposit invariant can be bypassed

Incorrect withdraw queue balance in TVL calculation

Withdrawals of rebasing tokens can lead to insolvency and unfair distribution of protocol reserves

Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps

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

stETH/ETH Feed being used opens up to 2 way deposit<->withdrawal arbitrage

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

Lack of slippage and deadline during withdraw and deposit

`BalancerConnector::_getPositionTVL` is calculated incorrectly

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

Base tokens accumulated from withdraw fees can't be transferred to/from the NoyaFeeReceiver and will remain stuck

`Keepers` does not implement EIP712 correctly on multiple occasions

Lack of Slippage Controls in retrieveTokensForWithdraw Function

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

Camelot and Aerodrome Connector TVL susceptible to manipulation attack

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

Design flaw and mismanagement in vault licensing leads to double counting in collateral ratios and positions collateralized entirely with kerosine

Kerosene collateral is not being moved on liquidation, exposing liquidators to loss

Unable to withdraw Kerosene from `vaultmanagerv2::withdraw` as it expects a `vault.oracle()` method which is missing in Kerosene vaults

`VaultManagerV2.sol::burnDyad` function is missing an `isDNftOwner` modifier, allowing a user to burn another user's minted DYAD

Attacker can frontrun to prevent vaults from being removed from the dNFT owner's position

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

Incorrect deployment / missing contract will break functionality

setUnboundedKerosineVault not called during deployment, causing reverts when querying for Kerosene value after adding it as a Kerosene vault

No incentive to liquidate when CR <= 1 as asset received < dyad burned

Liquidation bonus logic is wrong

Incorrect calculation of lending shares in `_withdrawOrAllocateSharesLiquidation` can lead to revert and failure to liquidate

The protocol allows borrowing small positions that can create bad debt

First depositor inflation attack in `PendlePowerFarmToken`

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

Wrong ProfitManager in GuildToken, will always revert for other types of gauges leading to bad debt

Users can deflate other markets Guild holders rewards by staking less priced token

Malicious borrower can decrease Guild holders reward

The price of rsEHT could be manipulated by the first staker

Possible arbitrage from Chainlink price discrepancy

Protocol mints less rsETH on deposit than intended

Setter functions for core GMX contracts

Wrong hardcoded PnL factor is used in all GMXVault add liquidity operations

Rebalance may occur due to wrong requirements check

Lack of events for critical actions

Wrong errors are used for reverts

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

Setting useRegistryAnchor to true will result in `recipientAddress` always be address(0) in RfpSimpleStrategy

`Allo.sol` feeAmount will round down to 0 when user calls `fundPool()` with small amount

Collateral amount will be inaccurate if the exchange rate goes up a lot

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

_curveSwap: getDpxEthPrice and getEthPrice is in wrong order

Malicious/Compromised organiser can reclaw all funds, stealing work from supporters

Centralization Risk for trusted organizers

DAI Tokens at Risk Due to Lack of address(0) Check in distribute

Missing Events

Tokens with less than 18 decimals allow for draining of funds

Lender contract can be drained by re-entrancy in `repay`

Lender contract can be drained by re-entrancy in `setPool`

Sandwich attack to steal all ERC-20 tokens in the Fees contract

Zero address leads to transaction reverts

Lender fails to giveLoan because of inconsistent length between `loadIds` and `poolIds`

Missing Events Emitting

`Staked` struct is created but never used

Move the Duplicate Checks into a Modifier

User can steal reward tokens if the Staking contract uses tokens with different decimals

Inconsistent formatting across all the contracts

Theft of collateral tokens with fewer than 18 decimals

Chainlink oracle will return the wrong price if the aggregator hits `minAnswer`

All of the USD pair price feeds doesn't have 8 decimals

Zero address check for tokens

Remove unused variables in `OracleLib`

Use constants instead of `type(uint256).max`