Growth Defi V1

1 Executive Summary

From November to December 2020, Consensys Diligence engaged with Growth DeFi to assess the security of the Growth DeFi v1 smart contracts: a set of tokens forming the backbone of the Growth Defi platform.

The assessment was conducted by John Mardlin and Alexander Wade, and took place over three calendar weeks: from November 23 to December 11, 2020. A total of 5 person-weeks were allocated over this period.

2 Scope

Our review concerned the files at commit 761f0a7af73a082ac64498061749db4466673542.

This assessment’s primary focus was to review code most pertinent to the function of the various Growth DeFi “gTokens.” Specifically, we reviewed the Type 0, Type 1, and Type 2 gToken smart contracts.

The following was out of scope:

• Type 3 gTokens and their dependencies
• Non-Solidity files
• The Growth DeFi webapp

Additionally, we deprioritized review of the contracts’ interactions with various DeFi protocols, including, but not limited to:

• AAVE
• Balancer
• Compound
• DyDx
• Sushiswap
• Uniswap

Rather than review the finer points of interaction with several of these external systems, we spent the majority of our time reviewing the inner workings of the various gTokens, as this represented the core of the Growth DeFi system.

3 Trust Model

In any system, it’s important to identify what trust is expected/required between various actors. This is particularly important given the anonymous nature of the developer team.

Users of the system must trust the administrators of the system with the following capabilities:

1. Determining which tokens are held in a given gToken and their corresponding percentages.
   1. This portfolio can be modified at any time: before or after a user’s deposits and withdrawals.
   2. An administrator could list “fake” type1 and type2 tokens which return false data regarding the balances of the underlying reserve.
2. Each gToken of type0, type1 and type2 manages a corresponding liquidity pool in a Balancer AMM. The administrator can initiate a withdrawal of all funds from this pool to an arbitrary address. After a 7-day waiting period, the migration and transfer of funds may be completed. Token holders will need to be vigilant for these events.
3. Setting an arbitrary exchange address, which normally would be used to sell the proceeds of staking and yield farming. This capability could be used to simply drain those funds.
4. Setting the collateralization ratio used for lending assets. This does not present an obvious opportunity for profit, but there is a risk that the gToken’s lending position could be liquidated due to mismanagement, or inactivity.

3.1 Actors

Whereas the previous section summarized the consequences of malicious or incompetent action by the administrators, this section presents an itemized list of the specific actions available to the administrators and users

Owner (administrator):

• Portfolio management:
• insertToken(): Add gTokens to the portfolio management token’s list of managed tokens
• removeToken(): Remove gTokens form the portfolio management token’s list of managed tokens
• transferTokenPercent(): Change the target percentage for each managed token
• setRebalanceMargins(): Modify the amount by which a token is allowed to deviate from its target percentage
• Pool management:
• allocatePool(): Initialize a gToken’s Balancer liquidity pool and associate it with the gToken contract
• setLiquidityPoolBurningRate(): Allows the Owner to set the Balancer liquidity pool burning rate. This rate is a percent of the gToken’s held BPool tokens that can be burned via GTokenBase.burnLiquidityPortion. The rate set may be any value between 0 and 2e16, representing 0-2%.
• burnLiquidityPoolPortion(): Allows the Owner to exit the gToken from its associated Balancer pool for a certain percentage of held BPool tokens, burning any received funds. The exit amount is a percentage of held pool tokens given by the gToken’s burning rate.
• initiateLiquidityPoolMigration(): Allows the Owner to initiate a migration of assets held in the gToken’s associated Balancer pool to an arbitrary address. The migration may be cancelled by the Owner at any time, and can only be completed after a period of 7 days passes.
• cancelLiquidityPoolMigration(): Allows the Owner to cancel a pending pool migration once it has been initiated.
• completeLiquidityPoolMigration(): Allows the Owner to complete the Balancer pool migration process. The gToken exits its associated pool with the entirety of its BPool tokens. The received GRO and gTokens are then transferred to the migration recipient specified by the Owner at migration initiation.
• Yield farming management:
  • setExchange(): setting the exchange address used to convert yield farming assets (COMP and DAI) to the underlying asset
  • setCollateralizationRatio(): Adjust percent allocation of the reserve token between two managed tokens
  • setBurningRate(): Set the burn rate for each gToken
  • setMiningGulpRange(): Set the minimum and maximum amount of the mining token to be converted
  • setRebalanceMargins(): Set margins for acceptable deviation from the PMT’s percent allocation before triggering a rebalance action

