Background
This post proposes a possible framework with which to evaluate new collateral types for VST minting in the Vesta Vault system. As a lending protocol focused on providing capital efficiency, Vesta has long sought a more streamlined process to provide users with more opportunities to access liquidity opportunities. Thus far, we have successfully onboarded five collateral types onto our system while steadily maintaining peg throughout our protocol’s existence. Though this is a good start, we believe that we can quickly and substantially outpace this rate.
This post will outline the necessary process for onboarding a new collateral type as well as the items that must be submitted in a successful process. It sets the standards through which we can accurately understand the risks that a token can pose to our system. A successful risk framework should streamline the onboarding process, allowing us to unlock the potential of many more assets than we have thus far. It should remove blockers and unknowns around the process, which also opens the door to community-sourced collateral onboarding.
As a result of a recently passed vote in favor of partnering with RiskDAO, we expect this process to be both speedy and robust. Through a combination of in-house analysis and the quantitative perspective of RiskDAO, new collateral types will be of the highest quality and utility.
Motivation
We aim to extensively build out our suite of collateral types available to mint VST against in the near future. To that purpose, we must construct a robust framework through which to analyze risk to minimize possibilities of damage to our system and VST’s peg. By doing so, we expect to substantially increase VST supply and usership by attracting novel collateral types that add greater color to Vesta’s composition.
Process Overview
At a high level, our proposed risk analysis process will have this general flow, in chronological order:
- Vesta Partnership Request/Curia Proposal
- To simplify the initiation phase of onboarding, we plan to accept both direct requests from protocols to onboard specific tokens and pre-written proposals on our governance forum. In both cases, the community will maintain a say in the process.
- Risk Checklist
- A comprehensive checklist of relevant qualitative and quantitative data is provided and evaluated, as described in the sections below.
- Community Verification
- A proposal including the team-verified checklist is submitted to the community for final read
- Community Temperature Check and Poll
- The community is invited to share general opinions on the involved collateral and any relevant details, followed by a poll of community sentiment
- RiskDAO assessment and report
- RiskDAO is engaged to provide a purely data-driven approach to supplement Vesta’s analysis. We expect RiskDAO to take on research into the collateral’s oracle, multisig parameters, volatility, among other key indicators of risk.
- Parameter Finalization
- Work continues with RiskDAO to finalize Vault parameters such as mint cap, fees, and minimum collateralization ratios.
- Testnet Deployment
- Oracles and testnet contracts are deployed for testing and quality assurance
- Final Community Vote
- A governance vote on final deployment on the relevant network is conducted.
- Deployment
Risk Checklist
Please see below a table of checklist items, organized by categorization, see below for justification of various items:
Checklist Motivations
Use of the checklist
We have designed the checklist to be used in a grade-based categorical fashion. That is, we expect each new collateral type to be categorized and assessed according to first principles first, and then graded in each item according to their placed category. As a result, we believe we can adopt a more dynamic risk assessment policy which allows us to fill a lending basket with many more diverse assets that would be possible with a more traditional approach. Currently, Vesta supports a range of assets from GMX to ETH to gOHM, and we would like to maintain this diversity going forward. We recognize that there is substantial complexity to this process and that ours may differ from other well-known frameworks, but as a result of our willingness for onboarding new collateral types, we believe that what we are presenting here is sufficient.
Smart contract risk
It is Vesta’s immediate goal to ensure that all onboarded collateral types contribute to both the utility and stability of VST. To that end, we recognize that many instances of capitulation are a result of faulty smart contracts rather than actions related to swapping. As such, we are asking all proposed tokens to provide qualifying information such as a valid GitHub repository or the number of token transactions. From this, both ourselves and RiskDAO can conduct the needed analyses for onboarding. We believe that while properly audited code is a good start, our own due diligence is the needed safeguard here to prevent any unfortunate oversights.
Counter-party risk
We also recognize that not all actors in the ecosystem have perfectly aligned incentives or flawless governance. As such, we believe that we can take the proper steps towards protecting the protocol and its users through a thorough assessment of counter-party risk. Generally, this phrase describes the risk involved in engaging another party in an agreement and the possibility of their inability to fulfill the partnership terms, either through malice or inaction. For us, this looks something like a governance attack on a partner protocol’s platform directed at us, rapid purposeful action on a collateral token to impact VST’s peg, or any other event on a collateral directed to harm Vesta, be it malicious or not. We believe that looking into factors such as the partner’s multi-sig can reasonably reduce the risk of these events.
Market risk
This risk is a self-explanatory one but somewhat difficult to define accurately with few inputs. However, as Vesta seeks to onboard more diverse assets and further improves its already secure mechanisms, we are willing to take on assets of varying market risk. We will however continue to diligently assess these factors in our onboarding process. We plan to use best practice methods described deeply by other protocols with lending features such as Maker, Aave, and Compound. To that end, we will pay great attention to both quantitative and qualitative traits such as liquidity depth across the market, oracle quality and history, token volatility as defined by Gauntlet, as well as the supply-side of the token. With these factors in mind, we believe we can make a more informed decision on many assets.
First principle categorization
Before anything else, we would categorize a new collateral type into a number of different buckets. By looking at whether the token is used for governance, whether it’s designed to hold some kind of peg, whether it’s backed by some asset treasury, etc. These qualitative first-principle driven analysis will help the protocol form a more comprehensive picture of the token. With this process on the books, more color is added to each new step. In this way we can more accurately assess the risk of a specific token in relation to comparable peer assets, without placing the collateral type in a vacuum.
Following these example questions, we can accurately group assets into a typology:
- Is this token a governance token?
- Is this token backed by an asset treasury and is it partially redeemable?
- Is this token a stablecoin?
- Is this token backed by high quality liquid assets?
- etc.
Community Sentiment Poll
After sufficient community discussion on this RFC, the authors of this proposal will open a poll for this framework.