Asset Listing Briefer

General Discussions
#1

Asset Listings

The Interest Protocol asset onboarding process requires zero input from the GFX Labs team or any key individual. Anyone controlling a sufficient number of votes can make an onchain proposal. All onchain proposals that pass governance will be automatically implemented after a short timelock.

The protocol is designed to be compatible with a diverse range of assets. Standard ERC20 tokens, governance tokens, rebasing tokens like stETH, LP tokens, and even fee-on-transfer tokens can be added as collateral assets.

The protocol has two primary collateral types: Capped Collaterals and Standard Collaterals. Capped Collaterals are assets with a global cap on the number of tokens the protocol will take as collateral. By limiting the number of tokens used as collateral, the protocol can significantly manage its risk to any particular asset and thus support a greater breadth of assets. Standard Collaterals have no cap.

To date, the protocol supports a small number of assets: wETH, stETH, wBTC, UNI, and MATIC. There are many other assets IPT holders can consider adding as collateral. GFX Labs would like to provide some thoughts from our experience at Compound and MakerDAO, and from our expertise with Interest Protocol.

Before we get into the fundamentals of supporting an asset as collateral, let’s cover the requirements for adding a collateral asset to Interest Protocol.

Technical points

Here are the requirements for a standard asset:

  • Token address
  • LTV (loan-to-value): Between 0% and 100%, minus the liquidation incentive.
  • Oracle address: The AnchoredViewRelay (a composite of the primary oracle and the secondary oracle)
  • Liquidation incentive: Between 0% and 100%

If it is Capped Collateral

  • Cap: The number of tokens to allow as collateral

Note that these parameters are set through governance proposals and can be changed by subsequent proposals.

A critical part of every asset listing is the oracle setup. Interest Protocol runs off a read-based oracle system. Meaning prices are called through basic read functions, and the oracle contracts act as a conduit to get an asset’s price and format it to the protocol’s standard.

Each asset has three contracts that make up its oracle system:

  1. The Anchored View Relay
  2. A primary oracle relay
  3. A secondary oracle relay

The Anchored View Relay reads the primary oracle relay for the price and the secondary oracle relay’s price. If the primary and secondary oracle prices are within the deviation parameters configured on the Anchored View Relay, then the primary’s price is used to mark the collateral’s value. If the primary’s price is outside the deviation range, the price is not used, and the transaction will fail, effectively freezing the market. For more information on the oracle system: link.

The proposer for the asset listing is welcome to use this flexible oracle design however they would like. While the existing collateral assets use Chainlink Oracles as the primary and Uniswap v3 as the secondary (exception is stETH which uses a custom curve implementation), proposers can implement additional adapters to other DEXs and oracles. So long there is a primary and secondary source, it will work (subject to a governance vote).

To see what has been done in the past, check out the deployed contracts page and the protocol parameters page.

If you’re proposing a Capped Collateral asset, there are a few additional steps.

  1. Deploy the capped token contract
  2. Set the initial cap
  3. Transfer ownership of the cap token to the governor contract
  4. Deploy the three oracle contracts
  5. (Governance) Register the underlying on the voting vault controller contract
  6. (Governance) Register the capped token on the vault controller contract

Fundamentals of asset listing

1st rule of a borrow/lend protocol is not to become an exchange. It should never be in someone’s financial interest to deposit a collateral asset, borrow a good asset, and walk away from their collateral. It must always make more sense for the token holder to sell their holdings on the open market. If a user walks away from their collateral, the loan will likely be underwater. As risk is identified, the protocol should act quickly to mitigate the risk.

Now that we have the main point, we can break the listing process into two sections: Technical & Liquidity.

Technical risks

The quality of the collateral is heavily influenced by its traits. For example, wETH would be considered the highest grade of quality. The contract is a standard ERC20 token; the underlying asset is ETH which the contract has been around for a long time and secured substantial funds.

  1. Type of contract: Standard ERC20 or other?
  2. Underlying asset: Wrapped token, LP asset, governance token, other?
  3. Time: How long has the contract been in use?
  4. Value: How much value has the contract secured, or how much could be exploited?
  5. Privileges: Is there an owner or admin? Could the underlying asset be transferred? Could more tokens be minted? Is there a timelock?
  6. Upgradability: Is the contract upgradable?

We would consider wETH to be the highest quality collateral

  1. Type of contract: Standard ERC20 token
  2. Underlying asset: ETH
  3. Time: +4 years
  4. Value: Billions
  5. Privileges: None
  6. Upgradability: None

No matter how good liquidity is for an asset, it should not be a collateral asset if it cannot appropriately address those five points. Assets with substantial liquidity but unable to meet those points are a significant risk to the protocol.

Liquidity risks

If an address can meet the five key technical points, the discussion regarding using a collateral cap or going the uncapped route can happen. The capped approach will be the best method for most assets unless the asset is a top token like ETH.

When assessing liquidity, four are four venues to think of:

  1. DEX liquidity (Uniswap, Balancer, Curve, etc.)
  2. CEX spot liquidity (Binance, FTX, Coinbase, etc.)
  3. CEX derivatives liquidity (perpetuals, futures, etc.)
  4. OTC/Market markets/other (assets like wBTC have notable private liquidity)

DEX liquidity is ideal because it is easily accessible. Some sophisticated liquidators will lean on CEX spot liquidity for liquidations. Although not much discussed in crypto, derivative markets for assets will also play a role in asset liquidity. Lastly, private market activity affects an asset’s liquidity profile. For example, if the price of wBTC/BTC begins to part significantly from 1:1, the market can expect someone to take advantage of the price difference by minting/burning wBTC directly.

The proposer should consider each of these variables and estimate the liquidity available for the asset.

In addition to assessing the market liquidity available for liquidation, the proposer should examine the historical volatility of the asset. Assets that fluctuate significantly possess additional risk.

Lastly, compare the available liquidity to the circulating market cap of the asset.

Ultimately this is a subjective process. The proposer and IPT holders should gather as much data as possible, but the final decision for the Collateral Cap, LTV, and liquidation penalty will be subjective. When in doubt, choose the conservative option knowing it is easier to increase the parameters than to lower them once a collateral has been accepted.

The Proposal

While the protocol does not require proposers to discuss or document their proposals on the forum or Discord, it is best practice to post the proposal on the forum and solicit feedback before proceeding with the governance proposal. The proposer will likely find the forum and Discord helpful mediums to gather the votes necessary to pass the proposal.

A few things to consider:

  1. Collateral Caps can be lowered to limit collateral growth within the protocol without liquidating existing users.
  2. Large borrowers tend to prefer high LTVs and are willing to deal with high liquidation penalties because they are confident in managing their risk.
  3. The protocol can support positive rebasing tokens like stETH. Negative rebasing tokens should not be considered for collateral; if they are, they should be considered with great care.
  4. For a governance token to retain its voting power, it must follow one of the following standards: Gov Alpha, Gov Bravo, OpenZepplin Gov, or Aave Gov. The protocol needs an interface with a delegate function that takes a single address as the input.
  5. Failed proposals are healthy. Protocols should have a higher number of proposals, including plenty of proposals that fail.
1 Like