User:

• deposit()/depositUnderlying(): Can deposit their gTokens into the Growth protocol
• withdraw()/withdrawUnderlying(): Can withdraw their gTokens from the Growth protocol

4 Action Items

Our assessment determined that significant improvement was needed in the following areas:

4.1 Increase overall quality and quantity of testing

Many individual components of Growth DeFi v1 are covered by unit tests, and a stress-testing system exists to simulate random interaction with the protocol. However, the system lacks comprehensive integration and scenario testing.

The existing unit tests are incomplete, and do not cover many important functions and features of the contracts. Some of the contracts not covered by unit tests include, but are not limited to:

• GLiquidityPoolManager.sol
• GPortfolioReserveManager.sol
• GADelegatedReserveManager.sol (note that GCDelegatedReserveManager has tests)
• Flashloans.sol
• SushiswapExchangeAbstraction.sol
• UniswapV2ExchangeAbstraction.sol

However, unit tests alone are not sufficient. Especially for a highly-configurable system like Growth DeFi, comprehensive integration testing is needed to ensure that each individually-tested component works as expected with other components. Integration testing should include the inner workings of each gToken, but should also extend to the system’s interaction with external protocols (like DEXes, Flashloan providers, and other DeFi protocols).

Finally, the highly-complex nature of Growth DeFi demands a complementary battery of scenario tests. Scenario tests describe complete sequences of events in your system, and are often replete with interactions from multiple simulated actors. As an example, one scenario test for a gToken may begin with contract initialization, simulate multiple users depositing, simulate multiple users withdrawing, and end with the contract drained of all assets.

Note that this differs from the existing random stress tests: rather than simulating random actions, scenario tests should simulate specific sequences of actions that are likely to occur during regular use of the system.

Recommendation

Implementing a robust, complete test suite requires significant effort and careful consideration outside of the scope of this review.

In general, write tests that encapsulate the specification. Tests should address each of a system’s requirements. A system’s requirements should be clearly defined within the system design specification. Ensure that the Growth DeFi test suite accurately reflects the most up-to-date specification and includes checks for all of the requirements mentioned therein.

4.2 Improve system documentation and create a complete technical specification

A system’s design specification and supporting documentation should be almost as important as the sytem’s implementation itself.

• Users rely on high-level documentation to understand the big picture of how a system works. Without spending time and effort to create palatable documentation, a user’s only resource is the code itself, something the vast majority of users cannot understand.
• Security assessments depend on a complete technical specification to understand the specifics of how a system works. When a behavior is not specified (or is specified incorrectly), security assessments must base their knowledge in assumptions, leading to less effective review.
• Maintaining and updating code relies on supporting documentation to know why the system is implemented in a specific way. If code maintainers cannot reference documentation, they must rely on memory or assistance to make high-quality changes.

Currently, the only documentation for Growth DeFi is a single README file, as well as code comments. While significant effort has been invested into the latter, this system’s documentation should be considered incomplete until both high-level and low-level descriptions for its behavior exist outside of the codebase itself.

4.3 Ensure system states, roles, and permissions are sufficiently restrictive

Smart contract code should strive to be strict. Strict code behaves predictably, is easier to maintain, and increases a system’s ability to handle nonideal conditions.

Our assessment of Growth DeFi found that many of its states, roles, and permissions are loosely defined:

• Growth DeFi’s Owner role assigns complete control over a bulk of important system configuration to a single account. This control includes, but is not limited to:
  • Managing Type 0 gToken assets under management, by inserting and removing assets at any time.
  • Rebalancing Type 0 gToken asset percent distribution
  • Changing the exchange contract used by Type 1 and Type 2 gcTokens
