Idle Governance

In `contracts\IdleController.sol`, the function `claimIdle` will loop through all the combinations of `holders` and `idleTokens` and pass into the function `distributeIdle`. However, in the function `distributeIdle` on `L119` will revert all the transactions that pass in any `supplier != idleToken`.

In `contracts\Idle.sol`, The function `_delegate()` invokes `_moveDelegates()` with the delegator's full balance instead of remaining undelegated balance. This can cause users to lose delegation ability if additional Idle tokens are acquired without minting (i.e., via transfers). Consider the following scenario: 1. Alice has `10` Idle , which is delegated to Bob. 2. Alice acquires `1` additional Idle from a transfer. 3. If Alice attempts to re-delegate her `11` Idle tokens to Carol, it will fail due to the `SafeMath` check on `L195`; effectively, the function will attempt to undelegate `11` tokens from Bob instead of `10`, and revert. In general, if Alice's balance is ever more than the number of tokens minted toward her account (due to transfers), she will not be able to delegate. This can be mitigated by Alice by simply transferring the excess tokens out of her account, however this scenario may not be clear to end-users from a UX-perspective.

For `contracts\Idle.sol`, `delegateBySig()` should validate the `v` and `s` parameters as in `ECDSA.sol` (See: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/2bb06b1af4d57cf47c700992b327a08bebf64879/contracts/cryptography/ECDSA.sol#L46).

Integer overflow/underflow occur when an integer hits its bit-size limit. Every integer has a set range; when that range is passed, the value loops back around. A clock is a good analogy: at 11:59, the minute hand goes to 0, not 60, because 59 is the largest possible minute. Integer overflow and underflow may cause many unexpected kinds of behavior and was the core reason for the `batchOverflow` attack. Here's an example with `uint8` variables, meaning unsigned integers with a range of `0..255`. ``` function under_over_flow() public { uint8 num_players = 0; num_players = num_players - 1; // 0 - 1 now equals 255! if (num_players == 255) { emit LogUnderflow(); // underflow occurred } uint8 jackpot = 255; jackpot = jackpot + 1; // 255 + 1 now equals 0! if (jackpot == 0) { emit LogOverflow(); // overflow occurred } } ``` In particular, for `contracts\PriceOracle.sol`, there is a potential underflow on `L70`: `... 10**(18-tokenDecimals) ...`. It is recommended to use `SafeMath` for this operation.

For `contracts\IdleController.sol`, the values inside the `priceOracle_` input parameter is not checked to be different from `0x0` inside the `_setPriceOracle` function.

For `contracts/PriceOracle.sol`, in function `getCompApr`, the computed pair will always return a result that has the last two digits as `0`, in `L58` due to division before multiplication `div(cTokenNAV).mul(100)`.