Defining a process to add new collateral

Following recommendation from Doug Leonard here:

This is a discussion that will help define a process for adding new collateral types into the Hifi lending protocol. Such process shall be defined as a set of steps and rules to follow. The outcomes of this discussion might require one or many votes, if needed. In those cases, separate proposals shall be created.

For a good start, let’s share and describe the collateral onboarding process from meaningful projects. Doug has suggested different sources to begin with, in the url above. Time to get your voice heard!

The best way to contribute here is to reference sources projects and making a bullet-point description of their processes. Put your best glasses on and let’s dig in. Help Hifi have the best collateral onboarding process out there.


There are some examples of how other protocols do their process so we could get a better understanding of what we can discuss and improve.


Overview of the MakerDAO governance model

Information below was taken from various sources and explained using my own words. I try to stay as precise as possible, but some errors or incomplete information might happen. Help me improve this by replying to this post. Thank you!

MakerDAO has a powerful model of governance, and was referenced by @doug and @Josue as being a great example to be inspired from. This can help design Hifi’s own governance model and processes.

Information taken from BANKLESS Podcast

Episode from April 2nd (7:04) - The Bull Case for MKR

MakerDAO is the OG of governance: The maker protocol is extremely hardened […] and operated by one of the most experienced DAOs in existence making sure that your collateral is safe.

Different “groups” part of the DAO

  • Core units: They are the main workforce of the DAO, doing protocol engineering, maintenance and building smart contracts for the protocol

  • Protocol mandated actors: Elected people that runs the day to day operations of the protocol

  • Core unit facilitators: Various tasks like planning and running weekly meetings

  • Delegates for voting

  • Token holders

What makes maker unique and special […] comes from a perspective that is adversarial.
We try to think about every little thing that could go wrong, and try to have as little direct human control or authority as possible.

Developers don’t have special knobs or switches to activate or deactivate stuff. This is completely controlled by token holders and governance, and this is quite rare in Defy especially. […] Most DeFi protocols wants to keep a bit of centralized practices at the beginning to innovate and scale quickly, but then, they never become fully decentralized.

Some specifics of MakerDAO:

  • Mission focused community: A common goal of having a reliable system. They attracts special group of people not looking just for quick gains.

  • Talent retention: Ability for maker to retain the same talent it had years ago. People who commits for the protocol are in for the long term. Having experienced people is powerful.

Speculative aspect:

  • MKR token price […] the market can only remain irrational for so long, after building so hard for so long. However, the community has adapted to the low price of MKR. Profits made by the system and DAI are diverted to MKR token holders.

Information taken from MakerDAO Whitepaper

  • Everyone (not only MKR holders) can submit proposals.

  • Governance security module (GSM) can delay as much as 24 hours a voter approved modification to governance variables. the GSM gives MKR holders opportunity to protect the system if necessary against malicious governance proposals, by triggering a shutdown.

  • The process includes “proposal polling” to get a rough consensus of community sentiment, before executing and “Executive voting”. This ensures governance decisions are considered thoughtfully before vote.

  • An example of an Executive Vote could be a vote to ratify Risk Parameters for a newly accepted collateral type.

  • MKR token also has secondary utility, for recapitalization of the maker protocol. If system debt exceeds the surplus, MKR token supply can increase through a debt auction to recapitalize the system. It’s a risk that helps holders to align responsibly to avoid excessive risk taking.

MKR holders can vote to do the following:

  • Add a​ ​new​ ​collateral asset ​type with a unique set of Risk Parameters.
  • Change the Risk Parameters of one or more existing collateral asset types, or add new Risk Parameters to one or more existing collateral asset types.
  • Modify​ ​the Dai Savings Rate.
  • Choose the set of Oracle Feeds.
  • Choose the set of Emergency Oracles.
  • Trigger Emergency Shutdown.
  • Upgrade the system.

