Idle Finance

Quantstamp23 Apr 2021Files named in the report

Audit

Quantstamp reviewed Idle Finance on 23 Apr 2021: 39 findings, 0 critical; 22 marked fixed, 14 acknowledged, 3 open.

No open critical findings

Open the report Open Idle Finance’s security record

Report hosted on certificate.quantstamp.com.

Trustblock does not review code.

Findings39

Statuses are the security firm’s own, from its report.

Severity	Open	Acknowledged	Fixed
Critical	0	0	0
High	0	0	0
Medium	1	0	3
Low	2	14	19

LowAllowance Double-Spend ExploitAcknowledged

As it presently is constructed, the contract is vulnerable to the [allowance double-spend exploit](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/b4f87bb8fc25fb07f73099701e39e167a3d36465/contracts/token/ERC20/ERC20.sol#L71-L78), as with other ERC20 tokens.

LowFlashloan could be used as a tool to manipulate liquidities of the underlying lending protocolsAcknowledged

The `flashLoan` can be used to force triggering the rebalance process and moving funds in and out different underlying protocols. A related security issue is described in [EIP-3156](https://eips.ethereum.org/EIPS/eip-3156#flash-minting-external-security-considerations).

LowFlashloans may decrease funds if underlying protocols have redemption feesAcknowledged

The function `flashLoan` can be used to force triggering the rebalance process and move funds in and out different underlying protocols. If any of the underlying lending protocols have a redemption fee, an attacker who seeks to damage IdleFinance can achieve this by rapidly performing large value flashloans that cause IdleFinance to redeem and mint the underlying protocol’s tokens and end up losing money.

LowIncorrect hardcoded addressesAcknowledged

1. The address of the Idle governance token is hardcoded to `0x0001` on L85. 2. The address of the `oracle` is hardcoded to `0x0001` on L111. 3. The address of the `idleController` is hardcoded to `0x0001` on L112. 4. The following address seems to be an EOA, not a smart contract L131: `rebalancer = address(0xB3C8e5534F0063545CBbb7Ce86854Bf42dB8872B);` 5. The address of the `iToken` is hardcoded to `address(0)` on L130 and there is no setter function to change the `iToken` address.

LowInitialization can be done multiple timesAcknowledged

The owner of the `IdleTokenV3_1.sol` could call `manualInitialize` multiple times. This would reset several state variables. The semantics of the function name gives the impression that it should only be called once.

LowMissing address sanitizationAcknowledged

The values inside the `_newGovTokens` array input parameter are not checked to be different from `0x0` inside the `setGovTokens` function.

LowMissing input checkAcknowledged

1. The `manualInitialize` function does not check if the length of the 2nd, 3rd and 4th input arrays is the same. The `for`-loop inside this function assumes the length of `_protocolTokens`, `_wrappers` and `_lastRebalancerAllocations` input arrays is the same. 2. A comment on L105 indicates that the `_newGovTokens` array "should include IDLE". However, this is not verified inside the function. It could be verified by setting a binary flag to true inside the `if`-statement on `L124: if (newGov == IDLE) { continue; }`, and then checking this flag after the `for`-loop using a `require` statement.

LowMissing return valueAcknowledged

The `getGovApr` function does not have an explicit return value for the cases where the `if`-statement is not entered, i.e. the `if`-condition is not `true`.

LowPrivileged rolesAcknowledged

The owner of the `IdleTokenV3_1` contract has the right to change the following state variables at any time, they can even front-run end-users: 1. `setAllAvailableTokensAndWrappers` can be set to any address including EOAs 2. `setGovTokens` can be set to any address including EOAs 3. `setRebalancer` can be set to any address including an EOA 4. `setFee` upper bounded by 10% 5. `setMaxUnlentPerc` upper bounded to 100% 6. `setFeeAddress` can be set to any address including an EOA 7. `setOracleAddress` can be set to any address including an EOA 8. `setIdleControllerAddress` can be set to any address including an EOA 9. `setIsRiskAdjusted` 10. `setAllocations` this can also be done by the `rebalancer` address

LowPrivileged Roles and OwnershipAcknowledged

Smart contracts will often have `owner` variables to designate the person with special privileges to make modifications to the smart contract. Within `IdleRebalancerV3_1`, the owner can perform the following actions: 1. Can set the idle token exactly once via `setIdleToken` 1. Can set the rebalance manager address any number of times via `setRebalanceManager` 1. Can add any number of new tokens via `setNewToken` 1. Another role enforced by `onlyRebalancerAndIdle` modifier, which allows the rebalance manager or idle token to set completely new token allocations, for exactly the same token addresses, that sum up to 100% (any number of times). The `IdleTokenV3_1.sol` contract contains the following privileged actions: 1. Modify the `allAvailableTokens` array any number of times 1. Set the address of the `iToken` any number of times 1. Set the governance token address `govTokens` any number of times 1. Set the rebalancer address any number of times 1. Set the fee taken from end users any number of times to any value lower or equal to 10% 1. Set the maximum unlent asset percentage to any value lower than 100% 1. Set the fee address any number of times.

Show 4 more

LowSecurity of Idle contracts is dependent on underlying lending protocolsAcknowledged

Although there is no immediate exploit known at this time, since protocol wrappers can be added arbitrarily in the future, this issue could occur, and further unforeseen issues could arise in the existing underlying protocols.

LowUnchecked function argumentsAcknowledged

The function `_init` should ensure that `_tokenHelper` is non-zero.

LowUninitialized inherited contracts and state variablesAcknowledged

The `initialize` method has been replaced with the `manualInitialize` method, which is significantly different: 1. There are several inherited contracts which were initialized in the `initialize`, but are not initialized in the `manualyInitialize` method. The following code snippet indicates the initialization of these contracts, which was removed: ``` // Initialize inherited contracts ERC20Detailed.initialize(_name, _symbol, 18); Ownable.initialize(msg.sender); Pausable.initialize(msg.sender); ReentrancyGuard.initialize(); GST2ConsumerV2.initialize(); ``` 2. Similarly, the following state variables: `token`, `tokenDecimals`, `cToken` and `maxUnlentPerc`, were initialized in the `initialize` method, but are not initialized in the `manualyInitialize` method.

LowUninitialized state variablesAcknowledged

Several important state variables: `token`, `tokenDecimals`, and `isRiskAdjusted`, are not initialized anywhere.