Extend the Safety Module Protection to V2 Markets

Risk General
1

title: ARC: Extend the Safety Module Protection
Update
status: WIP
author: Governance House, @MatthewGraham @ncitron, 3SE Holding & uhom
created: 01/04/2022

Simple Summary

This ARC proposes to extend the Safety Module (SM) protection to V2 markets as the smart contracts have been extensively battle tested.

Abstract

The Safety Module is a $700m risk mitigation pool holding that protects Aave users. It’s a unique mechanism within DeFi, that pushes borrowing capacity while providing security for users. At the moment the SM only covers the Aave V2 Ethereum market. As a result, not all users across the V2 markets share the same level of risk protection.

As new markets hold more risk at launch, they are initially excluded from the SM protection. Today, most of the V2 markets have been extensively battle tested and have been generating collections for the Aave DAO, they seem fit for SM protection.

Motivation

The SM is one of the largest risk mitigation pools of DeFi. This pool was designed to protect Aave users from potential deficits in an Aave Market. As new markets hold additional risk, these are not initially protected by the SM. However, once a market has been live and battle tested for a few months, the risks are significantly lower. Furthermore, the listed assets are currently similar across markets and follow the same rigorous listing process, with an assessment based on the Aave Risk Framework.

Overall, these markets are smaller than the Ethereum V2 Market, holding combined supplied and borrowed assets of just half of the Ethereum V2 market. This implies that, in case of a shortfall event in an Aave market, the shortfall would likely be smaller on those markets than on the Ethereum V2 market. Overall by covering different markets the SM would benefit from diversification of risks, as these are not additive but rather follow the law of large numbers.

Extending the SM coverage to other V2 markets reduces the risk for liquidity providers (lps) on these markets. By reducing the risk for lps, it is expected to lead to further growth of the market’s TVL overtime. Through standardising the application of the SM across the markets, lps are treated more equally across the markets.

The Safety Module protection needs to take into account the additional risks of these markets. In the case of Aave markets on other chains, the SM will only protect in cases where the Aave smart contracts experience a failure, and not failures caused by the chains themselves (Polygon/Avax). With regards to the Aave Arc Market, Safety Module protection is contingent upon acceptance of the Aave DAO’s stated risk parameters, should the whitelisters of the Arc market reject a DAO approved Risk Parameter update, the market will lose coverage until it is brought back in compliance with the DAOs stated tolerance.

These markets have become core components of the Aave ecosystem. In particular, the Polygon and Avalanche markets have opened the Aave Protocol to new users for which Ethereum transaction costs are prohibitive. Today, most users prefer these markets with over 1m addresses having used Aave V2 Protocol on Polygon, while just about 100k on Ethereum V2. These markets also represent a large share of the protocol revenue bringing in half of the ecosystem collections, in a shorter time period.

Specification

The table below shows the Aave V2 markets, assets listed and ecosystem collections for the Aave DAO.

Market Assets Supplied Borrowed Ecosystem Collections Inception
Aave V2 Ethereum Reviewed by Gauntlet $14.6B $5.2B $29m 3/12/2020
Aave V2 Polygon V2 Ethereum Assets + MATIC + GHST $1.6B $408m $10.8m 12/04/2021
Aave V2 Avalanche V2 Ethereum Assets + AVAX $5.4B $2.4B $5.5m 20/09/2021
Aave Arc Some V2 Ethereum Assets $43m $22m $15k 01/01/2022

Voting

FOR Polygon: DO extend the coverage to Aave V2 Polygon

AGAINST Polygon: DO NOT change the existing arrangement

FOR Avalanche: DO extend the coverage to Aave V2 Avalanche

AGAINST Avalanche: DO NOT change the existing arrangement

FOR Arc: DO extend the coverage to Aave V2 Arc

AGAINST Arc: DO NOT change the existing arrangement

Copyright

Copyright and related rights waived via CC0.

6 Likes
2

I think this is a key addition to adding the SM to other networks.

As for ARC, in addition to the language (below)

In the future the whitelisters should offer a first layer of protection themselves prior to SM activation, but for bootstrapping the ARC market this feels like the right decision.

1 Like
3

Gauntlet is supportive of extending the Safety Module to V2 markets. From a risk perspective, it is valuable that the Safety Module covers V2 markets as a backstop against insolvency / deficit events. For Aave Arc, Safety Module coverage is especially important for adoption, as the institutional audience requires comfort around risk management before deploying significant amounts of capital.

5 Likes
4

Lots of good intentions in the above post. I believe reassuring V2 Markets and their users with Safety Module protection will create more trust among users and encourage adoption.

@Pauljlei says this best here:

