[ARFC] $AAVE token alignment. Phase 1 - Ownership

The Snapshot vote has wrapped up, and it has raised important questions about the relationship between Aave Labs and $AAVE token holders. This is a productive discussion that’s essential for the long-term health of Aave.

While it’s been a bit hectic, debate and disagreement are features of decentralized governance.

I want to state clearly: I am committed to making the economic alignment between Aave Labs and $AAVE token holders more clear. We haven’t done a great job explaining this and will do so going forward. Another thing that’s gotten lost in this conversation is that the DAO has earned $140M this year, more than the past three years combined, and $AAVE token holders have control over this treasury.

In the future, we’ll be more explicit about how products built by Aave Labs create value for the DAO and $AAVE token holders.

I also want to address my recent $15 million purchase of $AAVE. These tokens were not used to vote on the recent proposal and that was never my intention. This is my life’s work, and I am putting my own capital behind my conviction.

Lastly, the Aave ecosystem is large enough for many service providers to succeed, and we will continue to support and collaborate with teams building on the protocol. I am confident that by working together, we will build a stronger and more aligned future.

$AAVE will win.

18 Likes

For the record, I voted Nay in-line with my previous posts.

I think @MarcZeller’s framing in this thread is materially biased, both before and after the vote. That shouldn’t go unnoticed, especially given ACI’s position as one of the largest delegates.

First, the “storefront vs engine” analogy is simply misleading. The core revenue engine of Aave has never been the UI monetization. The dominant revenue stream has always been the reserve factors at the protocol level, independent of who operates a frontend. The controversial UI fees created value primarily because users adopted it, not because it diverted economic rent away from the DAO. Treating this as a structural extraction problem misrepresents where value is actually generated (thanks to the whole bunch of SPs - including AL - as detailed in his post).

Second, the post-vote interpretation is selective. The Snapshot result was a clear rejection of the proposal: ~55% NAY, with one of the highest participation levels Aave governance ever. Reframing that outcome as “lack of endorsement of the status quo” is done in bad faith. A share of ABSTAIN votes were explicitly about process, timing, or escalation path, not opposition to Avara - like @TokenLogic. That distinction matters, and blurring it conveniently serves a narrative that did not win.

Third, governance legitimacy cuts both ways. Record turnout strengthens the outcome, it does not weaken it. After such participation, continuing to imply manipulation or bad faith from Stani or Emilio is not only unproductive, it’s irresponsible. If we want to defend good governance, we should also be willing to retract serious accusations when the data contradicts them.

I don’t understand why Marc contributes so much value on one side, then undermines it with this kind of narrative warfare on the other. My two cents: if you want a DAO-owned frontend, go build it, get funded, and compete on merit. It’s not that hard.

6 Likes

Hi Folks I hope everyone has had an enjoyable holiday period where ever you are in the world.

I deliberately stayed out of the original debate, as many of my arguments were being articulated very well by other contributors but read the discussion assiduously.

It is evident that Avara/labs have been and continue to integral to Aave’s success. Their technical leadership, vision, and continued investment are widely recognised. At the same time, there is a shared acknowledgement that communication can and should improve, and . addressing the key concerns raised—especially around decentralisation optics, DAO authority, and long-term alignment—will be essential to maintaining confidence.

Equally, the Aave Chan Initiative (ACI) has demonstrated a strong and consistent commitment to the DAO. However, as with all stakeholders, there may be value in reflection on how positions are communicated and how escalation is handled during sensitive governance moments & I speak as being one of the earliest delegates to Marc/The ACI.

Ultimately, all parties share the same goal: what is best for Aave. Achieving that requires constructive engagement, respect for all voices, and a collective effort to keep debate civil, transparent, and solutions-oriented. If approached in this spirit, this discussion can strengthen—not divide—the Aave ecosystem and set a healthier precedent for future governance decisions.
So come on folks as this is the season of goodwill let us continue the debate but remain civil to all parties and collectively drive Aave forward to dominance in both Defi and tradfi

10 Likes

