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

Anyone can manipulate user nonce (nonce_manager) in settlement contract

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

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

in `farmPlots()` an underflow in edge case leading to freeze of funds (NFT)

Players can gain more NFTs benefiting from that past remainder in subsequent locks

In `Voter.sol` the `vote()` function is using wrong if statement when checking the `_periodDuration`

`_notifyBribes()` will revert everytime because of wrong check in `BribeRewarder::_modify()`

There is no check for minimum staking duration in `MlumStaking.sol`

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

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

in `farmPlots()` an underflow in edge case leading to freeze of funds (NFT)

Players can gain more NFTs benefiting from that past remainder in subsequent locks

BalancerConnector has incorrect implementation of totalSupply, positionTVL and total TVL will be invalid

`BalancerConnector::_getPositionTVL` is calculated incorrectly

`AccountingManager::resetMiddle` will not behave as expected

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

In Dolomite, when opening a borrow position, the holding position in the Registry will never be updated due to the removePosition flag being set to true

Attacker can increase the length of `withdrawQueue` by withdrawing 0 amount of tokens frequently

`Keepers` does not implement EIP712 correctly on multiple occasions

First depositor can make subsequent depositor lose all of her or his deposit

Incorrect modifier condition

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

`depositQueue.queue` in `AccountingManager` can be flooded causing a DoS

Dust donation might DOS all connectors to create new holding positions, by preventing removing existing holding positions

LenderCommitmentGroup_Smart::addPrincipalToCommitmentGroup calculates `totalPrincipalTokensCommitted` wrong

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

OCL_ZVE::forwardYield executes removeLiquidity without slippage protection