[Template] Collateral Proposal

[PaperImperium]

Please use this template as a reference for making a collateral onboarding proposal for Interest Protocol. It is acceptable to post a proposal without all information filled out, but as much information as possible will facilitate a healthier discussion and feedback early in the proposal process.

Notes:

• Capped collaterals have a maximum debt ceiling. This limits the protocol’s exposure to that asset. Uncapped collaterals do not have a debt ceiling. Capped collateral is probably appropriate for most collaterals unless liquidity is extremely deep or the asset considered to be low risk. The capped token address is a smart contract Interest Protocol uses to “wrap” the raw collateral as a means of enforcing the cap.

• LTV is “loan to value” and represents the maximum amount of USDi that can be generated by a user against the market value of a collateral asset. Higher LTVs are generally riskier than lower LTVs. Higher LTVs are generally more desirable to users. Balancing this tension is a key part of your proposal.

• Liquidation incentive is expressed as a percentage (%) discount when liquidating this collateral. This is the discount given to a liquidator to encourage them to repay USDi to a user’s vault. Higher discounts are generally appropriate when slippage is likely for liquidators.

• Oracles: Interest Protocol utilizes two oracles on every collateral. There is a primary oracle (often Chainlink when available), as well as a secondary oracle that is used to “double-check” the primary oracle. Only the primary oracle is used for the protocol’s internal accounting, but a secondary oracle needs to be available for a collateral. It is acceptable to put TBD for oracle addresses while a proposal is still soliciting feedback and discussion. Price deviation is the amount of deviation allowed between the primary and secondary oracle before a market is frozen.

• Liquidity: Please list any pools that provide significant liquidity. Contract addresses are recommended to avoid confusion. Liquidity should also break down total supply and circulating supply, with a reference or explanation for how circulating supply was calculated.

• Volatility should be expressed in terms of token vs ETH. This table is an example. Data beyond 90 days is optional.
  

  

• Technical risks should include descriptions of the token’s specs, permissions, utility, upgradeability, and any technical ideosyncracies.

• Supplemental information is a section for any additional information the applicant wishes to be considered in support of the application. Information on the issuer of a token, evidence of demand to leverage the proposed asset, and data-based arguments for the LTV and maximum cap proposed are all encouraged.

Proposal to add XXX

Proposal to add XXX as a [capped or uncapped] collateral to Interest Protocol.

Overview

[Insert an overview of the token, its issuer, any uses for the token or value that accrues to it, and any other relevant information]

Parameters

Token Address:
Capped Token address:
LTV:
Liquidation incentive:
Maximum Cap:
Oracle Address:
Primary oracle:
Secondary oracle:
Price deviation:

Liquidity

Market Cap:
Liquidity:
Volatility:
Coingecko 7-day avg 24hr volume:
Notable exchanges:

Technical risks

1. Type of contract:
2. Underlying asset:
3. Time:
4. Value:
5. Privileges:
6. Upgradability:

Supplemental Information

Relevant References