Marc certainly has his biases, but the vote was a farce. Short notice, Christmas week, and without any discussion with the author of the proposal, who has said he would not have submitted this proposal as is.

It hasn’t settled anything and the author should have the opportunity to revise and submit their proposal as they intend it to be submitted, as is the normal process for governance.

8 Likes

Whilst I applaud any founder buying tokens, its a bit easy to claim you never intended to vote those tokens after the vote, when you know they are no longer needed to get a majority. Given the timeline and events it seems very likely they were purchased as back-up, or to vote. Otherwise, you would have stated from the beginning you wouldn’t use them to vote. Especially after so many people critized the clear conflict of interest on voting on this matter for you. With a majority shareholding in Avara (direct beneficiary of vote outcome here).

Can you please be transparent about which (and how many) tokens you did vote with? Because you own a lot more tokens than just the purchased amount

Further, can you please disclose the captable of Avara? This is essential information given the conflicts of interest that may exist.
The DAO should stop funding Avara if it’s not disclosed.

Lastly, can you, with Avara, please bring forward a proposal that addresses the alignment issue raised by the community? You say you care about alignment, but not with the current proposed method, then please bring forward a structure and timeline that work for Avara. Because the current status quo does not work for 90%+ of the community (going by voters and sentiment here and on twitter - seems roughly 9 in 10 posts are in favor of this proposal, and 9 in 10 votes was).

4 Likes

The vote followed every rule and the voters chose the status quo. Anyone can propose a new vote including a vote on new voting rules.

It certainly has highlighted that the rules for governance votes are flawed. People should not be able to submit votes on behalf of the author without the author’s approval.

Aave has tended to have looser on governance processes, trusting more in social norms(unlike say MakerDAO, which has very detailed explicit rules for things like voting). Maybe that will need to change.

4 Likes

Sure, I’m all for two competing frontends and letting users decide. But as long as one is accessible via aave.com, it will naturally be perceived as the official/default option, giving it an unfair advantage in user acquisition. If the goal is true merit-based competition, then the domain shouldn’t be what determines the outcome.

12 Likes

The lessons DAO needs to learn from this incident include:

  1. As the proposal initiator, they should be familiar with basic governance processes. It seems that directly submitting this proposal to the ARFC was inappropriate.

  2. Major decisions and proposals involving AAVE should be discussed jointly by the DAO, service providers, AAVE Labs, and token holders, balancing and coordinating the interests of all parties to arrive at a mature solution. This requires detailed plans, specifics, and analysis of the impact.

  3. Why could the proposal be submitted for voting without the applicant’s consent or any modifications? Why could AAVE Labs unilaterally push through the vote? This indicates loopholes in the DAO’s governance process. Should these processes be optimized and adjusted?

  4. AAVE Labs has repeatedly infringed upon the DAO’s interests. This vote, conducted without communication with the proposal initiator, once again exposes AAVE Labs’ ugly face. AAVE Labs can disregard the interests of everyone. Given their large voting power and lack of ethical boundaries, should AAVE Labs’ voting rights be removed from the voting process?

  5. AAVE DAO also needs to improve its management, communication, and coordination capabilities. Did ACI seem confident of victory before? We must be well-prepared before acting; we must act as if we were overthrowing a dictator; we must unite all forces that can be united.

This whole discussion only highlighted how immature the DAO is, even as regarded as one of the strongest and most resilient ones in DeFi. None of the parties involved (BGD, ACI, Aave Labs) has had a constructive exchange and the tone of some has just been aggressive and too populists. It felt like an open policy debate, with the opposition attacking the officialism. I honestly don’t buy “the evil dictator” Stani and “the man of the people” Marc.

I’d expect that privately, their discussions are more constructive and this whole show is only what happened publicly, which ultimately is not the right approach and only damages the image of Aave as a whole.

Next step should be BGD and ACI proposing a concrete plan, not just we seize the IP and give it back to the people and then we see what the hell we do with it in Phase 2.

4 Likes

