Given that the friendly fork framework’s operation and contribution aspects are not defined, the community must understand the different ways BGD contributes to these forks, including what tech contributors of the DAO do for them and what they do not, as well as guidelines for their contributions.
Aave friendly forks: why
Currently, the Aave protocol could be understood as two major components:
- The codebases and infrastructure that are owned by the Aave DAO.
- The decentralised management and strategy over instances of that infrastructure, also by the Aave DAO.
The whole Aave ecosystem is focused on maximising the success of those two components together.
But historically, numerous parties have shown interest in accessing the codebase and infrastructure of Aave, while not relinquishing control to the Aave DAO.
With the friendly fork framework (to apply on EtherFi, Ink, WorldLibertyFinance, etc), the DAO factually defines a modularisation of infrastructure and management, allowing the replication & usage by external partners, but with those external partners being in charge of management and strategy of their instances.
While this idea is akin to white labelling agreements on traditional software, an important difference with those arises from the fact that the Aave DAO has external independent parties (Service Providers) to maintain and modify its software, together with doing quality and risk assessments and recommendations.
Even if we think that initiatives like this one by @EzR3aL to formalise further the friendly fork framework are required and should be encouraged (potentially with a small engagement/grant), the role of Service Providers towards friendly forks is a core piece. So we would like to clarify what exactly we do/don’t on the BGD side, and this way not creating any blockers, while keeping transparency with the community.
BGD’s work on friendly forks
Like with any critical software, configuring and running an Aave instance and its peripheral infrastructure with the highest possible standards requires expertise, and in what relates to technical and security topics, we are the expert party engaged with the DAO.
That means that for the friendly forks framework to be viable, we need to be involved up to a certain degree with the party that will manage the fork. With the upcoming EtherFi and Ink friendly fork instances being a good first touch on this type of workstream, the following is a high-level list of aspects where BGD is going to be involved:
1. Pre-production stage: setup of the friendly fork
-
Each friendly fork has slightly (or totally) different use cases. So first of all, we get in contact with the team that will manage the friendly fork and understand from them what exactly they want to do: assets to be listed, control model of the friendly fork, and optional infrastructure they want to configure/not, amongst others.
-
Once the previous is understood from our side, we explain how the configuration of the Aave-friendly fork will look to start with, and collect specific configuration requirements: e.g., addresses that will have a control role, the initial assets themselves to be listed, any custom price feed they decide to plug, etc.
On this stage, even if it is the full responsibility of the fork manager to choose the asset to be listed, we do a very light verification on those assets for them to be technically compatible with the Aave protocol. Important though, no matter what we highlight and recommend, the decision to include/not to assess in the listings set is of the friendly fork manager, not ours.
Additionally, how to price each asset is also a decision to be made by the friendly fork manager. From our side, we may highlight which layers (e.g. CAPO) are recommended, usually following examples from the pricing methodologies on official instances of the Aave DAO. -
Once all the requirements are fulfilled by the friendly fork manager, we deploy and configure the infrastructure. Similar to the DAO, this infrastructure will not be active/operative, as its activation will need to be decided and executed by the friendly fork manager (akin to new pool activation proposal in Aave DAO instances).
-
Depending on how the team behind the friendly fork will want to manage the instance post-production, we instruct and support them or other DAO contributors (e.g., ACI) on crafting the payload to activate the instance, which will be executed via whatever control mechanism they choose to have.
-
Finally, the friendly fork manager activates the instance.
2. Post-production stage: support for management of the instance
Once both the core and peripheral infrastructure are up and running, our role towards it changes to be focused on the following:
- Support the fork manager (or Aave DAO contributors involved) when using all the tooling available from the Aave DAO to maintain their instance: e.g., instructing them on how to make changes in the system, like listing of risk parameters modification.
- Whenever a new version of the protocol (e.g., v3.4 or v3.5) becomes official on the Aave DAO instances, support the fork manager to apply it to its instance.
- If any security threat affects the protocol itself, address protection and remediation with the fork manager. Important to notice that this applies to problems related to the generic codebase, and best effort to any common component (e.g., same asset listed on Aave DAO instances and the friendly fork), but not to custom components like could be custom assets listed, or modification of the codebase.
- For any new asset listing the manager wants to do, we can do a best-effort verification that the asset won’t create any issues on the protocol. Important to notice that this does not imply doing the type of deep full analysis we do for the Aave DAO instances, just some basic checks.
Our principles of contribution towards friendly forks
- Same as with the Aave DAO, we are not any type of decision makers to apply changes to the production-friendly fork. We advise and/or prepare those changes, but the responsibility of applying them lies with the fork manager.
- We don’t develop new tooling within the scope of the DAO towards friendly forks. Our responsibility is to have the existing tooling supporting general use cases that can help manage those forks in addition to the Aave DAO instances, but anything completely custom for each single one of them is outside our scope, and should be discussed ad-hoc between the fork manager and BGD.
- To receive full support from our side, friendly forks must compromise to keep up with the latest upstream version of the protocol (v3.4 currently, v3.5 soon). If going into a custom direction or opting out of upgrades, we can’t promise compatibility of all tooling, and our support role will be best-effort.
- Aside from light advice, if we see something very relevant, we don’t do a full technical/security analysis of assets the fork manager wants to list. We assume that if the manager wants to list an asset, they should understand any applicable risks.
- Unless we decide on any other ad-hoc mechanism, our defined support in this document only lasts while having an outstanding engagement with the Aave DAO, and that engagement including support for friendly forks.
For example, our current engagement with the DAO lasts until October, so the support for friendly forks extends agreement-wise until then. - We are providing this service within our current scope, with no extra cost for the friendly fork, as we believe this is a very valuable and fundamental value proposition from the Aave DAO. However, if any other Service Provider provides services at extra cost, we reserve the right to re-evaluate the pricing of our scope.
- On the other hand, as previously commented, our scope is with the Aave DAO and does not include custom components; one specific friendly fork would want to build. In that case, if the fork manager wants BGD to participate, it will be outside of our Aave DAO scope.