Moonwell Asset Listing Framework v2

[Gauntlet]

Gauntlet and Community Members are proposing the following framework and requirements for Moonwell markets to utilize when listing new Asset Markets:

Disclaimer from Gauntlet

Gauntlet worked closely with the Moonwell community to develop this V2 document. Gauntlet does not cover smart contract risks or any technical risks. Any of the smart contract or technical risk references or guidelines provided in this document are provided as general best practices by either Gauntlet or the Moonwell community. We defer to auditors with expertise in smart contract risk to provide their assessment.

Onboarding new collateral assets is inherently a risky process and contains several strategic decisions the community has to make, with tools the community decides to use. Gauntlet does not determine the strategy or the tools of the protocol, but below are a series of suggestions and guidelines for the community to consider when proposing to list new assets on Moonwell.

Disclaimer from Warden Finance

Warden worked with Gauntlet and the Moonwell community in reviewing this document. We defer to auditors and other vendors for their recommendations regarding smart contract best practices, and technical guidelines.

The process of onboarding new assets carries substantial risk implications and the community should always exercise caution when evaluating the risks of listing a new asset. Community members should be aware that the suggestions and guidelines presented in this document are general in nature. Ad-hoc analyses might be necessary to include specific tail risks for given assets.

Background

To guide best practices in the community, this document aims to provide a standard framework for assessing market risk when listing assets and enabling assets as collateral, as well as a set of process guidelines for the community to follow when submitting a proposal to list a new asset. Given 2 weeks of notice and strong community buy-in, Gauntlet and Warden Finance will conduct risk assessments prior to new assets being listed, however, these risk assessments are only one step in the process of enabling a new asset. Throughout the asset listing and collateral enablement processes, the goal of risk managers is to ensure that insolvency and liquidity risks are minimized and that when liquidations do occur, that they can be conducted in a healthy and efficient manner, with sufficiently incentivized liquidators. In order to be unbiased, risk managers will not explicitly support any asset listing, but instead provide the below framework as guidance for the community.

To safely deploy a new asset or market to the Moonwell protocol, other factors must also be considered, including, but not limited to: oracle risk, smart contract risk, centralization risk and ecosystem support. Again, we defer to auditors with expertise in smart contract risk to provide their assessment.

Asset Listing Process

1.) Forum Post: The proposal author submits a forum post titled “Add [ASSET SYMBOL] market to Moonwell on [Network]” under the “Community Proposals” category of the Moonwell Governance Forum, providing as much information as possible, including all fields from the “Risk Assessment Checklist” below.

2.) Community Check: The Moonwell community verifies the accuracy and completeness of the forum post information provided by the proposal author.

3.) Off-chain Signal Vote: The author incorporates community feedback and submits the proposal to the Moonwell Snapshot Portal for an off-chain signal vote. The passage of this signal vote will indicate to risk managers that there is sufficient community buy-in to proceed with their risk analysis procedures.

4.) Risk Analysis: The Moonwell community, alongside risk managers, assesses and deliberates on the risks associated with listing the proposed asset. This assessment is based on the data provided by the proposal author and the risk managers’ market risk assessment frameworks.

5.) Contract Deployment: Following delivery of the risk managers’ market risk analysis and initial risk parameters, the proposal author leverages either the Moonwell Market Deployer (for Moonbeam and Moonriver networks), or the updated Market Add procedure (for Moonwell v2 deployments on Base and other networks) to deploy the market’s smart contracts and generate proposal call data.

Instructions for using the Moonwell Market Deployer can be found here, as well as a sample run. For Moonwell v2 supported networks, such as Base, the documentation for creating a governance proposal can be found here.

6.) Onchain Proposal Submission: The proposal is submitted to Moonwell Governance for onchain voting. Upon successful passage and execution of the Moonwell Improvement Proposal, a new market for the proposed asset is activated on the Moonwell protocol.

Proposal Requirements

• New market proposals must first be posted on the Moonwell Governance Forum.
  • Format the title as “Add [ASSET SYMBOL] market to [Network]”
  • Post in the “Community Proposals” category
  • Include all “Required Information” listed below
  • Update forum post with link to live vote
