[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.

6

I would like to keep this discussion open for a few more days and not proceed immediately with a voting, as I do think its important to hear other voices from SPs that would be directly affected by this proposal.

1 Like
7

Hey @EzR3aL - Thanks for the thoughts and proposal. I’m new to posting in this forum, but my background is working with enterprises to adopt and implement web3 solutions. I try to spend most of my time on the technical side of things, but have done my fair share of proposals/contracting/negotiations. A few thoughts on the proposal below

Can you give some examples of how the friendly fork framework is undermining available features and the Aave brand? Are you just saying that we’re asking for too little from those who are looking to use the codebase, or are there examples of people making a friendly fork and then trying to do harm to Aave?

Security patches seem like table stakes for anyone looking to build real solutions. I think there could be a differentiation between simply receiving security updates (ie CVE fixes) vs new features.

Option 1 - you purchase a specific version of the Aave v3 codebase and receive security patches and updates for the duration of your agreement on that specific version (creates overhead on the SPs as they have to bring patches back potentially many versions)

Option 2 - you purchase ongoing upgrade support with the latest codebase, including latest security patches and new features

Scenarios Profit share for Aave Token supply to Aave DAO
Whitelabel Option 1 25% distributed monthly 7%
Whitelabel Option 2* 40% distributed monthly 7%

These profit sharing numbers seem very high and would likely be prohibitive for most businesses to create and scale using Aave’s codebase. While it’s not a 1 to 1 match on services provided, look at the reward fee figures for staking providers:

Coinbase - 35% of rewards on staked assets / 26.3% of rewards for Coinbase One Members
Binance - 35% of rewards on staked assets
Lido - 10% of staking rewards
Kraken - Ranges betwen 10 and 20% of staking rewards
Swell - 10% of staking rewards

If the intention here is to have many people adopt the Aave codebase as a foundational piece of their business, I think these numbers at a minimum need to come down and likely need to be more dynamic/tied to specific success metrics of the project.

Maybe it’s just that the wording of this clause needs to be fleshed out further, but I’d be generally against this clause. In my experience, my company receives some of the most insightful feedback from our customers based on their use of other products.

Given the brand strength Aave holds, it seems like a benefit to Aave for people who want to use the Aave codebase as a foundational element of their project to try features from other providers and then bring that feedback back to their SP or the Aave community.

1 Like
8

Hey @trevorsc thank you for your comment on this proposal.

So I cannot give you any numbers or a report that undermines my statement besides marketshare or TVL and codebase across all lending protocols. Its more about the pure dominance Aave has in the lending space and the security the code inherits.
You can clearly see this from all the examples that forked Aave in the past (Radiant, Geist, etc.) that all got hacked after doing changes to the protocol because they probably did not fully understand the code. Also some probably most of them had the idea or intention to beat Aave and take the no. 1 spot, but obviously none of them was able to do so.

Sounds interesting but needs SP approval in my opinion. And we probably would need to define Aave versions that can be forked that get that support. And exclude the others to not create too much overhead.

Also interesting, although I would see a delay here for the latest update. So lets say it Umbrella cannot be used by anyone else for at least 6months or even more. To make sure the Aave protocol stays dominant.

Regarding the profit sharing numbers.
For me it was never really about spreading Aave as much as possible. This proposal is more like, we either secure our spot or you pay the price for the best code available in lending. If one does not want to pay for it, thats fine, we take the spot on that chain and get 100% of the potential revenue.
If the DAO thinks we should lower this im happy to adjust, but I would not sell Aave at a cheap price, because its not. Its about supply and demand. We can supply the code and looking at all those forks there is definitely demand for it but yes, you have to pay the price for it. If not, feel free to fork Compound v2 or any other lending protocol thats not based on the Aave codebase already.

And lastly regarding the Anti -competition clause.
My words have been chosen carefully and I intended what the words are saying. If you choose the “full” Aave package you shouldn’t implement new code from opther protocols cause this will likely lead to brand problems if the protocols gets hacked and it says “powered by Aave”.
I also don’t expect any fork to report back to us, telling us for example they implemented feature XY from another lending protocol. So there is no benefit, at least in my opinion.

Thank you again for your thoughful comment and I do hope I answered all your questions.