[ARFC] Horizon’s RWA Instance

Governance
1

Summary

Horizon, an Aave Labs tokenization initiative, creates RWA products tailored to institutions, where regulatory compliance requires some centralization for permissionless DeFi integrations.

This ARFC proposes a friendly fork for Horizon to create a white label instance of the Aave Protocol, enabling the Aave DAO to capture new revenue from the Horizon RWA instance, one that is currently uncaptured.

Motivation

Aave Labs is launching an initiative that works in the RWA space, providing support for existing tokenized assets in the market and tokenizing assets such as Money Market Funds, Credit, Equities and Real Estate. Eligible users can subscribe and redeem these assets onchain. This initiative is also meant to facilitate the flow of value into Aave Protocol through collateralization of these tokenized assets.

Currently, the Aave DAO has limited revenue from RWAs, yet the RWA market is growing substantially with more institutions interested in pursuing RWAs. To accelerate this revenue stream, Aave Labs proposes a white label Aave Protocol instance for centralized and permissioned Horizon assets.

How Does the Horizon RWA Instance Work?

The Horizon RWA instance connects institutions to permissionless stablecoin liquidity while ensuring compliance with issuer requirements. This will allow tokenized asset issuers to enforce transfer restrictions at the token level and maintain asset-level controls, while keeping DeFi composability. Qualified users, permissioned by RWA issuers, can borrow USDC and GHO. With Aave DAO approval, a separate GHO Facilitator will enable GHO minting with RWA collateral, offering predictable borrowing rates optimized for institutions. This enhances security, scalability, and institutional adoption of RWAs in DeFi.

Horizon provides a structured approach to institutional participation, expanding access to permissionless stablecoin liquidity.

Key Design Components

  • Permissioned RWA token supply and withdrawal mechanisms
  • Permissionless USDC and GHO supply functionality
  • Stablecoin borrowing by qualified users
  • Dedicated GHO facilitator with newly minted GHO on demand
  • Permissioned liquidation workflow
  • Integration with RWA-allowlisted ERC-20 tokens
  • Asset-level permission management by RWA issuers

Specification

Strategic Benefits for the Aave Community

The Aave Protocol’s permissionless design is a core strength. However, integrating permissioned RWAs presents challenges that go beyond smart contract development, requiring an offchain legal structure, regulatory coordination, whitelisted liquidations and active supervision—functions not readily available within the Aave DAO infrastructure.

To scale RWA adoption in the Aave ecosystem, Horizon’s RWA instance will launch as a licensed instance of Aave V3, maintaining strong alignment with the Aave DAO.

Revenue Share Mechanism

Aave Labs is proposing an on-going 50/50 revenue share with the Aave DAO from the Horizon instance’s Reserve Factor and GHO revenue, starting from the launch of the instance. In comparison, the revenue split in the RealT RWA instance is 20/80, with 80% going to RealT. Since Aave Labs is closely aligned with the Aave DAO, this proposal offers the DAO a larger share of revenue than other RWA partnerships, while covering legal, compliance, finance, operations, engineering, regulatory affairs, institutional onboarding and business development from Horizon’s share. Aave Labs will bear most of the upfront costs and risks to bootstrap Horizon, covering operational functions, with no grant request to the DAO.

GHO will be listed in Horizon as a standard, non-mintable stablecoin. Liquidity may enter the market either (i) from secondary circulation (GHO minted on the Core market or acquired externally and subsequently supplied to Horizon) or (ii) through D3M-style facilitators configured by the Aave DAO. Under the first path, the Aave DAO captures 100 % of the revenue associated with the originating GHO and 50 % of the Reserve Factor specified in this ARFC. When GHO is introduced via a facilitator, the DAO accrues the full yield rate plus the same 50 % share of the Reserve Factor. These mechanics are consistent with every GHO integration across the Aave ecosystem and are not unique to Horizon.

Growth Incentives

Given the permissioned requirements of this instance, we would expect the instance to grow slower than permissionless markets (especially compared to those with incentives). To accelerate the growth of the Horizon RWA instance, Aave Labs will contribute $500k in incentives (paid in AAVE), with an additional proposed $500k matched by the Aave DAO. Creating a total amount of $1M in symmetric incentives, aligned with the revenue sharing structure. Aave Labs will collaborate with other existing Aave DAO service providers, such as @ACI and @TokenLogic, to organize and distribute the rewards.

