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:
- Aave Labs wanted to signal (and doing it) as soon as possible that they don’t agree with the principle.
- 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
: “Aave App” as a mobile app, clearly perceived by everybody as “the official” Aave mobile app.
Correct actions
: “Ghost (just example) App by Avara Labs” as a mobile app, not creating any confusion.
Operational blockers
: 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
: “Aave Labs” is clearly perceived by everybody as “the official” development company building on Aave.
Correct actions
: “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
: 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
:
- 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 
- 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
: 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
:
- 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
:
- 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
: 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
:
- 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
:
- 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
: 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.