• The specific permissions given to the Owner role suggest that future plans to transition this role to a DAO-governed multisig have not been well thought through. In its current configuration, it would be incredibly difficult to transition the management of the Owner’s extensive permissions to a DAO-governed multisig.
  • One example of this is the occasional “burn” feature of each gToken. Once per week, each gToken burns a portion of the funds it holds in its associated Balancer liquidity pool, decreasing the supply of the assets contained within. This function can only be called by the Owner, and can only be called once every 7 days. This means that every 7 days, one signature per gToken must be collected from each signer on the Owner multisig. Because there are 34 planned gTokens, each signer must commit to providing at least 34 signatures per week.
• Most contracts contain logic that allows the contract to operate on multiple chains (Mainnet, as well as Kovan, Rinkeby, etc)
• Most contracts can be interacted with by users, even if the contract has not been fully initialized, or is in a semi-configured state. For example:
  • All contracts can be interacted with, even if their Balancer liquidity pool has not been created/finalized yet.
  • GADelegatedReserveManager.adjustReserve allows users to perform deposits/withdrawals, even if no valid exchange has been set by the Owner.
• Contracts that use flash loans will attempt to use DyDx. If this operation fails, the contracts will attempt to use AAVE, instead.

Recommendation

• Document the use of administrator permissions. For users to know what they can expect from Growth DeFi, the administrator’s roles and responsibilities should be clearly and completely documented and communicated.
• Monitor the usage of administrator permissions. To ensure the Owner key’s operations are not compromised in some way, monitor transactions and events in Growth DeFi for Owner actions.
• Specify strict operation requirements for each contract. Define and implement a strict initialization state. If Owner actions may cause the contracts to deviate from this state (for example, by removing the “exchange” in a gcToken), determine and document whether users may still interact with the contracts, and if so, what altered behavior they should expect.

5 Recommendations

_underlyingCost = G.min(_underlyingCost, GC.getLendAmount(reserveToken));

library G
{
	function min(uint256 _amount1, uint256 _amount2) public pure returns (uint256 _minAmount) { return Math._min(_amount1, _amount2); }

function _getFlashLoanLiquidity(address _token) internal view returns (uint256 _liquidityAmount)
{
	uint256 _liquidityAmountDydx = 0;
	if ($.NETWORK == $.Network.Mainnet || $.NETWORK == $.Network.Kovan) {
		_liquidityAmountDydx = DydxFlashLoanAbstraction._getFlashLoanLiquidity(_token);
	}
	uint256 _liquidityAmountAave = 0;
	if ($.NETWORK == $.Network.Mainnet || $.NETWORK == $.Network.Ropsten || $.NETWORK == $.Network.Kovan) {
		_liquidityAmountAave = AaveFlashLoanAbstraction._getFlashLoanLiquidity(_token);
	}
	return Math._max(_liquidityAmountDydx, _liquidityAmountAave);
}

6 Findings

Each issue has an assigned severity:

• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Critical issues are directly exploitable security vulnerabilities that need to be fixed.

uint256 _numMarkets = SoloMargin(_solo).getNumMarkets();
for (uint256 _i = 0; _i < _numMarkets; _i++) {
	address _address = SoloMargin(_solo).getMarketTokenAddress(_i);
	if (_address == _token) {
		_marketId = _i;
		break;
	}
}

Appendix 1 - Disclosure

ConsenSys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via ConsenSys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any Third-Party in any respect, including regarding the bugfree nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any Third-Party by virtue of publishing these Reports.

PURPOSE OF REPORTS The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond Solidity that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) – on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

LINKS TO OTHER WEB SITES FROM THIS WEB SITE You may, through hypertext or other computer links, gain access to web sites operated by persons other than ConsenSys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that ConsenSys and CD are not responsible for the content or operation of such Web sites, and that ConsenSys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that ConsenSys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. ConsenSys and CD assumes no responsibility for the use of third party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

TIMELINESS OF CONTENT The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice. Unless indicated otherwise, by ConsenSys and CD.