GHO Adoption & Revenue

We are also proposing that the Aave DAO dedicates a direct minting GHO facilitator, with initially 1M GHO, that can be scaled up to 5M GHO based on the recommendations of the Liquidity Committee. If the market proves to be successful, it will be the DAO decision to grow this capacity with a separate proposal in the future.

Horizon enables institutional borrowing against RWAs with GHO as a primary liquidity option, alongside USDC, which is expected to:

  • Drive GHO adoption
  • Enhance the liquidity and stability of GHO
  • Strengthen GHO’s role as a settlement asset
  • Generate revenue through GHO borrowing

Operational Support for the Horizon Instance

Similar to the WLF instance approach and its configuration, and considering the nature of the market and supported assets, Aave Labs proposes a dual-role setup with clear separation between “Operational” and “Executive” responsibilities for the instance. While the Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals), the Executive role oversees risk management, assets listing, and general configuration.

The proposed framework assigns the Operational role to the Aave DAO, enabling the community and its service providers to manage the Horizon RWA instance and ensuring that governance and basic operational administrative controls are aligned with DAO oversight.

In parallel, the Executive role would be assigned to Aave Labs, providing the independence necessary to effectively configure and manage the instance. This division of responsibilities enables agile adaptation to evolving market conditions, alignment with institutional requirements, and supports strategic expansions into new networks.

This structure ultimately strengthens the DAO’s institutional revenue streams, fosters ecosystem growth, and leverages Aave Labs’ institutional expertise to navigate complex regulatory environments.

Role application across Aave V3 and V4:

  • Aave V3: Aave DAO will manage the instance’s operations (for example code upgrades), while Aave Labs retains permissions to enable/disable assets, collaborate with risk managers to configure risk parameters and price oracles, target specific networks for deployments, and administer supply/borrow caps.
  • Aave V4: With Aave V4’s modular design, Aave Labs will propose the optimal configuration of the instances upon release.

Permissioning Framework

The Horizon instance introduces asset-level permissioning controls that align with issuer compliance requirements while maintaining open access to stablecoin liquidity. Permissioning occurs at the asset issuer level, with each RWA token issuer enforcing asset-specific restrictions directly at the ERC-20 token level.

  • RWA Collateral Supply: Each RWA issuer enforces its own allowlist mechanism, permitting only addresses verified through its compliance framework to be issued eligible RWAs and subsequently use them as collateral
  • Stablecoin Supply: Any user can supply USDC to the Horizon instance and earn yield, maintaining broad participation and liquidity access
  • Liquidation and Redemption Access: RWA liquidators, typically market makers, must meet issuer-defined investor requirements to liquidate collateral or redeem RWAs

This model enables issuer-level permissioning where required, while preserving the open-access principles of DeFi—bridging institutional standards with composable market infrastructure.

Considerations by the Aave DAO

Based on community discussion of the previous Temp Check, Aave Labs made changes to address community feedback. With the above outlined new structure, Aave Labs requests approval for the Horizon RWA instance—a white label instance based on the existing Aave DAO framework.

Horizon’s RWA instance will expand the Aave ecosystem’s institutional reach while preserving its permissionless integrity. As a licensed instance, it generates new revenue streams for the Aave DAO, accelerates GHO adoption, and reinforces Aave’s leadership in the DeFi ecosystem. Additionally, as mentioned in the previous Temp Check, the Horizon RWA initiative is not meant to exclude other RWA initiatives from other Service Providers or third parties, which are encouraged to further expand the Aave Protocol’s presence in the RWA space.

Next Steps

  1. Engage with the community and service providers to refine the detailed proposal
  2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage
  3. If the ARFC snapshot outcome is YAE, incorporate stakeholder feedback and move proposal to AIP stage

Copyright

Copyright and related rights waived via CC0.

7 Likes
3

Broadly speaking I’m pleased that @AaveLabs has represented the Horizon proposal in its current format after listening to The Dao and amending the proposal in line with those suggestions.
After previous discussions its clear the reasons this needs to be a permissioned entity due to the complex legal framework and I applaud Aaavelabs for comprehensively addressing those issues in this ARFC.

I’m supportive of this proposal but would like to know:

How will revenue (Reserve Factor and GHO revenue) be tracked and reported to ensure transparency and accountability for the Aave DAO, can @TokenLogic add it to their dashboard?

The proposal mentions no grant request, but to be clear, are there any hidden costs or future financial obligations for the DAO (e.g., operational or legal support)?

