The path to launch and first proposals

The path to launch and first proposals

DAO-First, DAO-First, DAO-First… What does it mean? It means that initial members aka ex-core team — give the raw code to the community who then decide how to start the protocol. That is: deciding on pools and assets, allowed contracts, multisig signers, and everything else! That’s what we are going to talk about.

If you want technical specifications in a concise manner or want to know how to make a proposal for your protocol or asset to be in allowed-policy of Gearbox Protocol by DAO voting, you can jump in the forum template proposal. In the first weeks, it’s likely better to only have the major protocols and assets — and then expand as per risk policies and practices Gearbox DAO adopts.

[Template] Proposal for managing Gearbox Protocol Parameters
Section has moved to Discord forum: 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 sta…
Gearbox Governanceapeir99n

It’s obvious that we can’t code a complicated machine, and then say you could turn it into a toaster. Well, you could, but it’d be kinda dumb. However, you can decide what the machine does though: driving in the countryside or in the city, having fancy disks or not, having high speed or being extra safe.

The DAO must decide this, and while “we” have a good understanding of the machine so far — we can only guide the DAO on a path it chooses (the important factor here being that the ex-core team does not get to dictate).

DAO-First Launch - Gearbox Protocol
The path to decentralization and community governance from summer 2021.
Gearbox Protocol

In this docs section, you can see all the stages leading up to the protocol launch, whereas the deployment period takes almost a week. One of the final steps is to decide on protocol parameters, which must all be posted on the forum and then voted for on a snapshot. And yes, this requires quorum being met and multisig signing this all. This will happen in a couple of days!

So, what things are there to propose and vote on? We suggest splitting the proposals into 3–4 votes max, to not exhaust governance right away. Later on, every individual piece should be carefully voted on one-by-one.

[GIP-1] Voting for Liquidity Pools

Asset Pools as Liquidity Providers

The architecture of Gearbox Protocol allows for the creation of liquidity pools, which are later on used by Credit Accounts. This is where leverage users source their extra liquidity. You can essentially see it as lending capital. Gearbox Protocol does not impose funding rates, which you pay when opening positions on CEXes. Only regular borrowing rates are paid by leverage takers. The fees from borrowing accrue to the pools.

It’s common for users to trade against major assets being ETH or WBTC, as well as stablecoins. It’s important to note that lending in Gearbox works kind of like isolated lending yet not fully, meaning that if you put 10 ETH as collateral for opening leverage — you can only take more in ETH. The same way for liquidity providers who supply this capital — their interest is in ETH. All the positions opened in ETH as collateral are denominated to ETH in health factor calculations.

We would suggest using only the major tokens, because the protocol will have barely any TVL (due to TVL caps — see below). This way, the max leverage possible to take will also be higher as the potential slippage is lower.

The DAO can later on add new assets, similar to how you see these procedures on MakerDAO or Aave. While there are many assets which qualify for having large liquidity and being suitable, fragmenting liquidity very early is not an optimal solution. And there are multiple reasons for that:

  • As the protocol will be early in its life, giving users too many choices might leave them confused and they will have poor experience with the product;
  • More pools makes the protocol too complex at the start, etc.

Interest curve parameters

Parameters for supplying and borrowing should be established. These parameters can later on be changed by the DAO.

Pool Caps

While the protocol will be early in its stage, it will be incredibly risky to interact with it. As such, we suggest starting off with caps on pools and then gradually increasing them. This way, it essentially becomes a “test in prod” model where rates can be observed, user behavior, PMF, and so on.

As you could guess, this naturally imposes a cap on the amount of leverage one account could take. Also keep in mind that in these conditions, due to the cap being in place, borrowing rates can fluctuate a lot. Be careful in case you are worried about high interest rates!

We believe the DAO should gradually increase the pool cap size to make sure borrowers are not always at the top of the utilization curve.

  • Pool max limit.
  • Personal max borrow amount.
  • Max leverage amount.
  • Withdrawal Fee. Withdrawal fees on the LP side are not considered to be a sustainable source of protocol revenue as it creates conflict of interest between the protocols and its LPs. Yearn has previously moved away from this model. In the future, governance can either implement a performance fee or some other mechanism in order to best align interests. Because Gearbox Protocol has TVL caps in place, lack of liquidity can create discrepancies in borrowing APY and thus degrade the experience for traders and farmers. Withdrawal fees are in place and shall be removed by governance in a few weeks (as we would think it would make sense). This is not the source of protocol revenue, it’s simply there as a backstop against system turbulence in the first weeks post-launch.

Other parameters

Architectural note: some of these parameters refer to Credit Managers, and not inherently to pools. As such, technically speaking, these are different proposals for different modules. However, at the start with only 4 Credit Managers being the same — it seems easier to bundle the proposal in one. In the future, such things should be decided and voted on separately.

Allowed List Policy

Operations available to leverage users are restricted by two policies:

  • Allowed tokens list. 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 on, let’s say Uniswap — and essentially draining capital from Gearbox Protocol.
  • Allowed contracts list. Users can interact through Credit Accounts only with contracts from this list to mitigate risks that funds will be sent to vulnerable smart contracts.

Both policies are managed by governance and can grow to enable more assets and protocol. As you can imagine, those two are also essential pieces of Gearbox Protocol architecture.

Credit Account - Gearbox Protocol
DeFi Primitive for composable leverage 2.0
Gearbox Protocol

[GIP-2] Voting for Allowed Tokens

The DAO should choose the first batch of tokens which can be used for trading and making composable strategies with. For now, the protocol only supports ERC20 tokens, however, conceptually speaking:

it could support options, derivatives, Uniswap LP tokens, and more in the future if the DAO decides to.

The ERC20 tokens chosen criteria:

  • (preferably) not possible to pause tokens fully or freeze individually;
  • (preferably) fee-on-transfer and rebase tokens to be avoided;
  • (preferably) the token must be liquid and have big depth on the secondary markets, specifically DEXes. This is one of the protections against the domino effect;
  • (required) there must be a chainlink price feed oracle for the token. As you might have guessed, this is the oracle system Gearbox Protocol uses on Ethereum and in its current version. See the price feeds here — https://docs.chain.link/docs/ethereum-addresses/

Calculating a liquidation threshold per token added must be done as well. This is to ensure the correct liquidation parameters. See the docs.

[GIP-3] Voting for Allowed Contracts

Just having tokens in the allowed list doesn’t achieve much, because you can’t do anything with them unless you have a list of contracts with which you and they can interact with. But first, let’s dive into something interesting:

Gearbox Protocol architecture is made both for gas-efficient use as well as easy integrations. We value composability, so this is essential! As such, to integrate a protocol into Gearbox Protocol — only a simple Credit Adapter should be built for some per each protocol added. It’s an incredibly easy process, and it makes composability possible in the future.

Currently, four adapters have passed 2 audits:

Technical Specification

The audits will be published next week, but please keep in mind this does not guarantee safety as Gearbox is a risky protocol! Check here for risks.

Please discuss, see the template, and make proposals! Make sure to chat on Discord first - to get guidance on how to create a proposal in the most comprehensive way possible. Let’s not flood the forum with 100 token proposals at first, because they should adhere to basic security principles.

[Template] Proposal for managing Gearbox Protocol Parameters
Section has moved to Discord forum: 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 sta…
Gearbox Governanceapeir99n
JOIN DISCORD