wrong calculation of amount of Ltokens to seize in liquidateCrossChain function

malicious liquidator can get collateral tokens of borrower in chainA even if he doesn't pay repay tokens in chainB

DOS of _handleLiquidationSuccess function due to using incorrect underlying address as input of lendStorage.findCrossChainCollateral function

DOS of _handleLiquidationSuccess function due to using currentEId as input in lendStorage.findCrossChainCollateral function instead of using srcEid of chain which trigger execution of _handleLiquidationSuccess in this chain

DOS of _handleLiquidationSuccess function due to using payload.srcToken as input in lendStorage.findCrossChainCollateral function instead of using corresponding borrowed token of chain A

removing a ltoken from userBorrowedAssets will out properly checking weather he still has any borrows of this token

incorrect update of user borrowed assets

incorrect calculation of totalBorrowed amount of user

Incorrect calculation of total user borrowed assets due to incorrect check in borrowWithInterest function

wrong check in coreRouter::Borrow function allows users to borrow even if they don't have sufficient collateral

unfair liquidation due to incorrect calculation of borrowed funds

incorrect distribution of Lend tokens to users

user can't borrow even if he has sufficient collateral due to wrong calculation of collateral of user

liquidation will revert due to incorrect calculation of maxClose value

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

bad debt is not accounted for during partial liquidation of an insolvent position

Tiers of users surrounding Tier2-Tier3 boundary were not updated correctly if a new user stakes when total users in tiering system is in form of 10N+4.

Tiers of users surrounding Tier2-Tier3 boundary were not updated correctly if a staker in Tier 3 of tiering system unstakes when total users in tiering system is in form of 10N+5

The calculation of `totalAssets()` could be wrong if `operatorFeeAmount` > 0, this can cause potential loss for the new depositors

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

transferReserveToAuction function will always reverts

malicious users can DOS the auction functionality

attacker can drain contract funds by creating->cancelling->modifying orders in Bracket contract

Attacker can drain contract funds by creating 2 orders in same block with different Input amounts(1st small amountIn 2nd with larger amountIn

attacker can drain StopLimit contract funds through Bracket contract because it gives type(uint256).max allowance to bracket contract for input token in performUpkeep function

users funds loss and/or transaction reverts due to out of funds in ReputationMarket contract

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

[H-01] Miscalculation in `_farmPlots` function could lead to a user unable to unstake all NFTs