Document version 20190709
- Introduction
- Risk parameters
- Governance Approval
- Process Overview
- Technical requirements
- Adapters
- On Security Tokens
- Legal Requirements
- Financial Requirements
- Application Form
The target audience for this document is:
- Organizations and individuals that want to propose collateral types to be added to the MakerDAO Dai Credit System
- Risk teams that want to create risk parameters for new collateral in the MakerDAO Governance Process
- Others interested in the MakerDAO governance process
The purpose of this document is to guide you in the process of enabling a new token as collateral in the Dai Credit System (DCS).
The document introduces the suggested information that a Maker Governance Risk Team need to calculate collateral risk parameters and create a governance proposal for adding new collateral to the system.
Types of collateral tokens may include:
- Native crypto coins such as bitcoin or ether
- Security tokens such as company shares or bonds
- Real estate tokens
- Commodity tokens such as gold
- Intellectual property tokens such as patents
- Digital property tokens such as items from gaming or virtual worlds
Enabling a token to be used as collateral in DCS allows any token owner to lock up tokens in a Collateral Debt Position and generate Dai stablecoins against this position. Additionally, it contributes to the scalability of Dai by increasing the amount of available financial backing.
NOTE: This document contains guidance and checklists that will require approval in an MKR Governance poll. This hasn’t yet happened at the time of writing, so there may be changes to the process described here.
Further, this document shall be considered a living document that is adjusted as more experience is gained in adding collateral to the system, and new knowledge is available. For example, currently, how to add Security Tokens to the system isn’t addressed in any detail. The plan is to add this in a later version.
Each type of collateral in DCS is associated with its own set of risk parameters. The risk parameters may be influenced by both the financial and technical characteristics of the collateral token. The parameters include:
- Stability fee When Dai is generated by a Collateralized Debt Position (CDP), a stability fee accrues continuously. When the Dai is returned, the accrued stability fee must be paid on top. A share of the fee goes to pay the Dai Savings Rate to Dai holders. Another share of the fee goes to buy and burn MKR tokens to compensate MKR token holders for committing to backstop the DCS in case of a black swan event.
- Liquidation ratio The liquidation ratio is the minimum ratio between the value of the collateral in the CDP and the value of Dai drawn from the CDP. For instance, if the ratio is 150%, the CDP will be liquidated if there is 100 Dai drawn and the value of the collateral drops below $150.
- Liquidation penalty In the event of CDP liquidation, a penalty is paid by the CDP owner used to buy and burn MKR tokens.
- Debt ceiling A system wide limit on the amount of Dai that can be drawn against a specific type of collateral.
These risk parameters are calculated by a risk team using information provided by the proposer of the collateral. As the MakerDAO Governance process gradually is decentralized, the aim is to have a multitude of independent risk teams, that can calculate risk parameters and ask the MKR governors (MKR token holders) to approve the addition of collateral to the system.
By default, all tokens have a debt ceiling of 0. Before a token can be used as collateral it must be accepted through the governance process controlled by MKR token holders.
Introduction of new collateral types is handled in a two-step process. First, there is a Governance poll where the MKR governors reach consensus – potentially among different competing proposals – about which risk parameters a new collateral type shall have. Following the poll, there is an Executive vote that contains the actual changes and additions to the system that are needed. This vote is handled as approval voting in a continuous voting process. Once MKR token holders have indicated support for a set of parameters, the system will continue to see MKR token holder support for those parameters until they actively change their vote. To introduce new collateral, a new set of parameters must thus gain support from a larger amount of MKR than any other set. This can be achieved both by activating new votes from MKR tokens that have not voted before and by convincing existing voters to change their support.
Anyone can propose a new set of parameters to the executive voting process. However, to convince MKR token holders to support the new proposal, one must engage the community with detailed technical and financial specifications, audits, and scientifically informed reasoning for the chosen set of risk parameters.
This document describes – pending MKR holder approval – the information you shall submit to have a risk team create a proposal to the MKR governance community on your behalf.
The following figure describes the recommended high-level process for having a risk team vet a token being proposed as collateral, and put it forward for a MKR holder vote if deemed suitable.
It is assumed, the risk team includes or has access to the following set of roles:
- INT: a technical integration role, that can verify the technical information provided
- RISK: the risk function
- LEGAL: a legal role, that can verify any legal information submitted.
This section describes which technical information to provide to a risk team. This guidance hasn’t yet been approved by MKR holders as a template for risk teams to use, so be aware that there may be changes to this section.
For a risk team to create a new governance proposal on your behalf, you must have highly skilled system security professionals conduct a technical security audit of your token contract(s) and submit the resulting audit report as part of the application.
The audit must be performed by highly skilled system security researchers. The audit can be purchased from third party services.
The scope of the audit must include any smart contracts that provide functionality to your token including but not limited to transfers, freezes, whitelists, blacklists, transaction approvals/rejections, authorizations, upgradability, etc.
The audit should evaluate security factors including but not limited to:
- Overflow checks
- Complexity, including inheritance layers and whether external contracts are called
- Whether deprecated functions are used
- Whether SafeMath functions are defined and used
- Whether formal verification has already been performed or can easily be performed
For an example of what an audit report may look like, you can view Trail of Bits’ audit of the test version of single collateral Dai known as “Sai”.
It is at the sole discretion of the risk team to determine whether the result, depth, and quality of the conducted audit meets the standards for that risk team to determine risk parameters and submit a governance proposal on your behalf.
DCS accepts diverse token types as collateral in a standardized way through token adapters. Each token, once authorized as collateral, gets its own individual adapter contract, which custodies tokens and gives depositors a collateral balance. Users can use this balance within DCS to open a CDP and draw Dai. Keepers participating in collateral auctions can also convert their collateral to a token balance using the adapter contract. In this section, we will explain the functionality of adapters in detail and help you identify a suitable adapter for your token.
Every adapter contract has to implement two functions to let users deposit and withdraw tokens.
Joinlets token holders deposit tokens into the adapter contract and gain the same amount as an internal collateral balance at an address the user controls.Exitlets token holders redeem their internal collateral balance to token balance on an address in the token contract.
GemJoin is a standard adapter implementation suitable for accepting an ERC-20 token with simple transfer mechanics as collateral. This adapter cannot be used if your token allows token balances of holders to change without their explicit approval using a signed transaction, for ex: assessment of demurrage fees on token holders.
If available standard adapters cannot be used for your token, a new adapter has to be created to accept it as collateral. If you don’t have the skills to develop a new adapter, the Maker Foundation Integration team may be able to help you identify a suitable development partner. New adapter implementations must go through a technical audit before they can be approved for use.
We’ve listed a few possible side effects on your token when connected to an adapter for use as collateral within DCS. This list is not exhaustive, and we suggest you perform a review with the technical role in the risk team that you are working with to ensure there are no unintended consequences after an adapter is live for your token.
DCS does not impose transfer restrictions on internal collateral balances of users. Please review the effects this could have on your token if the token imposes any kind of transfer restrictions internally on user balances either by default or under certain scenarios.
Tokens held in adapter contracts are restricted from being used in their protocols because the ability to draw Dai while using them could have unintended side effects on both DCS and the protocol itself.
Adapter contracts do not take the current debt ceiling of the collateral type into consideration when allowing token deposits. Thus, a large number of tokens could be locked within adapter contracts even when they are not being used to draw Dai.
If the token is a regulated security token, additional considerations must be made.
Guidance for Security Tokens is planned to be added in a later version of this document.
This section describes which legal information to provide to a risk team. This guidance hasn’t yet been approved by MKR holders as a template for risk teams to use, so be aware that there may be changes to this section.
Legal assessment constitutes one of the central steps in the collateral onboarding process. You will see legal questions in the application form below. The list of questions is not exhaustive, so the process, in many cases, will involve iterative conversations with a person/entity promoting onboarding of the token and/or other relevant actors. Very often, the legal structure of a given token will be novel, and the MKR governance must fully understand it in order to make an educated decision regarding token onboarding and related risk parameters.
In general, the legal analysis will aim at determining the below factors:
- Legal risks associated with the token and its role as an available collateral type;
- Regulatory consequences (if any) of onboarding the token for both the particular constituencies involved (e.g., holders, CDP users, Keepers, other intermediaries, etc.) and for DCS.
This section describes which financial information to provide to a risk team. This guidance hasn’t yet been approved by MKR holders as a template for risk teams to use, so be aware that there may be changes to this section.
As part of the risk evaluation, a risk team must conduct a due diligence process. We request that you provide the following information to help facilitate this process:
Broadly speaking, collateral assets can be separated into two categories: crypto-native assets and Security Tokens. Crypto-native assets (often referred to as ‘bearer’ assets) are coins such as bitcoin and ether that have no counterparty risk. Possession of the token is equivalent to direct ownership of the asset. Conversely, ‘registered’ assets, such as tokenized securities, are merely claims or receipts on an underlying asset. These tokens require a recourse analysis, the process by which a token can be redeemed for the underlying asset. Specific information may be requested depending on the classification of the collateral asset.
You must provide a short summary of your project. In particular, please distinguish between the business sector (i.e., decentralized exchange, prediction market, payments platform, etc.) and the token use case (i.e., utility token, work token, governance token, etc.). You must submit all relevant documentation, including, but not limited to, whitepapers, pitch decks, and roadmaps. We also recommend submitting financial information, such as budgets, burn rates, runways, and treasury management overviews.
For bearer assets, describe the nature of the issuance. If there was an ICO, please disclose the date, raise amount, valuation, ICO price, and token distribution. Details regarding seed investors, lockups and circulating supply are also recommended.
Please present a detailed trading profile, including, but not limited to, exchange listings, liquidity providers, and so on. Liquidity is an important aspect that directly influences a Keeper’s ability and willingness to purchase collateral in a liquidation auction. Favorable liquidity conditions result in a lower Liquidation Ratio and higher Debt Ceiling.
Please provide links to primary communication platforms (e.g. email, Telegram, discord, reddit, etc.) on which you can be reached. All information requested herein, including documents, must be provided via email.
This form summarizes the information to submit to a risk team to request that it review your material and propose a set of risk parameters to MKR governance. All information requested herein, including documents, must be provided via email. If the risk team finds that the material is sufficient, all submitted information will be made publicly available along with the related proposed risk parameters in order to permit MKR governance to make a fully informed decision.
This form hasn’t yet been approved by MKR holders as a template for risk teams to use, so be aware that there may be changes to this section.
- What is the token contract address?
- Where can the source code be viewed? Please provide links to the source code for all contracts providing functionality to the token, including, but not limited to, transfers, freezes, whitelists, blacklists, transaction approvals/rejections, authorizations, upgradability, etc.
- Which token standard does your token comply with?
- Does the token have any special mechanics for handling forks? This may include forks in the token app or in the underlying blockchain.
- If yes, please provide a reference to more information on fork handling.
- My token fits with the following Dai Credit System adapter:
- GemJoin
- I will supply my own adapter contract. Input reference below.
- Has the token passed formal verification?
- If yes:
- Please describe the specification.
- Who composed the specification?
- Please provide a link to the result of the verification.
- If yes:
- Technical audit
- Upload audit report created by qualified research personnel.
- Please provide a short summary of your project.
- Please list the founding members.
- What type of crypto asset is it (utility, work, governance, etc)?
- If native crypto asset, which category (utility, work, governance, etc)?
- What is the token’s usage in the project? How is the token utilized?
- What was the date of the ICO?
- What was the initial price and valuation?
- How much capital was raised (in USD and crypto terms)?
- What was the token distribution breakdown?
- Are any tokens on a vesting schedule? If so, what is that schedule? Describe any related vestiture limitations.
- What are the circulating and total supply of the token?
- What is the wallet address of the treasury?
- How much of the ICO raise was converted into fiat (described in both terms of that fiat currency and the amount of tokens?
- Were there any pre-ICO seed investors? Who and what were their respective allocations?
- Please link to the whitepaper and/or pitch deck related to the token.
- Please link to the most updated roadmap for your project.
- How many employees and contractors does your project have?
- What is the monthly burn rate?
- What is the strategy for treasury management?
- Which exchanges is your token listed on?
- Are you aware of any paid market makers for your asset?
- Does your token have custodial support? Where/with whom? Please provide a copy of the custodial agreement if available.
- Please link your email, Telegram, subreddit, Discord, Twitter, Medium.
- What is the website of your project?
- Who is the token issuer (if any)?
- Do you have legal representation related (1) to the issuance of the token, (2) regulatory requirements regarding the token, or (3) otherwise? If so, whom?
- What is the regulatory status of the token? Please provide relevant documentation (e.g., legal opinions, prospectuses, public disclosures, filing documents, etc.).
- Are there any rights associated with the token that do not follow from its technical implementation or technical ramifications of the system in which the token is used? If so, what are they? How are they enforced? Please provide documentation memorializing these rights.
- In what jurisdiction(s) was the token issued?? Please provide all filings and public documents related to the token’s issuance.
- Was the token issued as part of a regulatory process (e.g., securities offering)? If so, under which law, rule and/or regulation was the token issued? Please provide all documents related to this regulatory issuance process (to the extent not already provided in response to the above).
- Was the token issued as part of the fundraising process for your project? If yes, who are the investors and how much equity do they respectively hold?
- Please describe the corporate and legal structure of the project/system/product in which the token is used.