[Template] Proposal for managing Gearbox Protocol Parameters

This template describes all the parameters that must be defined to create new Pool, integrate Pool with new DeFi Protocols and/or add new Tokens to the AllowedToken List. This template also can be used to change any of the described below parameters. This is standard across XYZ Improvement Proposals.

PS. This template works for Gearbox Protocol v 1.0 contracts.

Please note that per the rules of the current governance setup, an idea should first go through #main regular discussion to see temperature check, after which a proposal can be made in the #proposals section. For more information, please see the following short post:

Abstract & Motivation

In this section, please describe the purpose of an asset pool, how it can be used and by whom. If the proposal suggests changing any parameters of the pool or/and credit manager, please provide the motivation for changes.

Then, the proposals differ depending on the nature of the change.

Proposal type: Allowed Contracts

Users can interact through Credit Accounts only with contracts from this list to mitigate risks that funds will be sent to vulnerable smart contracts. So it is necessary to provide information for any protocol that should be integrated with pool:

  • Protocol Name
  • Protocol Website
  • Protocol Audit
  • Adapter Audit
  • Protocol Adapter (these are specially designed smart contracts which provide the same api like original protocol, but use funds from credit account, more details you can find here

** Existing audits cover implementation of adapters for Uniswap V2 AMM (and any AMM that supports IUniswapV2Router02 interface), Uniswap V3, Curve 3pool, and Yearn V2.

Proposal type: Allowed Tokens

This allows managing risks of swapping funds to highly-volatile assets whose price could drastically fall after a swap and before a liquidation would take place. Another attack vector is a user creating some dummy ERC20 and then buying it - thus essentially draining capital from Gearbox Protocol.

Each token from allowed tokens list should have Liquidation Threshold. Liquidation Threshold is the constant showing the maximum allowable ratio of Loan-To-Value in terms of underlying asset.

What restrictions for listing tokens does the protocol have?

  • (required) the token should be open-source and audited.
  • (required) the token must have a Chainlink Price Feed. A list of current feeds can be found here.
  • (required) the token must be liquid enough so that there is no domino effect in the event of a liquidation
  • (preferably) token is unpausable and doesn’t have methods for black-listing addresses eligible to transfer token
  • fee-on-transfer and rebasing tokens may not work correctly

Proposal type: Pools

Proposal subtype: new pool

ERC20 token address

Link to etherscan or any other block explorer for pool token

Token source code

Link to github or any other source code

Audit of token

Link to audit report or any other evidence of audit.

Proposal subtype: Interest rate model for pools

Borrow rate for pools is calculated by formula described in docs. It is a standard model many lending protocols use. It is necessary to provide 4 parameters to define this model:

  • Optimal Utilization ratio value
  • Minimal borrow rate R_0
  • Borrow rate at optimal utilization ratio R_1
  • Maximal borrow rate R_2

Proposal subtype: Pool Caps

Launching any new pool is always a risky experiment. To limit the scope of the experiment, the pool has the following parameters:

  • Pool max limit defines maximum available deposited amount.
  • Withdrawal fee is temporarily implemented so that there is no liquidity crisis with a small pool. More details are here.

and special smart-contract called Credit Managers connected to the pool has parameters:

  • Min collateral size defines minimum amount of funds available at start in Credit Account
  • Max personal borrow amount defines maximum amount of funds available at start in Credit Account
  • Max leverage defines max leverage size available for Credit Account

Proposal type: other parameters

There are also parameters that define Gearbox DAO fee structure, liquidation parameters etc. Below is the list of such parameters:

  • APY spread fee going to DAO Treasury.
  • Fee Liquidation going to DAO Treasury when Credit Account is liquidated
  • Liquidation Discount represents discount for liquidator
  • Default swap protocol represents where funds from Credit Account will be swapped to underlying asset when user wants to close Credit Account.
  • Chi Threshold and Health Factor Check are special constants for a simplified check of the collateralization ratio during financial operations with Credit Account. Details are provided [here]([special constants for a simplified check of the collateralization of a credit account. Details are provided here.