PAIRING_CHECK_GAS_LIMIT hardcoding causes KeyRegistry and Settlement to not work on zksync

Functions such as getOperators may revert because the gas reaches the gas limit.

The getOperatorVotingPower function does not check if the vault is registered and may return incorrect data.

There could be a slight drop in the price of wstETH, leading to more money for user redeem and ultimately undercollateralization

There is no reset accrued in the claimLend function, resulting in users being able to reclaim rewards repeatedly

In the supply function, not using the latest exchangeRate results in an error in the protocol ledger

The protocol was unable to transfer USDT because of the wrong interface.

Incorrect Borrowing Capacity Calculation Leading to Denial of Service for Borrowing

Users may not be able to call the unstake function, resulting in a lockup of funds

Vertex calculates the vault fee for closure, but the final fee is not borne by the user, which will cause the attacker to make the liquidity provider lose all of their funds

In the addValueSingle function, there is an error in the order in which taxes are assigned, which will result in a partial loss of the tax that the user gets.

There is a problem with the internal call order of removeValue/removeValueSingle, which will cause liquidity providers to lose their profits.

The value of each closure is not the same, and the same ValueToken cannot be used for all cids

Using initializer Modifier Prevents Child Contract initialize Function from Being Called

_resetVestingPlans Function’s amount Check Prevents Adjusting Vesting Plans

Reward Vesting Time Can Be Extended Indefinitely by Small Deposits

feeRecipient Address Cannot Be Assigned, Causing 100% Fee Loss

Incorrect tickUpper in collectFees Causes Revert, Disabling Core Protocol Functions

Withdrawal Failure in Leverager.withdraw() Due to Incorrect Repayment Calculation

Users can claim more that their actual allotment

Incorrect listing type validation bypasses enforcement of minimum purchase amount

Incorrect referral fee calculations

Rounding error in stepDuration calculations.

Underflow in `claimable` DOSing `claim` Function

The _getUnlockingPercentage function will always return 2000 due to a precision miscalculation, which will result in the user having to suffer an 80% penalty.

When calculating in the _getUnlockingPercentage function, 540 was mistakenly used instead of 540 days for calculation. As a result, users can unlock all their funds earlier without paying penalties.

Gas griefing/attack via creating the proposals

Malicious actors can manipulate the `cross_chain_callback` callback

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

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

The lack of check conditions leads to the loss of contract functions.

Since the status parameter is not used, this will result in the owner being unable to set the permission of any address to false.

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

When `LockManager.lockOnBehalf` is called from `MigrationManager`, the user's `reminder` will be set to 0, resulting in fewer received `MunchableNFTs`

Incorrect Comparison Logic in Post-Operation Checks

Vultisig should be burnable

Malicious users can bypass the blacklist.

Malicious User can call `lockOnBehalf` repeatedly extend a users `unlockTime`, removing their ability to withdraw previously locked tokens

Single plot can be occupied by multiple renters

Failure to Update Dirty Flag in transferToUnoccupiedPlot Prevents Reward Accumulation On Valid Plot

When `LockManager.lockOnBehalf` is called from `MigrationManager`, the user's `reminder` will be set to 0, resulting in fewer received `MunchableNFTs`

Funds may not be withdrawn due to a check error

The _stake function in the PufETHAdapter contract will revert

Wrong checking causes the swapETHForYt function to revert with a high probability

In the RsETHAdapter contract, _stake may revert

Incorrect calculations can result in user losses

An attacker can extend the user's reward release time

Division may cause a lot of reward tokens to be locked in the contract

_totalSupply update errors will cause user reward calculation errors.

claimRewards may fail to execute

Adding liquidity may fail

Users can make the protocol issue more rewards through flash loans. And these rewards can be claimed through slippage.

Funds locked due to missing transfer check

Epoch not increasing may cause the protocol to get stuck

Failure of user withdrawal may cause the rebalance function to get stuck.

The deposit may fail due to precision issues.

When borrowers repay USDS, it is sent to the wrong address, allowing anyone to burn Protocol Owned Liquidity and build bad debt for USDS

Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST

Impossible to change managed wallets with `proposeWallets` after first rejection

getBunniTokenPrice function calculation error

Wrong function used to get totalSupply

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