MKR holders can also allocate funds from the Maker Buffer to pay for various infrastructure needs and services, including Oracle infrastructure and collateral risk management research. The funds in the Maker Buffer are revenues from Stability Fees, Liquidation Fees, and other income streams.

Also, MakerDAO Governance is designed to be flexible and upgradeable.

Risk parameters (risk profile of collateral) controlled through voting:

  • Debt Ceiling
  • Stability Fee
  • Liquidation Ratio
  • Liquidation Penalty
  • Collateral Auction Duration
  • Auction Bid Duration
  • Auction Step Size

Risk and mitigation responsibilities

  • Malicious attach of the smart contract infrastructure by a bad actor
  • Black Swan event
  • Unforeseen pricing errors and market irrationality
  • User abandonment for less complicated solutions
  • Dissolution of Maker Foundation
  • General issues with Experimental Technology

Price stability mechanism

  • Dai target price
  • emergency shutdown

For more details about each specific mitigation processes, please checkout the MakerDAO whitepaper URL above.


You’ve given us a great summary of MakerDAO to start comparing with other protocols and DAOs and to define the Hifi Protocol’s unique and secure process.
We are now discussing the need for a mitigation process to be merged into the process of adding new types of collateral, which is another topic for discussion, and then a proposal will be made and put to a vote.


I have had the opportunity to look into Compound, and here are the bullet points I took away from it:

  • You don’t have to vote yourself on proposals with COMP, you can delegate your votes to a third party (it’s a form of liquid democracy)
  • You need 100K COMP in order to create a proposal
  • You need 100 COMP in order to create an “autonomous proposal”. An autonomous proposal is a proposal which requires that COMP holders delegate collectively at least 100K COMP. If the 100K delegation threshold is reached, the proposal becomes active. Once active, COMP holders can vote on the proposal like normally.
  • Proposals are executable code, not suggestions for a team or foundation to implement.
  • If a majority, and at least 400,000 votes (a bit more than 5% of the circulating supply) are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.
  • The Compound DAO pays entities such as OpenZeppelin and Gauntlet to perform risk analysis reports and audits.

For those interested, the following blog posts are great reads:


Awesome! I have a draft for AAVE’s model incoming soon :ok_hand:


Overview of the AAVE governance model and risk management


Information below was taken from various sources and explained using my own words. I try to stay as precise as possible, but some errors or incomplete information might happen. Help me improve this by replying to this post. Thank you!

AAVE is a successful liquidity protocol that runs using a decentralized governance model that has proven safe and efficient over the years. This is another model that has been suggested by Hifi admin team members for reference, to help define a governance model for building a process to add new collateral.

AAVE has well documented risk management. They define four main risk factors for DeFi borrowing protocol:

  1. Security Risk
  2. Governance Risk
  3. Oracle Risk
  4. Market Risk

According to them, there are four primary sources of market risks worth mentioning:

  1. Extreme downward price movement
  2. Asset illiquidity and liquidator inaction
  3. Cascading liquidations
  4. Slashing of safety module

A feature they have to test the risks are simulated stress tests.

Adding assets

To add assets, AAVE follows a specific process that is well documented. The selection of assets is done within some constraints:

  1. Each additional currency will slightly increase the gas cost of the borrow and redeem actions permanently.
  2. Each currency added to Aave protocol as collateral increases the protocol risk of insolvency.
  3. A centralised currency accepted as collateral exposes the protocol to its centralisation risk.
  4. Currencies only enabled for depositing and borrowing (not usable as collaterals) present lower risk for the protocol.
  5. Having volume from different currencies in our lending pools reduces risks via diversification benefits.

AAVE also considers ensuring that there’s more value than risk when adding a new currency. Only projects with worthy products and significant community are considered.

