[ARFC] Strategic Opportunity Framework for Friendly Forks and Whitelabel Instances

Governance
1

[ARFC] Strategic Opportunity Framework for Friendly Forks and Whitelabel Instances

Author: EzR3aL

Date: 2025-05-04

Summary

This proposal is meant to be an update and upgrade to the existing Framework for Instances and Friendly Forks created by @ACI in 2024.

Motivation

The goal of the first iteration of this proposal (see here) was to create a standard for friendly forks and whitelabel instances. While the general idea was good and is already helpful it is lacking some major specifications and for that reason needs to be reworked.

Aave is currently the number one lending protocol in terms of different metrics for example market share based on TVL or active loans.


[1] Source: https://tokenterminal.com/explorer/markets/lending/metrics/active-loans

Based on the top 6 projects in lending with at least over 500m in active loans (date:26/04/25)

Additionally Aave’s v3 codebase currently dominates the lending category, holding approximately 53% of the market share, which underscores the robustness and reliability of its technology and explains why many projects opt to fork Aave’s code rather than developing their own from scratch.

[2] (Source: https://defillama.com, Aave v3 + Aave v3 forks TVL / Lending TVL, date: 26/04/25)

This means, it has a big community trusting the protocol and its security in the form of its codebase, risk management and other features it is offering like:

  • Flashloans
  • liquid e-Mode
  • safety layer aka Umbrella
  • collateral & debt swap
  • deep liquidity
  • wide asset support
  • deployments on several L1/2 (EVM + Non-EVM)

It’s a superior protocol in its vertical. The Aave infrastructure and brand are superior and widely known.
The current form of the friendly fork framework is undermining these features and the Aave brand by asking

  • friendly forks for only 10% of their revenue monthly distributed and 3.5% of their total supply at TGE or shortly before deployment if TGE already occurred and
  • Whitelabel instances for 20% of their revenue monthly distributed as well as 7% of their total supply at TGE or shortly before deployment if TGE already occurred.

This proposal suggests creating a more detailed framework with different packages the DAO can offer and each package having different terms that have to be accepted from the counterparty.

Specification

The following two scenarios are proposed:

Friendly fork:

  • Licensing one specific Aave version
  • Social Media support from delegates & service provider at launch
  • Risk assessment for initial asset listing evaluation (one-time)
  • Security updates & patches two-times only

Whitelabel Instance:

  • Option 1:

    • 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
    • Social Media support from delegates & service provider at launch
    • Risk assessment for initial asset listing evaluation (one-time)

  • Option 2:

    • 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
    • Social Media support from delegates & service provider at launch
    • Risk assessment for initial asset listing evaluation (one-time)
    • Umbrella coverage (Insurance fund)
    • Ability to use the “Powered by Aave” branding
    • Ongoing security updates & patches
    • GHO facilitator allowance

In addition I propose the following for each of the scenarios:

Scenario Profit share for Aave Token supply to Aave DAO
Friendly fork 15% distributed monthly 3,5%
Scenarios Profit share for Aave Token supply to Aave DAO
Whitelabel Option 1 25% distributed monthly 7%
Whitelabel Option 2* 40% distributed monthly 7%

*Anyone selecting Option 2 automatically agrees to an Anti-Competition Clause. This means you are prohibited from promoting, collaborating with, or implementing code from competitors within the lending sector to not harm the Aave brand, code and its assets.

Additionally I propose the following for all scenarios:

  • No time limits on profit share
  • No minimum revenue hurdle before profit share kicks in

Extra-Clause for Aave DAO Service Provider & Delegates:

If a DAO Service Provider or Delegate opts for a Whitelabel Solution, they agree to allocate at least 50% of profits to the Aave DAO. Additionally, if they introduce a token for this instance, they must distribute 55% of the token supply to aAAVE, and stkAAVE holders. This serves as a security mechanism for Aave token holders & their investment as well as a sign of commitment towards the Aave DAO.

If deployment of an instance holds outsized strategic or financial advantages to the 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.

A structured framework providing clear guidance for the DAO and applicants on determining whether to proceed with a Friendly Fork or a Whitelabel Instance.

It is important to emphasize that this serves as a guiding framework designed to assist both the DAO and applicants. Each project may be assessed on a case-by-case basis by the DAO if there is a justified reason, whether strategic, financial, legal, or otherwise.

This proposal represents a strategic opportunity for the DAO. By endorsing friendly forks and whitelabel instances, the DAO can capitalize on the established Aave infrastructure and brand recognition without assuming full operational responsibility. This approach allows the DAO to benefit from the potential growth and success of these derivative projects like dedicated RWA (Horizon), Stablecoin focused (WLFI) and other instances or forks while maintaining a streamlined operational focus. If the number of friendly forks and whitelabel instances will decrease due to this proposal, the DAO can create a TEMP CHECK and deploy Aave on its own, capturing 100% or potential profits and securing marketshare. The disadvantages are therefore almost non-existent for the DAO.

I invite all DAO member and SP to give feedback, so this ARFC can be adjusted accordingly.

No onchain actions (AIP) are required for this proposal so if ARFC Snapshot passes this will become canon.

Next Steps

  1. Publish a standard ARFC and collect community & service provider feedback.
  2. If the ARFC snapshot passes, this community preference becomes canon and risk service providers incorporate this into current and future recommendations.

Disclaimer

I have not been compensated for the publication of this proposal. I am a holder of Aave & aAave currently.

Copyright

Copyright and related rights waived under Creative Commons Zero (CC0).

  1. Footnotes ↩︎

  2. Footnotes ↩︎

5 Likes
2

Thanks for the great proposal @EzR3aL :folded_hands:

One small note:

Having delegates or service providers promote forks on social media feels a bit off tbh

From my experience (over 30 discussions with money markets in the last couple of years) a lot of these projects (not just the ones forking AAVE, of course) like to position themselves as “AAVE killers” and never hesitate to trash-talk AAVE or the DAO just for the sake of shilling their own token(s)

Economic alignment is key, but it’s not just about revenue. We need to make sure these projects share the right vision and mindset, not just act as opportunistic forks (ofc there’s nuance to all of this & proper vetting can help reduce most of these issues)

Overall, I think AAVE Labs tweeting a small “cross-marketing” tweet could be fine, but I’m not sure it’s a good idea for all service providers to get involved in “marketing”

Also, regarding this:

Not sure we should allow service providers to launch forks or instances at all. Shouldn’t they be fully focused on the core protocol?

One last thing:

I’m also a bit confused about why the anti-competition clause would only apply to those selecting Option 2 of the whitelabel solution and not Option 1, especially considering that Option 2 partners are committing to a significantly higher revenue share to the DAO (40% vs. 25%)

Looking forward to hearing what the rest of the community thinks!

3

Thanks for the proposal @EzR3aL! Overall very much in favour here. The point made by @Tor_GAINS around delegates and service providers promoting on social media feels fair, although it is a valuable service that would be provided to the forks and justifies the revenue share well.

Regarding service providers and delegates launching instances, in some cases, it is fair, especially when they take on undue risk or deploy their own capital and effort in launching the instance. The level of “alignment” expected with the DAO here, however, will be higher than for any other instances.

Overall, promoting a friendly fork and whitelabel instance strategy could be very lucrative - in the real world, something like what McDonald’s has done with its franchises - which allow the Aave brand to be more broadly propagated and well-known. One suggestion could be to use the “Powered by Aave” branding even for Whitelabel Option 1 because it could be mutually beneficial for both parties - however, it could also pose a risk if the instance is less “aligned” with the DAO.

1 Like
4

Formalizing friendly forks seems like a step in the right direction. Usually, teams would bring their offers, and we would negotiate; this provides a baseline for intending friendly forks to consider before approaching the DAO.

5

We have had it several times now that teams were asking for some support. And in my opinion there is nothing wrong with it, as they are using the Aave code that has been approved by the DAO before. Its just to kickstart things and helpful for us aswell. If they get traction we get revenue.

Obviously there are bad sheep and they could simply come and ask for a friendly fork, then create a token and simply leave this space. But thats something the DAO may be able to detect upfront and deny the friendly fork.

We have a dedicated “PR” group that is sharing posts like these, which could be used for that if all agree.

Surely they should focus 100% on their job, but if they intend to create a whitelable only the DAO could stop them from doing this. But if they want to do this they need to pay a price for that. So likely it will be more of a situation where a SP will decide to either stick with the DAO or risk it and create a whitelable instance. Its basically safe salary vs. potentially more salary or huge downside.

The reason is that option 2 is giving way more access to the Aave brand with GHO (liquidity) access, the “powered by Aave” branding, umbrella, etc. While option 1 isn’t including any of these powerful features.
That being said, someone going with Option 1 cannot damage the protocol as hard as someone going with Option 2.
So one could come and choose option 1 and also add other code aswell, lets say some DEX dynamics from Fluid. But if you go with Option 2 you basically “buy” Aave code in its most powerful form and you should not destroy or damage it by adding some Morpho, Compound, etc. elements into it and likely opening a gate to be hacked in worst case.

I removed it on purpose and lowered the revenue share significantly because I do think if you want to go with the light version you are free to modify it but we are not endorsing it.

Option 2 on the other hand is proudly presented but also more expensive.

The general idea aswell is that its either us (the DAO) deploying on a chain or someone is willing to pay for it. In any case we (the DAO) are winning. Cause we will capture revenue in anyway and keep competition away from forking Aave (best case).

I hope this clarifies some parts. Happy to hear some more comments from other SPs like @ChaosLabs, @LlamaRisk, @ACI, @bgdlabs and others as they would be affected in some way too.