How will the collaboration with service providers (@ACI @TokenLogic) for incentive distribution be structured, and what fees or costs, if any might the DAO incur?

Just minor points for me and am looking forward to seeing this proposal progress and Aave become a leader in the RWA market.

4 Likes
4

We’re overall supportive of this initiative and have shared our impressions along with a few queries to help delegates make an informed decision. We understand that some of these points might require additional work and could extend beyond the ARFC timeline.

1 Like
5

Excited for Horizon - Aave really needs to make inroads into RWAs and establish leadership there, and the sooner we can get started on this work, the better!

1 Like
6

How will liquidations work for institutions?

7

Appreciate the feedback. Please find below the replies to the topics that were not previously addressed.

The Operational role will not demand any financial obligations from the DAO, now or in the future. This mirrors the current arrangement for Aave V3 management. All expenses required to maintain and evolve the Horizon RWA instance will be borne by Aave Labs and covered by Horizon’s own revenue share.

The DAO is not expected to incur any expenditure beyond those explicitly detailed in this ARFC. Engagement terms with @ACI and @TokenLogic will follow patterns already used in current incentives programmes; the final structure will be clarified once Horizon-specific workstreams begin.

Legal and regulatory framework & User qualification and AML/KYC compliance: Refer to the Permissioned Framework. The precise contractual arrangements and legal structure remain under review and will be presented once confirmed.

Asset issuers, facilitators and liquidators: Liquidations will be restricted to addresses that satisfy the issuer’s investor requirements.

Incentive structure: As previously mentioned, Aave Labs intends to collaborate with existing Aave DAO service providers, such as @ACI and @TokenLogic, to organize and distribute the rewards. The definitive distribution schedule and mechanics will be subject of further analysis between all the parties.

2 Likes
8

This ARFC proposal has been escalated to ARFC snapshot.

2 Likes
9

What’s the status of this proposal?

1 Like
10

Sir, as you can see ARFC Snapshot passed so at stage 3 of next steps.

11

Hey,

It is positive to have a trusted and friendly entity on the ground working towards DeFi. I expect very similar products will start emerging from regular banks eventually. Will people prefer Horizon over their local KYC bank/trading-app though? competition will get fierce, but at least you have starter advantage.

Since Horizon is a full compliant project, you could explore creating a stock instead of a token, this opens similar funding possibilities without conflicting with the DAO.

Along side Horizon, I suggest you assemble or work-with a full DeFi non-KYC project. This way you make sure you don’t lag out on innovation because of compliance with unfair and slow regulation, while protecting user privacy.

In EVM there is space for centralized tokenized assets and DeFi, is fair to explore both routes.

1 Like
12

Why this proposal hasn’t moved to the AIP stage? @AaveLabs @ACI

1 Like
13

We are still finalizing the Horizon AIP proposal and preparing for launch, as outlined in our previous update. As part of this process, we are working closely with certain RWA issuers to prepare a smooth onboarding experience.

Once this stage is complete, the Horizon AIP will be published with additional information and next steps.

5 Likes
14

TL;DR

With the release of Horizon approaching, this post aims to provide visibility and our opinion to the community (members of the DAO and SPs) regarding the activation strategy intended by Aave Labs, more precisely, in the control roles of the system and code versioning.
In addition to that, we also propose an alternative configuration to consider, which, in our opinion, is more natural towards the goal of friendly forks.


Context: multi-roles configuration on Aave friendly forks

With Aave Labs nearing the release of Horizon, and the team forwarding us to review an Aave governance proposal, we would like to comment with the community on certain implications of the intended approach, which, at least for us, were understood differently during the TEMP CHECK and ARFC stages.

The confusing component arises mainly from the fact that the “Operational” and “Executive” roles defined in the Horizon proposal are not morphologically correct in the current status of the Aave DAO.
The reasons why we think that are the following:

  • As we explain in the post of our approach to friendly forks, the friendly forks framework was very loosely defined, but the substance behind it was relatively clear:
    The Aave DAO at the moment has, in one hand, infrastructure, brand and intellectual property that can allow other entities to use for a price; on the other hand, the Aave DAO has defined historic procedures, know-how and hired entities (SPs), that support the executive arm of the DAO (the AAVE holders via governance) running the ecosystem (Aave pools, GHO, Staking, etc). It is a business venue for the DAO to modularise that, and allow other entities to, under certain conditions, use the first component of tech, brand, and general IP.
  • Assuming a precise framework setup for the previous, it is true that 2 main roles appear in the Aave DAO <> fork relation:
    • The entity with executive power on the fork (we will call it the fork manager going forward). By substance, the entity acting as some type of licensee of the infrastructure and with the power to control and manage the pool.
    • The entity owning the IP of the licensed infrastructure (we will call it the IP owner going forward). In this case, the Aave DAO, allowing the fork manager to use the infrastructure, brand, and other benefits (e.g. this case, the GHO credit line) under certain conditions.