Here’s an overview of their onboarding process for a new currency:

  1. Proposing assets via ARC process (AAVE request for comment)
    1.1 Risk analysis (smart contract review and analysis of constrains listed above)
    1.2 Parameter suggestion (Sharing risks parameters and interest rate curves with the community)
    1.3 Community sentiment (Multichain snapshot with low cost / gasless voting about risk parameter preferences, parametrisation, etc.)

  2. Preliminary AIP Steps (AAVE Improvement proposal)

  3. Check for Chainlink price feed

  4. Prepare the payloads (contract creation from templates)

  5. Submission of proposal

Learn more from AAVE’s official documentation below. They are worth a look, as they provide great visuals for understanding.

Governance architecture: Governance - Aavenomics
Governance Policies: Policies - Aavenomics
Safety module: Safety Module - Aavenomics
New asset listing: New Asset Listing - Governance
Template for asset onboarding: Template ARC Asset Onboarding - Governance

ARCs and AIPs

AAVE suggest creating a ARC (Aave Request for Comments) as the first step in governance. Anyone can participate. This process can require having a rough concensus by creating a simple poll in snapshot. Source: ARCs - Governance

Then, AAVE suggest creating AIPs (Aave Improvement Proposal) which is the actual proposal, and requires having sufficient proposition power. The AIPs are resource heavy. Details here: AIPs - Governance


Some information gathering from the governance processes of is coming next!


Using Doug’s comments from another thread, which helped to spawn this topic/ discussion & posted in an effort to keep to the task at hand:

What do we like and don’t like between their approaches (Maker, AAVE, Compound)?
How do we build a process that allows us to will avoid opinion and bag wars?

‘Each new collateral we add completely changes the risk profile for lenders and LPs. What would drive away potential lenders vs. what will attract them and how to balance those tradeoffs?’

1 Like

We could simply mirror MKR, AAVE & Compound collectively, lol! For instance, if a collateral is listed on all three exchanges – then we consider the collateral, based off the fact that the collateral type is on all three of those exchanges. It may seem simple, though isn’t that the approach we are taking with governance? – to re-use techniques, versus reinventing the wheel.


What would the implications of doing that be? Are there any other options? Do you think speaking about TVL would be useful?

I find that this is quite a good idea @Hollywood41
I really agree that we should not reinvent the wheel.

So, since Hifi have its own specifics, I believe that it still need it’s own process, even if heavily inspired from others. But then, part of the process could actually be to list platforms (that we trust) that also use the collateral in study.

By documenting a list of ‘trusted’ platforms, starting with Maker, AAVE, Compound, Euler, (etc), Hifi can also use them to survey the status of collaterals on the long term.

For example: Let’s say I want to list token ‘XYZ’ as collateral in Hifi:

  • Part of the onboarding process to the protocol, we provide the list of “trusted” platforms that also supports collateral XYZ,
  • Then, we can track the status of XYZ on the trusted platforms. If we ever find that one or many platforms stops supporting the XYZ collateral, it might raise a red flag for Hifi to review that collateral for suspension.
1 Like

Overview of the Euler Finance governance model for onboarding collateral

Onboarding process for new collateral is pretty simple. Euler let users list any assets, as long as they are a supported WETH pair on Uniswap.

However, Euler uses an asset tier system, to manage risk from the permissionless listing.
Tiers works as follow:

  • Isolation-tier:
    Provides ordinary lending and borrowing, but cannot be used as collateral to borrow other assets. For example, if you provide USDC as collateral to borrow token XYZ, you can only borrow XYZ with your current account. To borrow something else, you would need a separate account, thus the isolation.

  • Cross-tier:
    Like isolation-tier, it provides ordinary lending and borrowing, but cannot be used as collateral to borrow other assets. However, they can borrow multiple tokens like XYZ and ABC with the same acocunt.

  • Collateral-tier:
    Provides all features (lending, borrowing, and also used as collateral).

EUL holders can vote through governance to promote tokens from Isolation-tier to Cross-tier and Collateral-tier.


And also in removing tokens; if Maker or any of these other protocols we were to select end up removing a token; or pausing taking on more of a specific token for any reason, I think we should to be able to respond quickly & follow suit (if need be).

