[ARFC] Framework for Instances and Friendly Forks
Author: ACI
Date: 2024-11-01
Motivation
Table 1 shows a large variation in terms of historical friendly fork proposals. We propose that terms for friendly forks are formalised to ensure fair and transparent treatment of teams wishing to make use of licensed Aave instances in the future.
Table 1 - Licensed instances and benefits to Aave
| Partner | Profit share for Aave | Token supply to Aave |
|---|---|---|
| WLFi | 20% | 7% |
| Spark | 10% | None |
| Superlend | 15% of quarterly revenues over $200k | Unconfirmed amount of tokens airdropped to stkAAVE holders |
| Zerolend | 10% for first year | 1% to stkAAVE holders |
| RealT | 20% | None |
| Reental | 20% | None |
It should be noted in the above that two particularly strategic outliers are present in WLFi and Spark. Spark represented a significant revenue opportunity for Aave DAO, with $2m per year projected revenue at the time of proposal. This could go some way to explaining the profit share being at the lower bound of previous forks. With WLFi, the terms are at the higher end of the range, although it should be noted that this is not an entirely separate fork of Aave and will make use of Aave liquidity, and tokens will in part be distributed as rewards to users.
Two other outliers representing not as good value for Aave DAO are the Zerolend, and Superlend forks. It should be noted that the Zerolend proposal was rejected by governance for being too low a profit share. With Zerolend there was a time limit on the profit share terms, meaning that Aave DAO will cease to benefit from any success of Zerolend after the first year. Superlend introduced a minimum revenue value before profit share kicks in, this means the team deploying the fork will profit before Aave DAO does, despite Aave DAO facilitating this through use of the protocol code. Both of these forks also proposed token airdrops to stkAAVE holders, however no tokens directly to the DAO treasury. It is our belief that the DAO should decide how to distribute tokens within the Aave ecosystem and not the teams proposing forks.
In our view there are two distinct scenarios which must be considered when discussing friendly forks:
-
Friendly Fork: Entirely separate deployment, making no use of existing Aave instance liquidity. This may often be on a smaller EVM blockchain or L2 which Aave is not currently deployed on.
-
Whitelabel Instance: deployment which makes use of existing Aave instance liquidity as facilitated by Aave 3.2, for example WLFi.
We believe it is reasonable to expect whitelabel solutions making use of existing Aave liquidity to agree to a higher profit share and token payment to Aave DAO as there are significant benefits associated with this arrangement. It is also possible for tokens provided to the DAO to be deployed as incentives on the main instance in a mutually beneficial manner. On the other hand, teams which handle the deployment themselves, and attract their own liquidity to their fork could be expected to pay a lower profit share given the reduced role of Aave DAO in providing liquidity and other services. This proposal intends to set baseline terms for both of these scenarios which can be referred to by those proposing licensed instances as well as Aave governance when licensed instances are proposed in the future.
Specification
For the avoidance of doubt the following two scenarios are proposed:
Friendly Fork:
- No Aave DAO involvement beyond licensing Aave code base.
Whitelabel Instance:
- Makes use of existing Aave liquidity.
- Aave DAO will make an effort but makes no guarantees to use DAO owned tokens to participate in governance through the Aave Protocol Embassy.
- Aave DAO and Service Providers will handle deployment.
It is proposed that the following terms be set as the baseline for Friendly Forks and Whitelabel Instances of Aave in the future:
Scenario 1: Friendly Fork
| Profit share for Aave | Token supply to Aave DAO |
|---|---|
| 10% distributed monthly | 3.5% of Total Supply at time of TGE or before deployment if TGE already occurred, if the token is rebasing or inflates in the future, Aave DAO will receive additional tokens so as not to be diluted. |
Scenario 2: Whitelabel Instance
| Profit share for Aave | Token supply to Aave DAO |
|---|---|
| 20% distributed monthly | 7% of Total Supply at time of TGE or before deployment if TGE already occurred, if the token is rebasing or inflates in the future, Aave DAO will receive additional tokens so as not to be diluted. |
In addition we propose the following for both scenarios:
- Tokens are to be provided to Aave DAO treasury which can then decide on their distribution through governance.
- No time limits on profit share.
- No minimum revenue hurdle before profit share kicks in.
If deployment of an instance holds outsized strategic or financial advantages to Aave DAO, it is possible for these terms to be deviated from with governance approval. However, it would be expected that the proposing entity provides a strong argument for why deviation should occur.
No onchain actions are required for this proposal so if ARFC Snapshot passes this will become canon.
Next Steps
- Publish a standard ARFC and collect community & service provider feedback before an ARFC snapshot.
- If the ARFC snapshot passes, this community preference becomes canon and risk service providers incorporate this into current and future recommendations.
Disclaimer
The Aave-Chan Initiative (ACI) has not been compensated for the publication of this proposal.
Copyright
Copyright and related rights waived under Creative Commons Zero (CC0).