With the previous understood, we can narrow down the unnatural aspect of the previous versus what is defined in the Horizon proposal to the definition of Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals .

This is contradictory to the split Executive/Operational roles in the Aave DAO/protocol context.
Ownership and upgradeability of an Aave pool are by definition , the highest form of executive power in the context of a system like the Aave pools. The reason is straightforward: whoever has control over the upgradeability of the system has full executive control, superseding any other role. It can change the smart contracts’ logic, it can replace any other entity with roles, it can execute the function of any other sub-role, etc.
The whole configuration and strategy around all Aave DAO instances is proof of that, with the governance contract being the executive power of the pools, and then delegating limited operational roles to, for example, the Aave Protocol Guardian for emergency actions, or others like Risk Stewards (implementing constraint logic to change different risk parameters).

Even more, on the whole description of dual roles,

“Operational” and “Executive” responsibilities for the instance. While the Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals), the Executive role oversees risk management, assets listing, and general configuration

there is a pretty strong case to be made that roles are factually reversed: what is defined as “Executive” there is factually operational (management only on the asset and risk side); while “Operational” is factually executive.



The previous could be, in some cases, a minor matter of terminology and nothing else, but in this case, it is, in our opinion, a pretty important topic, with major implications.
To delve into that, let’s dig into some Horizon high-level characteristics:

  • Due to the limitations of the Aave DAO listing security tokens on the instances it directly controls, Horizon separates that from the DAO by establishing another entity, which then uses the aforementioned infrastructure and brand from the DAO. So the entity behind Horizon (the fork manager), actually enters into some type of agreement with the Aave DAO for the usage of its infrastructure and brand, for a price.
    Here, it is obvious that the DAO still having superadmin control on a pool implies that the DAO has control over a pool with security tokens listed. Thus, Horizon becomes a layer purely on the asset issuance, as the superadmin is factually the DAO.
  • Similar to any other case where the IP owner (Aave DAO) permits the use of the infrastructure and brand to another entity, that entity is currently allowed to modify the software however deemed appropriate for their use case. In the case of Horizon, due to the nature of the pool, this is a mandatory requirement, as Aave Labs correctly did.
    At the same time, and as we described in our post on friendly forks’ approach, this customisation, added to the fact that the base version of Horizon is v3.3, makes it not doable for all the DAO infrastructure to support seamlessly. Moreover, aside from simply being an item outside of scopes like ours (BGD), even the review stage of Horizon itself is contradictory: there is no point for entities engaged with the DAO, like us, maintaining a different version (currently v3.5) to have a say on a custom fork.
    This lack of review would be fine if the full control would be on the fork manager, but the moment the pool gets voted via Aave governance, and the Aave governance gets super-admin control, it creates an uncertain scenario where code produced by somebody external to the DAO, not following the latest version of the software, will be voted by uninformed AAVE holders.

Options to move forward

With the previous in mind, we would like to raise different options to be discussed:


Option 1. The first option is to go forward with the proposal of Aave Labs as it is, for the DAO activating Horizon and getting superadmin control. This will imply:

  • The DAO factually gets superadmin control over the Horizon pool, with any liability associated with that.
  • At the same time, a different entity/ies can perform critical actions, such as listing assets, permission participants, configuring oracles, and, in general, everything aside from assigning existing roles on the protocol, and upgrading some core contracts.
  • On our side, we will NOT review the specifics of that instance, due to the aforementioned custom nature.
  • We don’t recommend any friendly fork instance not to use the latest Aave v3 version as a base; same applies naturally to Horizon.
  • In the future, the DAO may need to vote on proposals like upgrades of the Horizon smart contracts. Even if having a decentralize voting engine like the Aave governance arguably adds to the security of the Horizon system, the reality is that the DAO will vote in a system that doesn’t manage in terms of assets and configurations, whose codebase didn’t decide, and which technically could have been partially upgraded in some components by the fork manager (e.g. tokens implementations).
    So the voting via Aave governance becomes a relatively “blind” process, hence, unhealthy.