• On Moonbeam and Moonriver (Moonwell v1) networks, all proposal contract calls/JSON must be derived from the Moonwell Market Deployer output.
• On Moonwell v2 networks, such as Base, all proposal contract calls should be derived from Foundry and generated using the procedure found here.
• The on-chain proposal must include:
  • JSON derived from the Moonwell Market Deployer or calldata generated by Foundry in the Moonwell Contracts v2 repository.
    • No additional contract calls should be included
  • Proposal description in Markdown
  • Link to original forum post
  • Titled formatted as “MIP-# Add [ASSET SYMBOL] market to [Network]”

Required Information

The following information should be included in the forum post when submitting a proposal to list a new asset:

General

• indicates a required field

• Token Asset Name*

• A description of the project and the token*

• Benefits to the Moonwell Community*

• Resources (Website, Social Media Links, and docs)*

• The proposal author’s contact information*

• The relationship between the author of the new market proposal and the token*

• Social channel metrics (size, activity, and growth)

Market Risk Assessment

• indicates a required field

• Market cap of the token*

• Total supply*

• The largest central and decentralized exchanges where the token is listed and its respective liquidity*

• Volatility per Gauntlet’s definition Gauntlet - MakerDAO Auction Report (30 days, 90 days, 1 year) (Gauntlet can also help with this)*

• Average daily trading volume on CEX and DEX*

• Gini coefficient and Herfindahl index of token balances*

• Emission schedule

Decentralization

• indicates a required field

• List the top 10 token holders, the percentage held by each holder, and tag them if they are known*

• List all of the privileged roles in the token contract. This can include whitelisted EOAs, Multi-sigs, or DAOs.*

• Is the token pausable?*

• Does the token have a blacklist?*

Smart Contract Risks

• indicates a required field

Codebase & On-chain Activity

• Provide a Github repository for the underlying token contracts*
• Provide a test suite with code coverage
• Provide Basescan/Moonscan/Etherscan links with verified contracts*
• Give the age of the token in days*
• Provide the number of transactions in the contract to date*

Security Posture

• What audits, if any, were performed? Provide links to the reports if they exist.*
• Does the project have an active bug bounty program?*
• Provide emergency contacts with their estimated response time/availability*
• List additional security and formal verification tools used in the development
• List all monitoring services used by the token, if any.

Upgradability

• Is it upgradeable?* If yes, answer the following questions:
  • Who is authorized to make an upgrade?
  • Can an upgrade happen instantaneously or is there a time-lock delay?
  • Which components are upgradeable?
  • How does the upgradeability design work? Who manages it and how are upgrades performed?
  • Does it emit an event when the implementation is updated?

Oracle Assessment

• indicates a required field

• Chainlink oracle price feed address*

• Is the asset a wrapped, staked, or synthetic version of a different underlying asset?* If yes, and the Chainlink price feed provides price data for the underlying asset rather than the wrapped, staked, or synthetic version, please provide the following information:

  • How is the asset wrapped, staked, or otherwise created?
  • On what network does the underlying asset exist?
  • How can you verify that the amount of the asset that is minted is never more than the amount of the underlying asset that is locked, staked, or used as collateral?
  • Is there a way to verify proof of reserves (PoR) on the same network as the market?
  • Please provide an analysis of the price deviation from the underlying asset; ie. over the last 180+ days, how much has the price of the token on centralized or decentralized exchanges deviated from the price of the underlying asset?
  • What specific events might cause the price to “depeg” or no longer be the same as the price of the underlying asset?

Initial Asset Risk Parameters

Risk managers will assess the liquidity and market characteristics of proposed assets.They will then communicate their findings to the community and suggest appropriate initial risk parameters. If the protocol does not support supply caps (Moonbeam and Moonriver), we recommend that the collateral factor be set to 0 at the time of initial listing. Our primary objective in commencing with a collateral factor of 0 for the initial listing is to assess liquidity demand and ensure the feasibility of liquidations, taking into account the anticipated supply and borrow volumes at the outset.

Reserve Factor

The reserve factor is more straightforward on the initial listing, with risk managers generally recommending 15% for stablecoins and 25% for non-stablecoin assets.

Supply and Borrow Caps

Generally, it is advisable to adopt a conservative strategy when determining initial supply and borrow caps for new markets, as these parameters play a pivotal role in Gauntlet’s efforts to safeguard the Moonwell protocol against potential threats such as infinite minting, price manipulation attacks, and unsuccessful liquidations. Gauntlet’s primary objective in establishing the supply and borrow caps during the initial listing is to foster sustainable growth while simultaneously mitigating risks within Moonwell markets. This approach ensures that unforeseen technical and market risks are minimized, thereby reducing the likelihood of protocol failures or substantial insolvency events.

