Users might get less assets than expected upon migration due to price manipulation attacks

An attacker can steal all tokens of users that use `FeeWrapper`

REENTRANCY ATTACK POSSIBLE IF THE `_feeTo` IS A MALICIOUS CONTRACT IN `FeeWrapper._chargeFeePayable()` FUNCTION

RubiconMarket: buy() may not take any fee for tokens with low decimal precision

Zero reward rate calculation impedes low-decimals token distributions

First vault depositor can steal other's assets

Reentrancy abuse to reduce the minted management fees when changing an adapter

Owner can collect management fees with a new increased fee for previous time period.

Fee on transfer token not supported

Oracle data feed may return stale prices for tokens and ether

transfer() depends on gas consts

A VAULT OWNER CAN BE ALSO THE CONTROLLER AND ARBITRARILY SET THE SECONDARY MARKET ROYALTIES

A VAULT OWNER CAN FRONTRUN A PLUGIN CALL AND CHANGE ITS IMPLEMENTATION

ORACLE DATA FEED CAN BE OUTDATED YET USED ANYWAYS WHICH WILL IMPACT ON PAYMENT LOGIC

Put option sellers can prevent exercise by specifying zero amounts, or non-existant tokens

Unbounded loops may cause `exercise()`s and `withdraw()`s to fail

`fee` can change without the consent of users

Unsecure `transferFrom`

Accumulated ETH fees of InfinityExchange cannot be retrieved

Did Not Approve To Zero First Causing Certain Token Transfer To Fail

THE FIRST AMM STAKER WILL HAVE CONTROL OVER HOW THE SHARES ARE CALCULATED

THE FIRST AMM STAKER MAY NOT RECEIVE ACCORDING REWARDS BECAUSE OF POOR CHECKPOINTS