Option 2. Similar to other friendly forks in progress, Aave Labs changes the control model to the most natural one:

  • Aave Labs is the superadmin of the system in the smart contracts, via official smart contracts of the DAO (PermissionedPayloadsControler & Executor flow).
    The system allows adding any length of time lock, and also decouples permissions-wise submitting candidate proposals from cancelling them. This means that while Aave Labs can be the entity creating payloads unilaterally, they can nominate, for example, a Security Council with different members, to cancel potentially malicious proposals, or any upgrade having an unexpected effect.
    Similar to any other friendly fork, we (BGD) can support both explaining the control model of the PermissionedPayloadsController, and setting it up on behalf of Aave Labs, if required.
  • We still recommend that Aave Labs upgrades the base version to v3.5, instead of using v3.3. Even if by principle we think following the latest upstream afterwards should be optional, we believe that, at the beginning, is a very bad idea. Starting with the latest version as base only benefits the fork manager in the future: being able to reason very similarly to the Aave DAO production upstream contracts, making it substantially simpler to apply any future DAO upgrade on top of Horizon, not skipping versions, potentially being fully compatible with different tooling out-of-the-box, amongst others.
    Moreover, each upgrade of v3 includes improvements, making the codebase more solid, both security and usability-wise.
7 Likes
15

Thank you BGD Labs for the feedback. Though receiving it so close to the release is surprising, given that the proposal has been public for months, discussed widely, and advanced through TEMP CHECK and ARFC votes. Many of the points raised were addressed earlier in this thread and in the first post.

On versioning (v3.3 vs v3.5) and launch feasibility

We built Horizon on Aave v3.3 because it was the latest stable base when the technical work started. The Aave Protocol has been iterating continuously since the initial proposal was drafted. It’s basically impossible to rebase on each release, especially when custom changes are required. Moving Horizon to v3.5 now would mean repeating major engineering work, new security reviews and audits, partner integrations, and end‑to‑end testing. That would likely delay launch by months and put business development at risk. The plan is to move Horizon to 3.5 as soon as possible after release in order to bring it up to speed with the latest protocol version.

On “Operational” vs “Executive” roles

Obviously, we disagree with this interpretation of “executive” vs “operational” roles. A simple google or AI query would easily confirm how our interpretation of these roles is essentially correct. The design delegates executive decisions to centralized, accountable entities (appropriate for this asset class) and assigns onchain operations, specifically smart contract upgrades, to the DAO through ownership of the contracts. This is laid out in the proposal since the first iteration. We believe that the fact that the DAO could potentially exercise executive power, if wanted, has no meaning substantially. Especially with onchain governance, where no single entity can independently decide on whether or not to perform an action. Finally, this creates a much more robust and secure setup as there is no multisig controlling the funds, as also acknowledged by BGD labs.

This is also surprising:

We want to remind BGD Labs that Aave Labs is not “external to the DAO”, it is in fact a Service Provider and active community member. The code produced for the Horizon RWA instance has been reviewed by SPs @Certora and @LlamaRisk , while SPs @ChaosLabs and @TokenLogic were also involved in the project. The Horizon RWA Instance isn’t just a plain, “infrastructural” usage of the Aave Protocol code. It’s strongly tied to the Aave DAO and that was the intention since the beginning, as highlighted by the 50/50 involvement in incentives and revenue share and as approved by the community twice through TempCheck and ARFC.

Next steps

Extensive technical, legal and compliance work has been conducted over the last five months to ensure that the required code changes and the configuration fit the needs of asset issuers and all the parties involved. Making these changes now, either changing the control model or rebasing to a new release, would delay launch by months, compromise the business development completed to date, and put the whole Horizon project at high risk.

We will move forward as planned in the original proposal, and launching on the v3.3 base and setting a clear upgrade path post‑launch with auditors and relevant service providers. If the activation AIP is voted positively, we are open to implement any additional work the DAO may require and to plan upgrades that keep Horizon reasonably close to upstream, with appropriate risk controls and audits. As the Horizon configuration can be also technically changed pretty easily, we are open to re-discuss with the DAO another setup if it’s finally determined that the current approach doesn’t fit the DAO expectations.

