Technical Requirements

--- title: Technical Requirements order: 3 hideLanguageSelector: true keywords: "format, event, events, meetup, meetups, guide, agenda" description: "The technical requirements for proposing new collateral for the Maker Protocol." --- # Technical Requirements ## Technical requirements for evaluating new collateral 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. ## Technical Audit 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. ### Team The audit must be performed by highly skilled system security researchers. The audit can be purchased from third party services. ### Scope 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. ### Factors The audit should evaluate security factors including but not limited to: ### Overflow Checks <List> 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 </List> #### Audit Example 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”. #### Audit Results and Quality 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. ## Adapters 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. ### Contract Interface Every adapter contract has to implement two functions to let users deposit and withdraw tokens. Join lets token holders deposit tokens into the adapter contract and gain the same amount as an internal collateral balance at an address the user controls. Exit lets token holders redeem their internal collateral balance to token balance on an address in the token contract. ### Available Implementations #### ERC-20 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. ### Implementation Guidelines 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. ### Impact on Token Behavior 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. #### Transfer Restrictions 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. #### Usage Privileges 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. #### Locked tokens 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. ## On Security Tokens 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.