[ARFC] AL Service Provider Proposal

[AaveLabs]

Summary

This ARFC proposes a one-year technical contributor engagement for the Aave Labs to act as a service provider for development of Aave V4 and a new visual identity.

Motivation

Aave Labs seeks to be onboarded as a service provider to be one of the technical contributors to the Aave DAO. The specification below outlines the scope of the technical contributions of Aave Labs.

Specification

The following are the key deliverables within the grant:

Aave Protocol V4

Key deliverables for the 1 year scope of development include:

• New Modular Architecture
  • An innovative design to enhance flexibility and efficiency, minimizing disruption for integrators.
• Unified Liquidity Layer
  • A flexible liquidity management approach that allows for module modifications without needing to migrate liquidity.
• Fuzzy-controlled Interest Rates
  • Automated rate adjustments based on market conditions, optimizing for both suppliers and borrowers. Utilizing Chainlink for precise data feeds, setting new standards in capital efficiency.
• Liquidity Premiums
  • Adjusted borrowing costs based on collateral risk, ensuring fairer pricing. Higher risks incur higher premiums, while lower risks reduce costs.
• Dynamic Risk Configuration
  • Allows dynamic adjustments to risk parameters based on market conditions without governance overhead.
• Smart Accounts and Vaults
  • Simplifies user interactions with the protocol by allowing multiple smart accounts per wallet and enabling borrowing without direct collateral supply.
• Automated Assets Offboarding
  • Streamlines the process of offboarding assets, reducing governance workload and ensuring predictable offboarding plans.
• Enhanced Liquidation Engine
  • Introduces a variable liquidation factor, liquidation strategies, and batch liquidations to improve efficiency and borrower experience.
• Automated Treasury Management
  • Implements a reverse auction mechanism for reserve factor assets, reducing governance overhead.
• GHO Features
  • Native GHO Minting
    • Allows for more efficient minting of GHO directly from the liquidity layer.
  • GHO “Soft” Liquidations
    • Utilizes a LLAMM model to ease liquidations and manage market downturns, providing options for users to choose which collateral to liquidate to GHO.
  • Stablecoin Interest Paid in GHO
    • Suppliers can opt to receive interest payments in GHO, enhancing capital efficiency and providing additional benefits to the protocol.
  • Emergency Redemption Mechanism
    • A feature to handle prolonged and heavy depegging of GHO, ensuring stability and reliability.

Visual Identity Assets

Aave Visual Identity Guidelines | 2024

Deliverables include:

• Provision of Visual Identity Assets: Compiling and delivering a package of visual identity assets, including, but are not limited to, logos, color schemes, typography guidelines, various Ronnie illustrations and other graphical elements.
• Usage Guidelines: Instructions on how to implement the visual identity assets across various platforms and media, including digital and print formats. Practical examples and best practice scenarios demonstrating the potential usage of the visual identity assets.
• Delivery: The assets will be delivered and packaged in a Github repository accessible to everyone and hosted within the Aave DAO Origin organization.

Prospective Second and Third Year Scope

The DAO may renew the engagement with Aave Labs as a service provider for a technical contributor for a second and third year with that scope of work to be determined at a later date and subject to community input and AFRC approval.

Grant

$12m GHO, including $3m upfront and $9m streamed over the year.

Evaluation Metrics

• Monthly reporting of contributions to the Aave DAO.
• Solicitation of feedback from other service providers working as technical contributors and DAO members.
• Direct and transparent engagement with the DAO via the governance forum.

Principles

• Aave Labs shall strictly adhere to the scope of its designated role as one of the service providers working as a technical contributor, ensuring all decisions and actions remain within our areas of the engagement.
• Aave Labs shall prioritize the security and robustness of its technical contributions.
• Any production-ready code written within the scope of the proposal will be moved to the Aave DAO’s GitHub repository.
• Aave Labs shall engage with the DAO like all other contributors within the established working relationships and procedures of the Aave DAO. For example, decisions concerning risk configurations, DAO treasury, code audits, and other matters not covered by this proposal will need to be separately approved by the Aave DAO via TEMP CHECKs and Snapshots.

Next Steps