We appreciate the continued collaboration from service providers and the community and look forward to delivering Horizon as already approved by the community. We are also looking forward to collaborating with every Service Provider, but we want to ultimately highlight the importance of providing feedback in a consistent and timely manner to avoid disrupting work flows.

7 Likes
16

When leading a project like the case of @AaveLabs with Horizon, and requiring some type of review or feedback on the release phase, it is just natural for that team to simply reach us with the intended configuration approach in time.
This is even more important in a case like a totally hybrid setup, which, all opinions aside, is clearly very different from all other setups currently running on the DAO.

We have no obligation to reach out to other entities for projects we simply have no control or visibility over. This is the same in the other direction: whenever we (BGD) lead a project, it is our responsibility to reach SPs affected/involved; and that is what we have been doing.
For example, we gave Aave Labs both access and as much support as required months in advance of the release of Aave Umbrella, as we understood that they would need enough time in advance to integrate the smart contracts infrastructure we developed into their own user interface.


To give some visibility on the timeline:
Aave Labs reached out to us during what we assume was the configuration design approximately 1.5 months ago, but just with punctual questions regarding infrastructure, like risk stewards. As we always do, we gave our advice and opinion back then, almost immediately, but that was the only interaction regarding the project until 14th August, when the Aave Labs team messaged us to review an activation proposal of Horizon by the DAO.
On 14th August, we commented (again, immediately) to them that the same feedback as previously published, and given their intention was to proceed to the AIP stage as it was, we simply wanted to clarify publicly here the implications for the DAO, and the limits of our involvement; nothing else.

In terms of giving feedback/responding promptly, anybody who has interacted with us during these past years (including Aave Labs) can probably certify how responsive the team is.


Some extra clarifications, though:

  • We didn’t get involved in the initial Horizon discussions because nothing was defined formally; consequently, we assumed the DAO should not be affected anyhow. Once again, it is just natural for the entity designing the approach to simply highlight the morphological differences.
  • We explicitly described 2 different ways forward to not create any type of even perceived blocker for creation, the first (the one we don’t like) simply with the intended approach by Aave Labs; no change. The second proposes a single simple change that can be done very quickly: configure permissions to a different entity, not the DAO, plus the versioning recommendation, which is not even mandatory, as we understand the limitations.
  • Even if not agreeing with the approach, it is not our role to block any governance proposal like this one, so we reviewed the proposal received as of yesterday 21th August, to verify the integrity of the existing non-Horizon Aave systems not getting affected, no matter the inner workings and configuration of Horizon.
  • Regarding not applying the last version before release, that is simply our recommendation, which we actually gave 1.5 months ago, and sustain now. We, of course, understand that maybe this is/it was not ideal for Aave Labs and the go-to-market strategy, but given that the DAO holds control over the contracts, we simply need this to be very clear. If the DAO didn’t, we would not even highlight that.
    Important; we don’t really see any immediate or major problem with Horizon having v3.3 as base, but same as with the rest of the custom codebase on top, we simply can’t give a categorical statement about that to our customer, the Aave DAO, aside from trusting the know-how of Aave Labs.

If an entity has the highest type of control over a smart contract system (upgradeability and roles management), that entity has ownership of the system, no matter if exercised or not.
To argue the opposite is like claiming that because caps are usually managed by stewards’ smart contracts on Aave v3 and not frequently via direct governance proposals, the DAO has no executive power over caps.


We don’t acknowledge that, as our point is that governance becomes simply a time-locking mechanism, so equivalent in practise to the other approach proposed.
Decentralised voting indeed is more robust than a multisig, but with all the extra assurance around that.


The categorisation as external to the DAO has no other meaning than that there is an actor in this context (Aave Labs), that is not a service provider to the DAO, but something different.
If Aave Labs is just another service provider to the DAO even for on the Horizon context, then the following becomes arguably unnatural:

  • Aave Labs unilaterally and privately defined the release date of Horizon, the codebase, the entities involved, any type of agreement (conditions, compensation, incentives) with issuers and other third parties, the security procedures, the branding, and, factually, everything. With the DAO deciding close to nothing on the release and configuration phases, aside from the initial terms of revenue share, the GHO credit line given to Horizon, and the incentives contribution from the DAO.
    This is pretty obviously not a standard service provider relation towards the DAO, different to the scopes where obviously Aave Labs is a service provider, like the Aave v4 development.
  • A revenue-sharing model that does not apply to any other service provider, as it would be akin to ourselves, @ChaosLabs , @LlamaRisk , @ACI , @TokenLogic, @Certora having a revenue share agreement on all the systems of Aave (protocol, GHO); which currently doesn’t seem like the financially beneficial approach to the DAO itself.
