Decentralized finance (DeFi) has flourished in recent years, with the total locked assets recently exceeding $100 billion.
The Wing platform was launched on Ontology’s MainNet in September 2020. Wing’s Flash Pool currently runs on three chains (Ontology, Ethereum, and OKExChain), with its Inclusive Pool for credit loan products, Any Pool for NFTs, custom interest rates and periods having also been released. While continuing to innovate, Wing always puts the security of the project and its users’ assets first. Wing also offers the unique Insurance Pool to ensure assets safety. All versions of Wing have passed audits by Beosin, CertiK and PeckShield. For details, please refer to: https://docs.wing.finance/#audits
The world of DeFi is a highly complex and interconnected ecosystem. Risks affecting one aspect of the system may have the potential to impact dependent subsystems. Assets (e.g. WING, ONT, ONG) are at the heart of the Wing protocol as they enable operations and secure the assets and liabilities of the protocol.
This article, developed by the Wing Risk Management Team, focuses on the risk assessment for assets supported by Wing. The risk assessment considers market, counterparty, and smart contract risks, for the assets supported by Wing. The authors hope their assessment contributes to a safer, more secure DeFi ecosystem.
When the Wing protocol connects with the rest of the DeFi ecosystem, it also exposes the protocol to financial contagion. Assets used in the protocol affect the protocol at its core, in particular, assets accepted as collateral which safeguard the solvency of the protocol. To ensure a currency holds a reasonable amount of risk, we investigate three different levels: smart contract risk, and counterparty risk, and market risk.
Our risk scale ranges from lowest risk (10) for the safest assets of the protocol to the highest risk (1).
Smart contract risks relate to the security of asset technology based on the underlying currency code. If one of the supported assets is compromised, the collateral will be affected, thereby threatening the solvency of the agreement. Projects must be audited before they can be considered secure, but still smart contracts risks cannot be completely removed. We evaluate the risk of smart contracts based on the maturity of the smart contract (the time it has been launched) and the total number of transactions.
We observe different degrees of governance decentralization that may give direct control over funds (as backing, for example) or attack vectors to the governance architecture which could threaten the protocol and/or its funds. Therefore, the factor of counterparty risk is set. Counterparty risk focuses on the degree of decentralization of the asset and the rationality of the asset generation mechanism. Counterparty risk is measured according to the number of asset holders and the asset generation mechanism.
Market risks are linked to the market size and fluctuations in supply and demand. These risks are particularly relevant for the assets of the protocol, specifically assets serving as collateral. If the value of the collateral decreases, it could reach the liquidation threshold and become liquidated. The markets then need to hold sufficient volume for these liquidations, which tend to lower the price of the underlying asset through slippage affecting the value recovered. Although we have a complete decentralized liquidation mechanism and an insurance pool mechanism, the risk cannot be fully mitigated. We look at the 24-hour average trading volume representing asset availability to assess liquidity risk, and the largest price fluctuation in the past month to assess volatility risk. Finally, we also considered the market value that represents the size of the market.
The risk control score table is as follows:
Based on the above risk control scores, we have made a comprehensive assessment of the pledge factor of assets.
We will directly modify the collateral factors of the following two assets in the coming launch on the Ethereum Flash Pool:
According to the risk control model, the pledge factor adjustments of the assets that have been supported and other parameters that need to be modified (such as liquidation rewards, Reserve Factor) will be discussed in the forum and voted on. When adding new assets in the future, we will also use this model for asset access and parameter setting.
In the future, we will continue to study the various risks involved in the Wing project and optimize them, including but not limited to asset risk, liquidity risk, code risk, policy risk, user default risk, etc., and gradually develop a framework to protect Wing. We’ll also constantly improve the current risk model with more research, more calculation and latest data.
When preparing this article, we referred to Aave’s Risk Framework. As industry leaders, Aave has brought many innovations and novel ideas to our risk control model which we are grateful for.