User may lose funds when creating Nexus account or executing user operations

An attacker possesses the capability to exhaust the entirety of liquidity within the stable swap pools by manipulating the buy function, specifically by setting the asset_in parameter equal to the asset_out parameter

a huge loss of funds for all the users who try to remove liquidity after swapping got disabled at manipulated price .

complete liquidity removal will result in permanent disable of the liquidity addition and prevent minting shares for the liquidity providers .

``FULL_RESTRICTED`` Stakers can bypass restriction through approvals

```trancheTokenAmount``` should be rounded UP when proceeding to a withdrawal or previewing a withdrawal.

onlyCentrifugeChainOrigin() can't require msg.sender equal axelarGateway

allowing the transfer of ownership of the loans , which the callback is activated , to an EOA (externally owned account) will force the loan become default

malicious lender can force the borrower to pay a much more debt amount to take his collateral , otherwise the Lender force Loan become default

calling `claimDefault` function from the cooler contract of the clearingHouse loans will cause the `gOHM` tokens to be locked forever .

Blacklisted STADIUM_ADDRESS address cause fund stuck in the contract forever

If a winner is blacklisted on any of the tokens they can't receive their funds

Owner can incorrectly pull funds from contests not yet expired

Lack of checking the existence of the Proxy contract

Precision loss/Rounding to Zero in `_distribute()`

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

Using basis points for percentage is not precise enough for realistic use-cases

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

No expiration deadline leads to losing a lot of funds

Single-step process for critical ownership transfer is risky

Zero address leads to transaction reverts

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

Multiple accesses of a mapping/array should use a local variable cache.

+= and -= are more expensive

The `for loops` inside the borrow(), repay(), giveLoan() & startAuction() functions in Lender contract are probably gas-guzzlers

Uncheck Arithmetic where overflow/underflow impossible

Using Private Rather Than Public For Constants,Saves Gas

Use of magic numbers

For the borrow(), repay() & startAuction() functions in Lender.sol the public visibility modifiers should be changed to external, to help optimize gas usage

caching variable of struct in one slot

save storage slot

an important value does not been returned

Lack of events for critical actions

Precision loss when calculating the health factor

using x=x+y /x=x-y is more gas efficient than x+=y / x-=y

`++i`/`i++` should be `unchecked{++i}`/`unchecked{i++}` when it is not possible for them to overflow, as is the case when used in `for`- and `while`-loops

Constants should be be used for hardcoded values

Constructor of `Escrow` should make sure that `buyer`, `seller`, `arbiter` are different from each other.

Contract Can Be Deployed Without Funds.

Use predefined address instead of `address(this)`