9 Likes
17

While at the ACI we’re deeply supportive of the Horizon concept, the proposal in it’s current form has too many unanswered questions and weirdly defined areas.

We do not understand the rush to publish the proposal, especially on a summer weekend. Horizon will likely shine better with v4, which is months away from a production-ready state (we have no idea, as always there’s been very little communication between Aave Labs and other SPs).

As the @ACI is the voice of a substantial and diverse base of token holders trusting us to be their voice, we simply can’t sign a blank check to @AaveLabs with our vote.

Based on our experience over the years working for and then “with” the Aave Labs team, we think there’s a profound cultural incompatibility between how Aave Labs wants to do business and the reality of an actually decentralized DAO that holds every Service Provider to the same standards following the same frameworks.

Maybe the solution is to let Aave Labs do their things on their own with Horizon, they keep all control, have all permissions and simply have them request to the DAO GHO credit lines when needed at cost defined by the DAO via proposals.

We feel the current equilibrium is not a productive match that will satisfy both parties in the long run.

If Aave Labs wants complete control and flexibility in how they operate their own business, they should have it.

The DAO’s job is to make sure GHO is at peg and the ROI of financing and providing an initial subsidy for the horizon product makes sense.

ACI will vote no on this proposal in its current form.

We are happy to switch to supportive to a refined version of the proposal.

9 Likes
18

This is from a LP/Aave token holder’s perspective.

As a community member, we have witnessed ACI brought some proposal when discussion is still on-going and not even follow the procedures outlined.. We do not understand why putting up at weekend is a problem.

The horizon discussion has been on-going for quite sometime and definitely is not a blank check. This is especially true when comparing to various initiatives that leads by ACI then quick went into vote. A good example is the recently GHO incentive program.

10 Likes
19

First of all I supported the proposal as a delegate, but I do think there are elements that are specifically targeting other SP and that have been raised, for example by BGDLabs.
The comment made, in my opinion is valid even if Aave Labs, thinks it was too close to the release, because there was no clear timeline given when Horizon will be released and reassessing a proposal is nothing unusual and should rather be seen positive. That’s a positive sign of activity and attention, especially in this case attention to detail about the “operational and executive roles” for Horizon.
As a delegate I have not been focusing on this part, because I am simply not that much involved, but given that SP have a different job and thus view on this proposal, its only fair to raise these concerns/questions.
I wish that Aave Labs would inform other relevant SP upfront, even if in private chats, because of sensitive information that a competitor could use.

It is crucial to be transparent within the DAO to make sure we keep our edge in the lending vertical and that everyone is working together as a team and not as a single entity within the DAO.
Onboarding RWA is the next major step and I think everyone agrees, but we need to make sure everyone can work towards this integration and fully understand their roles, because if not it will be a rough start, just like the DAO had with GHO when the code was released but literally no plan was there on how to move with it to the market. It was a huge joint effort to grow GHO which could have been avoided. Lets not repeat the same mistake, but rather learn from it.

Additionally the idea from Marc regarding the GHO credit line could be interesting if Aave Labs wants to explore this.

There is nothing else to say besides Just use Aave.

8 Likes
20

I will be voting no, not because I disagree with Horizon as an initiative, but because I believe the proposal in its current form risks dividing the DAO when it should be a unifying step forward.

The edits made: no Horizon token, a fair 50/50 revenue split, and GHO integration, are real improvements. Still, as bgdlabs and ACI said, there are unresolved concerns around governance structure, versioning, and process.

I understand that Horizon timely launch is important from business perspective. But the concerns raised are not minor detail. And as EzR3aL said, “given that SP have a different job and thus view on this proposal, it’s only fair to raise these concerns/questions.”

So my vote is not meant as opposition to Horizon, but as a call for reunification: to clarify roles, publish a roadmap for upgrades, and improve coordination before activation. This could be done in a timely manner (perhaps weeks?)

Horizon should be a win win, and after having agreed on MAJOR concessions, the final mile of alignment would have made the DAO stronger.

Edit: I removed the part on delegation after learning that my voting power comes from other token holders, not directly from BGD Labs or ACI.

7 Likes