Base Markets

Moonwell’s Base deployment supports both supply and borrow caps, making the approach for setting caps on initial asset listing distinct from markets without supply caps. The availability of supply caps enables risk managers to minimize risk exposure to the protocol, while simultaneously allowing for collateral enablement upon market activation… Gauntlet will establish supply and borrow caps by employing a methodology that allows for the initiation of more conservative initial caps, taking into consideration the asset’s data and liquidity. Gauntlet has been elected as supply/borrow cap guardian for Moonwell’s Base deployment, empowering the risk manager to quickly implement cap adjustments following initial recommendations.

Supply caps should be determined based on either the minimum token quantity needed to induce a 10%-25% price shift in the local market decentralized exchange (DEX), 10%-50% of the onchain circulating market capitalization of the token, or the minimum supplied tokens needed to break even in a long price manipulation attack. Gauntlet’s recommendations for these caps will also take into account other factors, such as volatility, liquidity across both decentralized and centralized exchanges across different chains, as well as onchain growth and adoption trends.

Borrow caps should be determined based on the minimum amount of borrowed tokens necessary to achieve a break-even point in a short manipulation attack or set below the established supply cap.

Moonriver and Moonbeam Markets

The Moonbeam and Moonriver markets lack support for enabling supply caps. Consequently, Gauntlet will employ borrow caps in tandem with non-collateral enablement to enhance risk mitigation during the initial listing process.

Borrow caps should be set at 10%-50% of the onchain, circulating market cap of the token or the amount of borrowed tokens necessary to achieve a break-even point in a short manipulation attack.

Collateral Enablement

Enabling collateral can be one of the riskiest phases for a new asset launching on the Moonwell protocol. The general recommendation is a conservative, phased approach in which we recommend setting the collateral factor at 0 for initial listings. However, this recommendation may vary depending on factors such as asset liquidity and the availability of supply caps. New market risks are introduced when an asset is enabled as collateral. The community should assess the technical risks and follow OpenZeppelin’s framework. Below, we outline the relevant market risks and recommendations.

The community should take the first step in proposing that an asset is enabled as collateral by publishing a post on the Moonwell Governance Forum. This forum post should contain the metrics outlined above (market cap of the token, total supply, etc.). Should there be enough community support behind enabling this asset as collateral (i.e. via a snapshot vote), risk managers will then provide a market risk analysis as described below.

Risk Management Analysis for Collateral Enablement

Sufficient liquidity is required for an asset before enabling it to be used as collateral. Gauntlet must stress that because there are no supply caps for the Moonbeam and Moonriver markets, requirements for collateral enablement and collateral factor ramp-up will be more conservative than in markets with supply caps due to the inability to use supply caps to mitigate price manipulation and market liquidity risk. To validate asset liquidity, we analyze the combined slippage across all liquidity sources to measure how well a given asset can be absorbed into the market (a signal that may change upon asset listing).

Gauntlet recommends as a threshold either the combined localized DEX slippage or CEX+DEX liquidity via Coingecko to understand what the market could healthily absorb if a liquidation were to occur. If either is met, Gauntlet would support enabling collateral for the asset. These are the metric thresholds we recommend to have an asset move forward with collateral enablement:

25% DEX Slippage	$200k
2% Depth (CEX+DEX)	$2M

The 25% DEX slippage signifies the cost associated with swapping the asset for a stablecoin such as USDC or USDT. The 2% Depth value represents the depth value to move a price down across centralized and decentralized exchanges across all chains. This framework can be adjusted based on further analysis and collateral enablement strategy.

Note that this is an initial guideline to broadly understand the liquidity of a given asset. As risk managers conduct analysis on new assets coming to the protocol, we may provide a more granular analysis (i.e., around the distribution of users and around asset classes) that deviates from this guideline when we determine there is a better understanding of the market risks.

It must be the case that the Moonwell community supports a given asset being enabled as collateral. This is not an assessment that can be made purely from a market risk lens, as the non-market risk side can pose a more existential threat to Moonwell (i.e., smart contract bugs). After the community decides that they want an asset enabled as collateral, the general recommendation for markets with no supply caps will be to start conservatively at a 5-30% collateral factor. This will be assessed on a per-asset basis. The goal is to give the asset enough time at a low collateralization ratio to make sure that mechanisms are working as intended and to better assess the risks associated with the new collateral positions. Following 2 weeks of collateral enablement and ongoing parameter tuning work through simulation optimization, risk managers will consider increasing collateral factors based on the actual usage data and market conditions, as long as it is safe to do so from an insolvency risk perspective.

