[ARFC] Create an Excessive Debt Facility

Governance
1

title: [ARFC] Create an Excessive Debt Facility
author: @llamaxyz
created: 2023-03-12

Summary

This proposal presents Aave with the opportunity to allocate a $2.5M facility dedicated for facilitating the repayment of excessive debt on approved Aave deployments.

Abstract

A $2.5M per calendar year facility enabling contributors to repay excessive debt of $5,000 or more per wallet on approved Aave deployments.

Using this budget, any Aave contributor is able to repay excessive debt held within eligible wallets without needing to create Snapshot votes for each individual instance. A forum post detailing what is to occurr, receipt of approval from the respective service provider (@Llamaxyz) and an AIP to implement the change will become the new process.

However, Snapshot is to be used to determine which Aave deployments are covered, or excluded, from accessing the Excessive Debt Facility. The process of adding and removing Aave deployments, is the same as how the Safety Module coverage is currently managed.

Motivation

The proposal seeks to streamline how Aave manages events leading to excessive debt accumulating within the protocol.

With the creation of an Excessive Debt Facility, Aave can move swiftly to repay any excessive debt across various networks. Upon implementation, the process becomes as outlined below:

  • Submit ARFC detailing
    • Affected Aave Deployment
    • Affected Reserve
    • Affected Wallet Address
    • Excessive Debt Amounts
    • Asset used to repay Excessive Debt
    • Detail Any Asset Swaps and use of Agregator
  • Approval from respective Service Provider (@Llamaxyz)
  • Submit payload to @bgdlabs for peer review
  • Submit an AIP for voting, or payload to the Guardian where cross chain infrastructure is not yet implemented.

Any contributor can publish an ARFC proposal, then the respective service provider (@Llamaxyz) will approve the request on the forum and then anyone can submit an AIP to governance. This approach mirrors the process for increasing SupplyCaps whereby one risk providers support is needed before an AIP can be submitted. This proposal is to utilise the expedited process by removing Snapshot votes from the process to minimise the duration in time from when the excessive debt occurs and is repaid.

With the creation of an Excessive Debt Facility, this streamlines how to implement repayments within the specific facility allowance. Rather than proposing which assets can be used to fund any Excessive Debt repayment, this proposal outlines which assets are not to be used when funding Excessive Debt repayments.

This approach also creates transparency around how to fund the repayments up to a defined threshold. By removing the Snapshot step and definig which assets can eb used to refund Excessive Debt repayments, repayments can be streamlined and implemented by any contributor.

The overal Excessive Debt Facility is to be managed by the respective service provider. At the time of writing, Aave has engaged Llama to provide this service. Llama will be responsible for reviewing any ARFC from the community and verifying the proposal is in line with this governance forum publication.

Specification

The following outlines an overview to the approach for determine eligible of coverage by the Excessive Debt Facility:

The following Aave Deployments are covered:

  • Ethereum v3
  • Ethereum v2
  • Polygon v3
  • Avalanche v3
  • Optimism v3
  • Arbitrum v3

Aave deployments not mentioned above are excluded until a Snapshot vote extends coverage to the proposed deployment.

Wallet eligible requirement:

  • $5,000 or more in excess debt

Wallets with smaller amounts of excessive debt are not eligible for funding as part of this proposed facility.

Excessive Debt Facility:

  • $2.5M per calendar year, rolling basis

Asset used when repaying excessive debt:

  • Any assets on applicable network excluding the below:
    • BAL, CRV, AAVE, network tokens or liquid staking tokens

If Excessive Debt was to be incurred in BAL, CRV, AAVE, network tokens or liquid staking tokens reserves, then another asset is to be swapped and used to repay the excessive debt. Aave shall retain BAL, CRV, AAVE, network tokens and liquid staking tokens, whilst using other assets to repay any excessive debt.

Location of funds:

  • Treasury or Collector Contract address on respective network

Execution:

  • ARFC forum post
  • @Llamaxyz reviews, approves and comments on forum
  • Payload submitted to BGD for peer review
  • Submit AIP or payload to Guardian where cross chain infrastructure is not yet implemented

If an asset is to be swapped from one type to another, then swaps are to be routed via MEV protected aggregators. @Llamaxyz with support from @bgdlabs will develop a template to facilitate standardisation and ease of implementation. Where communities prefer, @Llamaxyz will support the development of and implementation of any associated Excessive Debt repayment payload.

Implementation

To repay the excess debt, the repay function will be used. This function requires the token which the excessive debt is nominated in, the amount and the address which the excessive debt that has accumulated within.

pool.repay(crv, total bad debt, variableInterest, Address)

Copyright

Copyright and related rights waived via CC0.

1 Like
2

A few notes:

  1. The solvency of the Aave Protocol, and the broader ecosystem’s confidence in it is the most important task of the Aave DAO. We should not limit the types of tokens used, especially since the debt may be denominated in those tokens.

I would rather some annual budget streamed into a contract so that protection continues to grow if unused in a given calendar year, as opposed to starting fresh each year. Should the facility grow too large, a governance proposal can move funds to the RF or another address etc.