By relying on downside protection created by Aave, it creates a sense of in-house insurance.

I am curious about when this safety module can be extended to V3 markets:

What makes something “battle-tested?” Is it a certain volume of TXs, a threshold of TVL, or the age of contract? Seems a bit subjective but important to extend to V3 when ready.

Doing so will encourage the migration of users to new and improved contracts.

2 Likes
5

If the risk/volume for a claim increases and something has to be paid from the reserve, doesn’t the interest rate for that risk also have to be increased? How do I calculate the risk correctly and how do I derive an adequate risk interest rate from this (safety module)? THX guys

6

Hi all, isn’t Aave Arc permissioned and whitelisted? Maybe it might make more sense for Arc to have its own separate safety module.
For example, if a shortfall event happened in Arc that didn’t happen in the other open Aave markets, should SM really pay out since Arc is essentially a walled up market?
Just thinking out loud…

7

Hi, i also thought about that and think this should be considered.
Its a completely different and permissioned market. In that case i think the Arc User themselves should be able to have their own kind of SM. Could be a different one though. But if it would be the same using Aave token, this would also create another use case for the Aave token. Which would benefit the talks in another thread about tokenomics changes.

TL,DR:

  • SM for Aave Arc
  • Security in whatever happens
  • Usecase for Aave token
1 Like
8

My additional thoughts on Safety Module for Arc…

Arc was built mainly for institutional / Enterprise investors who want to get into DeFi but don’t want to step into the regulatory grey-zone of an open DeFi economy.

Safety module was built for users of the open Aave market as, essentially, a self-insurance mechanism, because no traditional Insurance company with big enough pockets wanted to touch insuring DeFi protocols with the kind of coverage we would need.

Maybe a specific Aave Arc Safety Module could simply be… a centralized insurance from one of the big trad Insurance companies (or a consortium of them).
I mean… Arc was built on different principles than open DeFi markets, it’s got the controls and whitelisting that make it “compliance”-friendly. It has Enterprise gatekeepers.
Would be interested in what others think of this?

I think pursuing insurance for Arc may be a good first step for eventually accessing insurance coverage for Aave in particular, and all DeFi in general.

My current position is:

  • No to Arc coverage by SM, and recommendation for Arc to have its own SM or pursue traditional insurance coverage
2 Likes
9

Hi everyone :wave:

We have created three separate proposals that enable the community to vote on if we should extend the Safety Module to protect the Polygon, Avalanche and ARC v2 markets:

[ARC] Extend the Safety Module Protection to Aave V2 Polygon
https://snapshot.org/#/aave.eth/proposal/0x7da4985b2d5b1cbe6bbc0992d5c86030cedef2013487e4b53b4244c315c90155

[ARC] Extend the Safety Module Protection to Aave V2 Avalanche
https://snapshot.org/#/aave.eth/proposal/0x91ec3f1836dc0a52536ba953e9cbbbab4d9e7565e06be8d8db28ab0d5feff8ac

[ARC] Extend the Safety Module Protection to Aave V2 ARC
https://snapshot.org/#/aave.eth/proposal/0x0822cf558d7e42463558aac6dbc9cb60cdfe36fae827bd8a2cad15c208ccb075

Community members can vote on each proposal independent from the others. We are looking forward to seeing the community participate in these votes.

Matthew Graham

3 Likes
10

Hello,

Voted YAE for Aave V2 ARC as making the ARC market more attractive and safer is a net positive for the ecosystem.

Voted NAE for Poly & AVAX because it makes no sense to me to support outdated tech, V3 is safer than V2 (isolation mode) and should be supported. V2 will eventually fade away.

3 Likes
11

I agree with Marc’s points. We should encourage users to migrate to V3. @uhom You write the following in the proposal: “By reducing the risk for lps, it is expected to lead to further growth of the market’s TVL overtime.” - What is Aave’s interest in growing V2 Markets?

I believe ARC is not able to migrate to V3 at this point in time as the whitelisting functionality is not implemented yet in V3 so this is a slightly situation and probably warrants enabling it.

1 Like
12

We agree with @MarcZeller ‘s idea that we should not extend the SM to Aave V2 on the Polygon and Avalanche Network. We should support V3 instead because V3 is much better than V2. Therefore, when V3 is battle-tested enough, V2 should fade away.

For ARC, the question we should ask is whether the ARC users participate in locking the AAVE/ETH in the Safety Module contract. If yes, then the SM should cover for ARC market because they participate in the insurance for the Aave Protocol. If not, then the SM should not cover for ARC market because the users do not contribute to the Safety Module; thus, they should not be compensated for a shortfall event.

1 Like