Thus, this phased approach to collateral enablement starts with conservative collateral factor parameterization. After the asset is enabled as collateral, risk managers’ financial modeling platforms will continue to ingest data on how usage and market conditions evolve. At this stage, through a more thorough understanding of risk via our simulation models, risk managers can optimize for capital efficiency to the protocol.

Gauntlet Guidelines

• Gauntlet will not conduct simulations using fake data to assess the risk.
  • Simulations do not lend well to this type of listing when there is no prior data. Gauntlet has in the past used borrower distributions from similar assets to assess risk. However, this has been a weak signal given how different each asset’s usage behavior is when actually incorporated into the lending platform. As such, Gauntlet will not conduct simulation analysis to predict user behavior ahead of an asset’s listing.
• Gauntlet will not assess any of the following areas of non-market risk and instead defer to other vendors and the community on the below:
  • Oracle risk
  • Infinite mint attacks
  • Governance attacks
  • Smart contract risk
  • Centralization risk
  • Other technical risks
  • Gauntlet will treat the asset as if it serves its underlying purpose correctly and will not assess ancillary aspects of the token design. It is up to the community to decide whether a given asset belongs in the protocol.

Warden Guidelines

Warden will provide the community with a suite of on-chain data points and liquidation backtesting analyses to facilitate community decisions during collateral onboarding processes. These analyses will use on-chain data when applicable (i.e. if the asset has a sufficient onchain history). It is imperative to note that as market conditions evolve, our economic risk assessments, reviews, and recommendations may become outdated or inadequate and may have to be updated.

The asset onboarding tools provided by Warden only cover economic risks and should always be complemented by ad hoc analyses from the community or other vendors to included asset specific risks such as but not limited to:

• Oracle risks
• Smart contract risks
• Governance attack vectors
• Centralization risks

Next Steps

• After the community has had time to review, a snapshot vote will be put up

[Luke]

Thank you for this excellent guide for asset issuers who would like to enable new collateral markets on Moonwell. This will go a long way towards helping our community evaluate the safety and risk of new collateral assets, and is timely as several RWA and LST asset issuers are looking to expand to the Moonwell protocol.

[thiago]

Thank you for providing this guideline. The framework looks pretty complete and the risk assessment was very insightful.

I wonder how we should determine the minimum liquidity and %collateral for different assets like liquid-staked-tokens and RWA’s. While RWA’s (like t-bonds) provides more stability (almost like a stablecoin), the lsTOKEN might add another risk layer. In times of black swans, users will have an additional layer of operation for liquidating their positions.

Also, having 3 options of ls-tokens available might fragment the liquidity…

[Curly]

Great work on this very clear and well-thought-out framework.

One question I have is whether there should be a separate vote for the different protocols. Meaning should MFAM holders vote on this separately from the WELL holders?

I know in general we are “one project”, but I am aware that there are some MFAM holders that are not WELL holders and vice versa.

The proposal and Snapshot vote seems to suggest that WELL holders are currently voting to ratify the framework that Moonwell Apollo will be adopting as well.

Likewise, I think it is worth stating that if ratified the governance token holders of the respective protocols will have the final vote on whether or not a new token is onboarded to their protocol. meaning MFAM holders will vote to permit new tokens to Apollo, and WELL holders will vote to permit new tokens to Artemis and Base.

[Gauntlet]

Hi @Curly,

Thanks for your suggestion! We’d like to pursue the MFAM ratification of this framework at some point. However, there are concerns about immediately proceeding with a Snapshot vote due to the current lack of bridging infrastructure on Moonriver and the slow pace of new asset listings. Once a bridge partner has been solidified and new assets are available to list on Moonriver, we can pursue the MFAM ratification of the MALF v2.

[Curly]

Ok, thank you for that clarification.

I think it would be useful to have that mentioned in the proposal above. As it stands it does sound like we are voting for this framework to be implemented across all instances of the protocol. You also included the Moonriver tag in the title line, while this only impacts Moonbeam and Base.

Sorry to be so pedantic. I am in favor of this proposal being implemented across all instances…just want to make sure we are following best practices.

I take my GoverNerd role (too) seriously.

[penanna]

Hi here, just going through the guide. Who is assessing the Initial Asset Risk Parameters? Another question I have is about Chainlink support, do you accept any other oracle?