I would encourage the DAO to consider streaming the funds from the RF into another address, that has different permissions, allowing Risk Contributors to quickly move to address any excessive debt without the slow and burdensome process that is governance. Especially given the clear intent of the stream and fund, governance is authorizing these funds for a purpose, provided governance can claw the funds back at any time, having an easier means to act on the mandate being passed would increase efficiency of this important facility.

  1. Development of the Debt Facility Contract - Given the complexity of the build, and how the scope falls outside of all the various agreements of our existing contractors, I would be supportive of AGD running a formal RFP process to ensure the DAO gets this built in a timeline manner at a reasonable cost.
4 Likes
3

This proposal is rooted in good intentions and is especially timely.

It feels worth the investment though hopefully something we don’t need to use often as a DAO.

We agree with this direction, as well as the push towards streaming - allowing for Risk Managers to become more actionable, and ease the governance overhead.

It builds like a savings account or emergency fund for rainy days.

Thanks for starting the discussion about this.

2 Likes
4

Hi @oneski22, @fig,

With several Collector Contracts and Treasuries addresses on most networks, streaming assets to an additional address introduces a few considerations.

  • Streaming a % of revenue nominated in each asset to a designated address will lead to small holdings of various long tail assets accumulating in the address. If ever used, this will likely need to be consolidated. For context, we suggested that AGD receive some long tail assets which could be sold upon receipt to stable coins as part of AGD funding, but this was not preferred due to the time spent coordinating and processing swap transaction via multi-sigs.

  • The pre-defined budget, as currently proposed, is available in full, on each network as required. If we use streaming contracts and divide the overall budget across each network, it will likely lead to several addresses holding smaller amounts of capital. This presents operational considerations, as each assigned Excessive Debt facilitator address (1 per network), may not contain sufficient funds as required. This is especially likely to be the case on new deployments or those which are not yet generating significant revenue. This approach would reduce the overall efficiency, as it will lead to governance intervention to move funds around and introduces more capital constraints compared to having a flexible budget available on any network as needed.

  • It is not clear if excessive debt repayments are risk provider or treasury manager scope. Historically, this has been managed by the treasury team. It is Llama’s opinion that budgeting and funds management, whether it be liabilities or revenue generative, falls into the remit of the finance team.

  • Historically, with exception of AGD, there has been minimal interest for large sums of funds to be managed by individuals outside of the main collector contract. veBAL and treasury management strategies, likely to include GHO liquidity, are expected to all be managed from within the Treasury addresses.

As the proposal is currently written, the funds are to be held in the existing contracts. These funds are expected to be held in aTokens on various v3 deployments. It is reasonable to expect this budget would form part of a lower risk allocation within the broader treasury management strategy. Llama favours holding the community’s funds within the Treasury address where possible, as this is where the community’s service providers are remunerated from.

Llama has plans to enable the streaming of strategic assets like BAL and CRV back to Ethereum, where they will feature as part of a broader treasury management strategy. This is why such assets are excluded from this proposal.

Something to clarify, the $2.5M amount is intended to be thought of as, over a 1 year period Aave can use this budget to repay excessive debt without going the normal route through governance. The normal governance process can be used where deviating from this proposal. Using strategic assets, or exceeding this budgetary allocation, would be something that goes via the current ARFC > AIP process.

This is an interesting concept, if we streamed funds for risk service providers to manage, perhaps the same philosophy can be applied with Treasury funds for the finance team to manage. At this point, Aave would be trusting AGD with several millions of funds and risk providers also, it would seem a logical progression to do the same for treasury management.

With financial reporting, runway analysis, treasury management, and past experience in paying excessive debt being something Llama provides to Aave, we feel this type of work is within our current remit. To this end, if anyone from the community wanted to contribute, we are happy to include these contributors and would fund the work from within Llama’s funding from Aave.

We do view this facility as a first line of defence and we do believe a forum post before repaying the excessive debt is warranted, similar to how risk parameter are currently managed. At this point in time, we think the more prudent route, is to agree and allocated nominal budget rather than ongoing allocation.

1 Like
5

Thanks for the post @Llamaxyz,

We are in favour of the Excessive Debt Facility and believe it’s important to act quickly so that Aave’s realisation of adverse price movements is limited.

If Excessive Debt was to be incurred in BAL, CRV, AAVE, network tokens or liquid staking tokens reserves, then another asset is to be swapped and used to repay the excessive debt. Aave shall retain BAL, CRV, AAVE, network tokens and liquid staking tokens, whilst using other assets to repay any excessive debt.

While I understand the strategic nature of this, how would the swap occur and can it be done in a timely manner without having to go through a governance vote? If not, wouldn’t this defeat the purpose of the EDF?

What are your thoughts on having the full amount or x% of $2.5M retained every year such that the EDF can grow over time?

1 Like
6

Very supportive of this.

Agree with Wintermute here. The DAO may want to consider a bad debt accrual on revenues where x% is allocated specifically to this fund and accrues over time until needing to be paid out. This likely makes more sense than a flat-rate burden on the protocol’s P&L in volatile conditions.