During the last weeks, I have been reading the opinions of the community on the proposal, observing the points of view of external entities regarding the original topic, talking with different parties on both the rationale and execution of the principles to be voted on in my original proposal, and last but not least, thinking deeply about the topic.
In this post, I address various feedback topics and outline precise next steps.

But to summarise: I don’t think a new proposal vote is needed, because everything that happened last weeks and the proposal of December 22nd actually brought total transparency on the status quo of Aave.


The “form” of the proposal

First, it is important to mention that using ARFC was not just some type of random decision, but a (right/wrong) thought one.

Why ARFC to start with? Because it was really a request for comments, applying feedback afterwards, and finally followed by a vote by AAVE holders. And because ARFC is quite a “neutral” known governance step.

Is a TEMP CHECK also reasonable? This proposal probably could be a TEMP CHECK. Given different productive feedback, I would have no issue with recategorising it, because the proposal can be understood as signalling: this is the position of the Aave DAO in respect to the proposal content, the DAO will move to make that position factual. Still, also every entity affected should move proactively if it wants to abide.

Why is an AIP with just extra discussion time and a feedback loop (compared with a governance framework) also reasonable? Because this is a very major and foundational topic, and there is no real limitation to just doing an extensive discussion first and then voting about it.

Why is on-chain voting better? For multiple reasons, amongst others:

  • Aave voting is currently free, meaning that participation has no barrier.
  • On-chain proposals have a higher degree of “formality” because they stay on the blockchain forever. On foundational/principles voting, I believe it is better.
  • Aave on-chain voting takes a snapshot of balances at voting start, not proposal creation. This sounds like a technicality, why is it important? Well, on Snapshot Aave’s space, the snapshot of balances is done at creation, and that means that for example on the proposal submitted Dec 22nd, whoever didn’t know in advance the proposal would be created (basically any non-Aave Labs, the creator), if having assets in non-voting venues like CEXes, didn’t have a chance to move out to vote. They were left out.

All governance frameworks on Aave are to be flexible, within measurable limits, especially on non-operational topics. Multi-steps are required/stricter on operational topics, because different work streams need to be synchronized; governance steps act as an anchor.
This type of proposal involves discussion, feedback, and voting, with reason in the mix. The rest is bureaucracy.




The sudden proposal submission and outcomes

Currently, I don’t even think it makes too much sense to repeat the same topics again about the sudden proposal creation on the 22nd. Submitting the proposal I initiated without any sync if it was ready/appropriate, and without even warning the community to prepare assets for voting, speaks for itself.
To claim “it is how governance procedure works” is either delusional or trying to mislead people not having visibility about procedures. Also, to defend that it happened sometimes in the past with Skywards by ACI, is the sadly typical strategy nowadays of using ACI as some type of scapegoat when argumentation is empty.

Now, some points I would really like to highlight on the proposal:

  • Due to the dubious decision of submitting the proposal in its initial stage, the vote, regarding content, was totally chaotic. Meaning that some entities voted NO because the initial proposal had no feedback or clarifications addressed, some entities voting YES did it without the proposal really being the final proposal (so losing quite some meaning), and only ABSTAIN was seemingly a realistic vote because the rationale decision is “this proposal is non-votable in the current shape, unless I categorically don’t care about content”.
  • A bit of relatively interesting data on the votes themselves:
    • Approximately ~1200 addresses holding voting power and voting directly or delegating participated in the vote. Out of those, ~1060 participated with ABSTAIN, ~90 with NO, ~30 with YES.
    • Only by checking public sources (e.g., Etherscan), it is relatively simple to create clusters of the previous voting power and options voted. With clusters defined as addresses holding voting power probabilistically connected between them (e.g., same group associated with them). It is important to highlight that an address receiving delegation from multiple voting power holders doesn’t create clustering, unless the delegators are somehow connected (e.g., organisationally).
      • YES and ABSTAIN have very little address clustering. Meaning the majority of voting power holders are not really connected. So many hundreds of individual holders (of all sizes), if not over a thousand.
      • NO is heavily clustered. More precisely, out of the 994k NO votes, 600-700k seemingly belong to one single cluster surrounding Aave Labs or related individuals. This information is only based on public resources, so happy to be corrected about it.

