Rounding Issues In Certain Functions

fCash of the wrong maturity and asset can be sent to wrapper address before wrapper is deployed

DOS set token through erc777 hook

`IsWrappedFcash` check is a gas bomb

hard-coded slippage may freeze user funds during market turbulence

Title: Yield can be unfairly divided because of MEV/Just-in-time stablecoin deposits

Wrong calculation of excess depositToken allows stream creator to retrieve `depositTokenFlashloanFeeAmount`, which may cause fund loss to users

set cap breaks vault's Balance

`Vault.withdraw` mixes normalized and standard amounts

Vault treats all tokens exactly the same that creates (huge) arbitrage opportunities.

Controller does not raise an error when there's insufficient liquidity

No safety check in addToken

removeToken would break the vault/protocol.

An attacker can steal funds from multi-token vaults

earn results in decreasing share price

ERC20 return values not checked

# Controller is vulnerable to sandwich attack

calculate Loss is vulnerable to flashloan attack

Attacker can get extremely cheap synth by front-running create Pool

User may not receive the full amount of IL compensation

The first lp provider can destroy the pool

add liquidity is vulnerable to sandwich attack

Can not update target price

Ideal balance is not calculated correctly when providing imbalanced liquidity

`customPrecisionMultipliers` would be rounded to zero and break the pool

Get virtual price is not monotonically increasing

Stop ramp target price would create huge arbitrage space.

Approved spender can spend too many tokens

hard to clear balance

registerAsset() can overwrite _assetClass value

treasury is vulnerable to sandwich attack

Changing NFT contract in the MochiEngine would break the protocol

feePool is vulnerable to sandwich attack.

Vault fails to track debt correctly that leads to bad debt

A malicious user can potentially escape liquidation by creating a dust amount position and trigger the liquidation by themself

regerralFeePool is vulnerable to MEV searcher

anyone can create a vault by directly calling the factory

reward tokens could get lost due to rounding down

Validator can fail to receive commission reward in `redeemAllRewards`

Reentrancy in settleAuction(): malicious publisher can bypass index timelock mechanism, inject malicious index, and rug the basket

Unsafe approve would halt the auction and burn the bond

settleAuction may be impossible if locked at a wrong time.

No minimum rate in the auction may break the protocol under network failure

set cap breaks vault's Balance

`Vault.withdraw` mixes normalized and standard amounts

Vault treats all tokens exactly the same that creates (huge) arbitrage opportunities.

Controller does not raise an error when there's insufficient liquidity

No safety check in addToken

removeToken would break the vault/protocol.

An attacker can steal funds from multi-token vaults

earn results in decreasing share price

ERC20 return values not checked

# Controller is vulnerable to sandwich attack

Wrong aave usage of `claimRewards`

latestMarket used where marketIndex should have been used

`redeemToken` can fail for certain tokens

[Bug] A critical bug in bps function

arbitrary synth mint/burn from pool

Pool.sol & Synth.sol: Failing Max Value Allowance

Hijack token pool by burning liquidity token

Synth `realise` is vulnerable to flash loan attacks

Misuse of AMM model on minting Synth (resubmit to add more detail)

wrong `calcLiquidityHoldings` that leads to dead fund in the Pool

Result of transfer / transferFrom not checked

Vulnerable Pool initial rate.

safeTransferFrom in TransferHelper is not safeTransferFrom