• Engage with the community and other service providers to refine the proposal.
• Incorporate feedback and escalate ARFC to a Snapshot vote
• If the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.

Copyright

The text of this ARFC is released under the CC0 license. The visuals and the New Visual identity are subject to and governed by the license specified in the approved governance proposal by the Aave DAO (to be included in the ARFC at a later date).

[bgdlabs]

@AaveLabs

Any written software will be deployed by another Aave DAO service provider specializing in deployments, subject to the Aave DAO’s decision and approval.

From the technical side of the DAO, we would like to recommend to not include this clause. The rationale is that to start with, it is always recommended security-wise to have the party doing the development of certain software to lead all preparations of its activation.
Especially with new systems, this is even more critical.

To clarify, for the big majority of projects of the Aave DAO (and certainly for all major), the process should always be the following to start with:

1. The technical contributor doing the development does all the preparations for the system to be activated. This includes but is not limited to any smart contracts pre-deployment required, “cold” permissions configuration that later on (on activation stage) will be assumed by the DAO smart contracts and coordination of all off-chain components to be ready for pre-activation.
   To be clear, all this pre-deployments and configurations are on a system which factually is not Aave until approved by the community via an on-chain governance proposal, so there is no limitation or centralization in having the team with specific expertise doing them.
   Quite frequently, it is very far from ideal to do absolutely everything on the activation proposal, and it is simply not natural to “outsource” this step to another party until the system reaches certain maturity (e.g. this is getting done now with Catapulta, but after pretty good maturity of procedures).
2. After everything is prepared, an activation governance proposal should be written by the same party and submitted to vote for governance. Ideally, these proposals should be as light as possible given their criticality: they are factually the recognition of the new system as part of the Aave DAO, approved sole and only by token holders, and usually involve the DAO assuming certain permissions on the system, and “unpausing” it for users to start using it.

This is no new process, same as how it worked with Aave v3 new instances until now:

1. A technical service provider engaged by contract with as deep expertise as possible in v3 and the systems around (BGD Labs) did all technical preparations for a new pool; following all recommendations of other service providers and mandates of the DAO (e.g. initial recommendations and assets pre-approved on ARFC), but making this process as exhaustive and secure as possible for the later activation. During this process, the Solidity payload for the activation proposal is also written to be used later on by the Aave DAO.
2. The technical provider (or any other entity, but ideally the technical provider), creates a governance proposal for the activation proposal. From then on, the responsibility of activating/not the new system is on the Aave DAO via the $AAVE token holders. Once the proposal is approved, the system is factually owned by the DAO.

[AaveLabs]

Thank you for your thoughtful and detailed explanation about the deployment process. We fully agree that security is a top priority, and you are right about the difference between pre-deployment activities and the system becoming part of the Aave Protocol through AIPs and activation.

We understand how important it is for the development team to handle the preparations for activation and ensure all security measures are in place. However, there’s room for the technical contributor ecosystem to grow. In the long run, we believe it makes sense to separate the role of the deployer contributor. This aligns with the checks and balances that are key for a mature and decentralized ecosystem. Just as developers don’t audit their own code, having separate roles for development and deployment can strengthen the system.

We would like to find ways to involve more community contributors in the process. This will not only boost the technical skills within the ecosystem but also encourage more community involvement in critical technical areas. By gradually involving specialized deployment contributors, we can leverage the current expertise and slowly introduce the separation of roles, adding another layer of scrutiny and security.

[AaveLabs]

Since we don’t see any misalignment in principle with @bgdlabs here, we’ve decided to remove the bullet point to keep things moving forward.

We have created the Snapshot HERE

[AaveLabs]

With the positive outcome of the governance vote from this proposal, we would like to thank the Aave community for their support on this proposal and continue proceeding with the deliverables.

Today we are sharing our first deliverables, the Aave Visual Identity Assets for Aave and GHO including Usage Guidelines, are now delivered into the Aave DAO’s GitHub repository, Aave Brand Kit. Aave Labs will keep iterating and adding more brand assets over its service provider tenure whenever brand surfaces increase or change.

Aave Labs will start updating relevant brand surfaces and similarly these assets are now available for usage for all service providers, partners and for any applicable brand surface.