Voting is, at the end of the day, the decision-making mechanism and should be respected. At the same time, we are fortunate that the system is relatively transparent, hosted in a pseudo-anonymous blockchain.

So the previous aspects (participation, clustering, or the “sudden” proposal submission) actually created what I think is a very interesting twist on what was really voted: the proposal of Dec 22nd was a manifestation of:

  1. Aave Labs wanted to signal (and doing it) as soon as possible that they don’t agree with the principle.
  2. A big majority of holders by count signaled that the proposal, as it was, was not votable/ready. But at the same time, massively participating and in practice saying “yes, there is a big problem with the status quo”.



Lack of an explicit and detailed plan

I definitely agree that this proposal would be the first of different execution steps, but it actually is pretty precise in my opinion, for what it is: setting up principles. And the problem with being overprecise in a principles statement is that it only creates rejection by over-detailing. E.g., if you have a constitutional document, and one argument to discredit it is not having an extensive list of operational implementation of each of the points in the document, you enter into a paradox.

Now, this proposal is way simpler than any foundational document, more akin to establishing a high-level principle or entities to abide by. For example (this is a totally virtual, for the sake of example), it is similar to having a proposal vote saying “from now on, everybody engaging with the DAO can’t work with competitors of Aave”. That type of proposal has pretty much the same characteristics as mine, said:

  • The DAO doesn’t initially enforce anything, but clearly signals something that should be proactively respected by entities engaged/seeking engagement with the DAO.
  • If desired (usually if observing that other governance mechanisms don’t work), the DAO can do further movements on having more practical mechanisms to actually enforce the principle, in this example, having some type of legal vehicle to control the non-competition.
  • There is basically zero friction: entities’ engagement with the DAO should simply abide by the principle, but they should have just enough room to do so. First, via follow-up proposals to establish more precise limitations, or second, by modifying their engagements to reflect the reality.

My point with the previous example is that in the case of assets and the brand, it is the same. Entities holding a brand and assets can:

  • First, try to abide by or not by the principle. If not, then it is on the side of the DAO to decide how to categorise the entity and act afterwards towards it.
  • If trying to abide, there is no need to disrupt operations to make totally radical changes. E.g., an argument of “well, the DAO has no legal vehicle to hold ownership and delegate management of communication channels; so introducing the principle means we should just stop managing them and hurting Aave” is nonsensical and unreasonable.
    The correct way to do it is to apply the principles of management, and then progressively, in coordination with the DAO, make the principle factual.

But in any case, to avoid the perception of “there is not really any plan, it is castles in the sky,” and especially that the post-principle execution is not doable, this is a list of what I think could be potential “execution” steps.

I want to make something extremely clear, though: these steps are NOT what would get voted. What would get voted is just a principle, which I now simplify even more:

The Aave DAO (AAVE token holders) owns Aave’s brand, naming rights, and associated assets. Any third party currently controlling these assets should steward them without private interests involved, and proactively make changes to reflect the ownership in practice.*


