Gauntlet Market Risk Framework for Asset Listings

Since Gauntlet began its partnership with the Acala protocol, we have received requests from the Community to analyze asset listings. Community members, developers, and other stakeholders often asked us questions like, “how much liquidity should this asset have before being listed? What should the asset’s initial parameters be? How do we protect the protocol from insolvency?”

Gauntlet’s framework focuses specifically on market risk and how Gauntlet will support the asset listing process in Acala. Our framework can be found here.

To guide best practices to the Community, we provide this standard framework for assessing market risk when listing new collateral assets. Listing collateral is essential to the growth of the protocol. As new assets in DeFi proliferate and older assets fall out of favor, Acala must list and delist assets to maintain its usefulness as a protocol. Gauntlet will conduct these risk assessments prior to new assets being listed, given 2 weeks of notice and strong community buy-in.

We welcome and appreciate feedback from the community. If you have any thoughts or questions, please share them on this forum or message our team.

Quick Links:
Asset Listing Framework

While this analysis dissents from traditional parameter assessments made by Gauntlet of DeFi dApps on the Ethereum ecosystem, it is well composed and scientifically researched. There’s no doubt about that.

The bigger question the Acala community needs to ask itself, how do you expand Liquidity for ACA? The provided analysis below :point_down: showcases a need to hire a Business Development that will get out there and create more liquidity for ACA on both CEXes and DEXes.

As far as the proposal requirements for asset listing, (“include the following data” requirement) the Acala Community might want to add:

  • a brief history of the project/asset listing.
  • Request for Link to the whitepaper, documentation portals, and source code for the system(s) that interact with the proposed collateral, and all relevant Blockcahin addresses. If the system is complex, schematic(s) should be supplied.
  • Request for Links to any available audits of the project. Both procedural and smart contract focused audits.
  • and last and not least, ask how is the applying collateral type currently used?

Otherwise, good stuff!

1 Like