Naos-Formation

`Formation.sol`, `L661`: the price fetching function Chainlink API (`latestAnswer()`) has been declared deprecated by Chainlink and may be outdated. Furthermore, `latestAnswer()` was used but its return value `updatedAt` and `answeredInRound` are not checked, and therefore the data could be arbitrarily old.

A fresh address could invoke `forceTransmute()`, in which case the bookkeeping handled by `checkIfNewUser()` will be incorrect.

The documentation states that "A CDP is healthy if its collateralization ratio is greater than the global collateralization limit.". However, in `L59` of `CDP.sol`, it returns true if the ratio is equal as well.

If a user accidentally deposits to this contract instead of the expected `Formation` contract, they will not be credited for their funds.

The `constructor` sets `flushActivator = 100000 ether` with the added comment "change for non 18 digit tokens". It is not clear which tokens will be used, but if their decimal values are significantly different than 18, this amount will be too small or large.

1. The function `MultiSigWallet.getTransactionIds` iterates over the entire transaction history on L384, even though only transaction with indices in the range `[from, to)` are under consideration. If the wallet has a long transaction history, this may cause an unnecessary amount of storage load (`SLOAD`) operations, and the function may fail due to gas limits. Although the function is declared `view`, `web3` clients may not execute functions beyond the gas-limit, and external contracts may try to invoke the function. 2. `StakingPools._updatePools` could fail if too many pools are added.

`Formation.sol`, `L440` states that "This function reverts if an emergency exit is active.". The intended revert is not present. Considering this is present for emergency, the lack of this revert may allow the attacker to forcefully push funds into the external protocol. If the external protocol was vulnerable and under attack, this exposes the funds in Formation to the attack as well.

The TimeToken contract does not seem to be used in the system. It is also not present in the tests.

Some arguments in functions are not checked against zero. This leaves space for human-error and allows the arguments to be zero, which typically would simply revert, but in some cases it would result in transferring tokens to the `0x0` address and burning them. 1. `StakingPools.constructor` does not check that `_reward` is non-zero. 2. `StakingPools._token` does not check that `_token` is non-zero. 3. `Transmuter.constructor` does not check that `_NToken` and `_Token` are non-zero. 4. `Transmuter.setTransmutationPeriod` does not check that `newTransmutationPeriod` is non-zero. 5. `YearnVaultAdapter.constructor` should check that `_vault` and `_admin` are non-zero. 6. `Formation.constructor` should check that `_token` and `_xtoken` are non-zero.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.4.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".