To be executed/initiated by external parties

  • “Aave” products naming. No entity should name products in a way that will be implicitly perceived as “the official” Aave.

    Incorrect actions :cross_mark:: “Aave App” as a mobile app, clearly perceived by everybody as “the official” Aave mobile app.

    Correct actions :white_check_mark:: “Ghost (just example) App by Avara Labs” as a mobile app, not creating any confusion.

    Operational blockers :white_question_mark:: None, everybody can unilaterally implement basically now.

  • “Aave” companies’ naming. No entity should be named in a way that will be implicitly perceived as “the official” Aave company.

    Incorrect actions :cross_mark:: “Aave Labs” is clearly perceived by everybody as “the official” development company building on Aave.

    Correct actions :white_check_mark:: “Avara Labs” doesn’t create any confusion, and still allows talking in very legitimate terms like “The Aave team from Avara Labs”, “The Aave pod from Avara Labs”, etc.

    Operational blockers :no_entry:: None, everybody can unilaterally implement basically now.

  • Non-private usage of “aave” domains. Not using clearly perceived as “official” domains for clearly private purposes, either direct monetisation or spotlight promotion of private products.

    Incorrect actions :cross_mark::

    • On aave.com, focusing on spotlight areas (e.g., beginning of landing) on private products promotion, like currently happening with the “Aave app”.
    • On documentation places like docs.aave.com, redirect integrators to use private infrastructure, which implicitly gets perceived as “official”, e.g., on Earn the vaults by Aave Labs.
    • Use app.aave.com for private monetisation, without consulting AAVE holders in advance, and especially if placing the DAO in very fragile scenarios. E.g., the “CowSwap features” scenario, or the upcoming v4 UI seemingly not owned at all by the DAO or having any say about it.

    Correct actions :white_check_mark:

    • Use aave.com to promote the Aave DAO main products (e.g, protocol metrics) and give meaningful visibility to all ecosystem applications. For example, an idea would be having rotational exposure to ecosystem participants, if they are fully aligned with Aave (e.g. third-party applications not promoting Aave competitors).
    • Fully neutral documentation, exclusively Aave DAO products. That doesn’t conflict with having a section with links for documentation on contributors’ products, but separately.
    • Manage app.aave.com as a totally neutral steward, completely focused on maximising Aave DAO’s interests. E.g., proposing a contract for maintenance of the software with terms in the majority favour of the DAO’s interests, no matter of having any bonus clauses or other terms. If that is not attractive, allow for other teams to host applications to access Aave in the most favourable terms for the DAO in app.aave.com.

    Operational blockers :no_entry:: None really. The entities currently having access control ownership on the domains can keep operating the same, but following the policies.

  • Fully neutral stewardship of “aave” online organisations. GitHub, npm, or any other similar one should be managed by the steward in a totally neutral manner, never including private projects having direct/indirect monetization.

    Incorrect actions :cross_mark::

    • Assuming “aave” is to be used neutrally, the GitHub organisation does not contain private projects that are not “DAO owned”, no matter the contributor.
    • “aave” npm should not include any type of private project not directly benefitting the DAO, but should include all those packages “supporting” Aave subsystems.

    Correct actions :white_check_mark::

    • Using “aave” GitHub as an organisation where different contributors are owners of different projects, and all of them are Aave DAO-controlled. For all other private projects, they should be in separate organisations like “bgd-labs” for BGD, “aave-labs” (naming aside) for Aave Labs, etc.
    • Apply the same policies as on GitHub on npm.

    Operational blockers :no_entry:: None, everybody currently having superadmin control on the organisations can keep operating the same, but following the policies.

  • Fully neutral stewardship of “aave” channels. Only products of the DAO (or those private ones respecting the previously defined policies), growth data, DAO-sponsored events, etc, should be promoted by official communication channels.

    Incorrect actions :cross_mark::

    • Direct promotion of products as “official” Aave, even if private. And even worse if they are not respecting the proposed naming policies (e.g., promoting “Aave App”).
    • Promotion of official “visions” and other messianic-like unilateral roadmaps. Even worse, when factually part of those visions directly imply private benefit.
    • Use communication channels to promote private events.
    • Use the channels to announce partnerships with “Aave”, when not being approved by the DAO anyhow, or even in some cases being the private entity controlling the channel that actually partners, not the DAO.

    Correct actions :white_check_mark::

    • Give visibility on protocol/Aave DAO product growth, in line with several communications of “aave” on X.
    • Give visibility to official partnerships of the DAO, in line with some of the communications of “aave” on X: networks where Aave is, product developments of assets listed on Aave, product developments (no matter if private) of long-term partners of Aave, etc.
    • Give neutral visibility to major governance proposals and debates, really highlighting the value and decentralised activity.
    • Create separate channels for private endeavours, e.g., using “avara” on X to promote private products, or each product handle. No matter if then giving ad-hoc sporadic visibility on “aave”.

    Operational blockers :no_entry:: None, really. The entities currently having access control ownership on the domains can keep operating the same, but following the policies.