what would put us in a situation like that how could we respond quickly?

it’s sort of like a google search engine approach, where we’re sourcing a foundation from multiple respective protocols to on-board and to select a pause.

I look at the distinction between reacting and responding as when you react it’s a knee-jerk reaction and it’s like muscle memory and we don’t necessarily think about it;

whereas when you respond to something it involves thought and in this instance we have an opportunity to proactively think in advance when we’re creating the requirements to take on a token; what our methodology should be when we want to consider removing/ pausing a token.

and how does that happen what does that look like, because we’re going to still have tokens That are already in the mix; so I think what happens is you end up saying hey we’re just gonna pause taking on those tokens at this moment, until we can visit the situation in more depth, though it’s something we want to be able to respond to quickly.

so I almost think in some instances as if it meets certain criteria that we should be able to pause the continued onboarding of specific tokens & Then put it to a vote — sort of like where the guardians you know it’s like 2 AM and JayDubb is awake in Australia has to make an executive decision on a post & I know this is entirely different than a post on a message board; though in some ways it isn’t.

it’s like Game of Thrones you know where you’ve got the ‘Lord Commanders of the Night’s Watch’ — looking out for the white walkers.

i’m just saying — we should have a plan in place that allows us to respond quickly & if we wait and use a more deductive approach to vote on an initial pause — our voting to approve — could be too late. so who pushes the button and under what criteria?

just remember UST and Luna, If a situation like that is unfolding quickly, we want to be able to hit the pause button, versus taking on more of a liability & yeah it’s totally different, but you know three arrows capital and Luna there was a time that wasn’t that long ago where they were fully respected & then very rapidly things changed. so, we wanna be ready when things happen because things do happen, as we’ve seen. The landscape changes in the landscape we know today can be entirely different tomorrow; like that of an ocean.

So says a 24 hour pause (on what criteria though??); does that make sense? and what would the residual impact of doing that be, if we were to pursue that type of a strategy.

— we also want a corresponding PR message to be sent out, so that the community and the people that use the protocol understand the logic & people that have tokens inside should always be able to get them and take them out; depending on their situation (have to pay liquidation fees — if it’s an early liquidation, etc) you know what I mean.

I know I’m looking at it from a backwards approach, though sometimes looking at an idea from different angles makes it more versatile & stronger; improves the reflexivity of the idea overall.


Love it.
Yeah the big red button theory is totally needed to protect the people and the protocol. I think this could actually it’s own forum thread because there could be lot of discussions about the requirements to enable pushing the big red button.


So, where do we go from here? We have different models listed above that provides thoughtful ways of onboarding collateral safely.

I think we could be discussing what could be the actual process for Hifi, step by step, which could then become a ‘candidate’ process, that would then be up for snapshot voting.

If a voting would be successful, the process would then be published on official Hifi documentation at, and it would open the gate for onboarding new collateral using that process.

If the above makes sense to admins, we could probably start documenting each steps right here in the forum, and then directly through a Github fork of, making it easy to have admins and devs review the document through merge requests, to eventually bring the new documented process into the official Hifi docs.

This also provides an opportunity to community members, to contribute to Hifi directly.

1 Like

To enable people to create, present, and vote on proposals, documentation and tutorials are an essential part of it. We need to educate people on it.

1 Like

I want to focus on this thread more, it’s important and the work has barely started. I feel it’s time to list relevant elements that will safely help Hifi onboard collateral, and I want to be involved in this important decision taking.

And as mainnet is coming soon, 2023 might be a year where more people will progressively start leveraging the lending protocol, and request new tokens as collateral. The safeguards must be in place to protect everyone.

This specific thread makes a parallel with Safely onboarding NFT collections as collateral. The latter could be an iteration of the former.

I will promptly create some form of document, shared or something, to list and evaluate steps that should be part of the process to onboard new collateral. This will create a work sheet, which could also help create work sessions for brainstorming and sharing ideas.


A document and a system to do it safely don’t you think?