To be executed/initiated by the DAO

  • Engage an external entity to expand on the specifics of the previously defined “to be executed by external parties”. It is a typical process pre-engagement, but the firm should not have any type of conflict of interest, and act with full transparency on what answers they get whenever they require information from all parties involved.

  • Engage an external entity to neutrally evaluate the claims of the DAO over all assets requested and publish a memo about it. Same as previous, full transparency and no conflict of interest.

  • Engage an external entity to create a structural vehicle to be the holder on behalf of the Aave DAO governance contracts of assets that require legal ownership (domains, online organisations, etc). Having discussed with experts in the field for this, it is definitely a doable process, and could very perfectly respect the following principles:

    • The vehicle should NOT be an “incorporation” of the DAO. The DAO is decentralised and solely governed by on-chain AAVE voting, and should stay the same. This vehicle should have absolutely no control, influence, or liability in the Aave on-chain ecosystem.
    • The vehicle should have extremely limited responsibilities and powers, as commented, mainly holding different assets, but always following previous mandates via on-chain Aave governance proposals.
    • Management of those resources by “steward” parties is something that could/should be contemplated and allowed in the foundational documents of the vehicle, for management to be operationally efficient as currently. The vehicle should, however, enforce mechanisms of control and supervision to, or directly avoid malpractice by the steward, or to at least be able to publicly point those out and the Aave governance taking a decision about it (e.g., replacing the steward).
      What this means in practice is that all assets will still be managed by third parties (e.g., Aave Labs), but with certain rules and supervision by the owner (the DAO via its vehicle).
  • Going forward, start evaluating more critically/strictly proposals with compensation (e.g., SPs, funding of projects, funding of events). E.g., if a project delivered doesn’t include all the necessary infrastructure for the DAO to not get blocked if it doesn’t want to continue working with the counterparty (e.g., smart contracts, minimal interface if the system is user-facing, usage instructions), it should not even be considered. The rationale of this is very straightforward: yes, smart contracts should be designed for external parties to build tooling for users to interface with them, but subsidising the production of those contracts with no basic interface/access tooling creates an inherent vendor lock-in.

    Or if a sub-system of Aave favors/creates setups with implicit principal/agent problems, it should be carefully evaluated before starting it.
    It should be simply mandatory not to create any type of future conflicts in engagements before starting, because later on it will be very problematic to solve.




Once again, those previous “actionable points” are just examples of what can be done if the ownership principles would be accepted, and a showcase that they are feasible. But the proposal content does NOT include them, only the principle.




Some extra thoughts

This proposal and what has surrounded it can appear as creating some type of chaos, being aggressive, etc. However, what it has really led to is substantially more transparency, which, in my opinion, is net positive.


The reality of the DAO is the following:

  • As commented here, Stani/Aave Labs believes that pretty much no innovation has happened on Aave in recent years, and the future depends on products (Aave Labs’s mobile App, Aave Labs’s Horizon, Aave v4), of Aave Labs, some of them are only partially benefiting the DAO (app and Horizon), and the other unilaterally proposed and moved in a non-collaborative environment as what’s next for Aave. And to be clear, collaboration is not: “this is what is going to be done, like it or not, anybody can happily participate with ideas and contributions, we take the budget and credit”. That has different names, but definitely not collaboration.
    Leaving aside that it is pretty disrespectful to qualify the last years of Aave as having no innovation (I really don’t even think it deserves counterarguments), it is an opinion, but one that creates organisational centralisation, directly and indirectly. Aave has been improving and innovating through continuous work, and the issue by claiming the opposite is that whoever does it 1) doesn’t understand it or 2) doesn’t want to make it appear as such on purpose.

  • Aave Labs very clearly signalled that they don’t agree with the high-level principle of exclusive ownership by the DAO, and even more, accelerated the process unilaterally to pretty much shut it down, not only rushing the Snapshot creation, but by seemingly being directly/indirectly the party that factually moved the vote outcome to NO.

    Once again, governance is governance, and leaving aside the legitimacy of the vote, what it really showed is that Aave Labs will only move into the DAO ownership direction in its own terms; once again, organisational centralisation.

  • A point of feedback, both internally and externally to this forum, is some kind of “the least bad solution”: if the DAO and AAVE token holders don’t accept the position of Aave Labs, maybe they stop contributing, and that is bad.
    I think there is a piece of the puzzle that is missing here, and I would want to be very explicit about it: the current situation is unsustainable and goes against the interests of every contributor aside from Aave Labs. Everybody knows it, everybody voices it in private channels, but only some are willing to put it public.
    The damage of going in a direction of organisational centralisation is going to be important. The trends that this will create are 1) some contributors will just stop doing it on Aave, as becomes clearly and transparently miss-weighted to the benefit of a private party, or 2) some entities will adopt a pure mercenary mentality like “well, there is not really a fair ground of contribution with one entity getting indirectly higher benefit not based on merit, so there is no reason for us to go the extra mile on anything”.
    It is up to everybody to make their own analysis and assumptions of what an environment like that means.

  • There is a constant polarisation of the DAO vs Aave Labs, sometimes even portrayed as ACI vs Aave Labs, or others. While I understand that, unfortunately, polarisation is the world we live in, it is total nonsense.
    The reality here is that “the DAO” is not some shadow committee making decisions, while being non-productive and parasitic. There is nothing like that; the whole Aave is on-chain controlled, and if implying that this “shadow committee” is somehow a bunch of Service Providers, it is even more nonsensical, as precisely all non-Aave Labs Service Providers have close to zero asymmetric weight.

    The Aave DAO is $AAVE and its holders at its core, and that’s it. Then that core is surrounded by a large ecosystem of infrastructure, entities, or other participants.

    Now, whenever somebody raises a “tricky” topic publicly that is problematic for some, well, it is called transparency.




So, next steps?

After my previous lengthy points, here is what is next from the side of my proposal.

After thinking it through, I think there is not much reason to do any extra voting. The vote objective was to give decisive clarity on a principle, but clarity that depends on other entities to proactively do something about it.

Yes, the vote on 22nd December, in my opinion, was not legitimate in its high-level nature, but actually the vote really had an unambiguous outcome: Aave Labs said, “we don’t like that, we will not abide by it, and we will define our own terms”. While I think that is not good for Aave overall, well, at least for me, it tells everything I needed to hear.

Now, something I really want to be very clear about. Stani mentioned in its “Vision” post about collaboration and values. There is no ground for collaboration and values whenever that is a one-direction venue, on the terms defined unilaterally by one entity with self-assigned authority. Collaboration is highly based on trust, and trust is gained with actions, facts, and acting transparently.

Hopefully, the discussion itself and the transparency brought to the table will bring value to Aave and the DAOs and DeFi ecosystems.

29 Likes

Thank you @eboado for the concise and thoughtful summary.

At this point, it’s fair to say this ARFC discussion has achieved its main purpose: CLARITY.

The different positions are now well understood, and the key open questions are no longer about debate, but about follow-through.

As outlined in prior comments, there are two concrete areas where follow through was promised by Aave Labs:

  1. The planned fee changes referenced here (https://governance.aave.com/t/velora-cowswap-integration-analysis/23620/11?u=josuempia)

  2. The Aave Brand direction and commitments discussed here (https://governance.aave.com/t/how-aave-will-win/23792?u=josuempia).

For that reason, I believe this thread has largely run its course and can be closed.

Eboado has already done a thorough job summarizing the key takeaways including where ownership and stewardship currently sit, the practical limits involved, and the range of positions around a DAO-first principle. Any meaningful next steps can now proceed based on that shared clarity.

We now wait for @AaveLabs structures in their upcoming proposals.

5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.