ARC: Extend Aave DAO with EIP-4824

Governance
1

Simple summary

The EIP-4824 standard defines common interfaces for DAOs via daoURI, akin to tokenURI for NFTs. This proposal will upgrade Aave DAO to EIP-4824 by deploying a new registration contract through a contract interaction with the EIP-4824 factory maintained by DAOstar.

Rationale

Adopting the EIP-4824 standard will enrich the on-chain information availability of Aave governance contracts, making it easier for existing and future DAO tools to seamlessly interact with the contracts. A specific example is enabling members to interact with the Aave governance contracts through different front-end interfaces, potentially across multiple chains. Some of the tools that are digesting or committed to digesting this enriched information include Snapshot, Tally, DAOhaus, Etherscan, DeepDAO, and other members of DAOstar One.

Note that adopting the standard does not require any parameter changes to Aave’s existing DAO contracts, nor is there any cost besides gas to call the factory contract. To make the process easier, we have already built and deployed 4824-compliant subgraphs for the component endpoints of daoURI, including membersURI, proposalsURI, and activityLogURI. What remains is for Aave to claim these off-chain endpoints via the on-chain process specified by EIP-4824. The proposal does not in any way change the way that Aave’s governance works.

DAOstar is a public goods project supported by the Ethereum Foundation, Gnosis, Aragon, Radicle, MolochDAO, MetaCartel Ventures, The Graph, and many other members of DAOstar One.

Governance action

By voting yes, you agree that Aave DAO will (1) upgrade to EIP-4824 by calling the EIP-4824 registration contract located at 0x37df3fc47c1c3a2acafd2dad9c1c00090a8655bc, with Joshua Tan of DAOstar/Metagov (thelastjosh.eth) as the temporary manager for the registration contract. No funds will be transferred.

By voting no, nothing happens.

Technical details

To simplify adoption, we have pre-built the subgraphs and endpoints for Aave DAO. The endpoints can be edited at will by the selected manager, or by another vote of the DAO itself. For example, here is a live endpoint serving 4824-compliant data for Aave.

EIP4824 Registration Factory Contract

Each registration contract contains the registration metadata for one single DAO.

Registration Metadata

The registration contract exposes a daoURI view function which returns the URI containing the EIP4824 compliant registration JSON document.

Roles & Access Control

Upon deployment the registration contract is initialized with a DAO address and an optional manager address. The DAO address should be the contract that has the ability to execute arbitrary on chain transactions as instructed by the DAO members through the governance process. For Aave, this is the (Level 1 short timelock) Executor contract on mainnet at 0xEE56e2B3D491590B5b31738cC34d5232F378a8D5.

Admin Role is granted to the DAO address on initialization. This role allows the address to grant and revoke roles.

Manager Role is granted to the DAO address, and an additional manager address if the value is set in the initialization function. This role allows the address to update the DAO URI but not to modify roles.

Deployment Details

The registration factory contract is deployed to nearly all EVM chains. The mainnet address is 0x37dF3fC47C1c3A2acaFd2Dad9c1C00090a8655Bc. The factory uses a clone proxy pattern with a template registration contract deployed to 0x4aCd31Edc93adB1Cf08FFBCf4097bd61f4A824f6. New clones are deployed to predictable addresses using the message sender and a bytes32 value combined as a salt.

Transaction Details

The proposed transaction involves single contract call that summons a new registration instance and sets the initial DAO URI.

Simulation Results

Given a salt of 0x42 and a msg.sender of the Aave executor, the registration contract is deployed to 0x48969eefc31ce514030faf719d72118b875f1154.

Risks

The proposal is extremely low risk. It involves calling a factory that will deploy a new, standalone registration contract on behalf of Aave. The sole purpose of that contract is to publish a daoURI field on behalf of the main Aave DAO contract(s).

Team

DAOstar, the coalition of organizations that authored EIP-4824, is led by Joshua Tan, executive director of Metagov and Isaac Patka, summoner at Moloch, with support from Michael Zargham (CEO of Block Science), Eyal Eithcowich (CEO of DeepDAO), Fabien (CEO of Snapshot) and Ivan Fartunov (head of partnerships at Aragon), Kei Kreutler (co-founder of Gnosis Guild), Auryn Macmillan (co-founder of Gnosis Guild), Primavera De Filippi (researcher at Harvard/CNRS), and many others.

Current EIP-4824 DAO Frameworks

  • Moloch v2 / DAOHaus
  • Moloch v3 / DAOHaus
  • Gnosis Safe
  • DAOstack
  • DAODAO (Cosmos)
  • Superdao
  • KALI
  • And others

“DAO DAO is an enthusiastic supporter of the the DAOstar standard, which is making all DAOs more legible and composable regardless of which DAO tools they choose to use!" - Jake Hartnell, Founder of DAODAO

“EIP-4824 is necessary to make DAOs standardized and interoperable.” - Superdao (Twitter)

Conclusion and Next Steps

This proposal will upgrade Aave DAO to EIP-4824 by deploying a new registration contract through a contract interaction with the EIP-4824 factory maintained by DAOstar. It is extremely low risk, benefits Aave DAO by upgrading it to the ecosystem standard, and also positions Aave as a leader on standards for the ecosystem.

As next steps, we will be hosting community discussions in this thread and on Twitter/Zoom over the next 5+ days. This will be followed by a Snapshot to gauge community sentiment. If approved via Snapshot it will go to AIP for an on-chain vote.

3 Likes
2

Hello @thelastjosh and thanks for your proposal.

the Aave governance contract are the essential infrastructure in control of the Aave protocol, while we understand the potential benefit of your proposal,
The ACI won’t form an opinion before extremely careful consideration of the technical implications and expected consequences of this AIP project.

Any issue would mean devastating consequences for the Aave protocol and this is clearly not a proposal that should be considered lightly.

We understand that the EIP-4824 have been in some form battle-tested, but this is certainly not a decision that can be taken lightly in a few days.

We are keen to hear from opinions on @bgdlabs & @AaveLabs tech teams on the proposal.

1 Like
3

Interesting proposal @thelastjosh , and as you point out, there should not be any risk for the DAO doing the call to the registration contract.

We would like to point out that it is probably better to avoid delegation to a multi-sig, just boiling down to make governance proposals whenever any “metadata” needs to be modified for the DAO.
Which kind of admin actions could be required in the future?

2 Likes
4

Hey @bgdlabs ,

So there are only two actions possible in the registration contract: (1) changing daoURI itself, which belongs to the manager role and (2) changing the role structure, i.e. replacing the manager or adding new admins, which belongs to the admin role. (So technically Aave DAO would possess both the manager and admin roles in the contract, so it can both set daoURI directly as well administer roles.)

Having the multisig as an additional admin is mainly intended to be a convenience for Aave. It allows us to avoid invoking full DAO governance every time the manager needs to get replaced. If the multisig governance is problematic (e.g. because it becomes defunct, or if the full DAO disagrees with its decision), Aave DAO can always remove the multisig, it can select a new manager directly, or, in the worst case, it can deploy a new registration contract, which will be recognized as the “official” contract in indexes / subgraphs.

Happy to remove the multisig from the proposal if that is not the desired setup of Aave governance.

5

Yes, the best solution is to have the Level 1 governance Executor (Short Executor) with all the roles required, especially because doesn’t seem like a really frequent action.

2 Likes
6

Okay, based on your recommendation @bgdlabs I’ve removed the additional multisig delegation contract call. See above!

Note, the core engineering team behind DAOstar will be meeting at 11am ET / 4pm UTC (calendar event with call link here), and we would welcome anyone from Aave who has questions about this proposal!

2 Likes
7

Hi folks, if there are no further comments, we plan to move this to Snapshot in the next 7 days.

2 Likes
8

Hi everyone, just an update—while the Snapshot proposal for EIP-4824 passed with unanimous support in March, we ended up delaying moving to an AIP in order to build up more prop power and to improve some backend infrastructure before deploying. Since then, a new Snapshot quorum requirement for 320k AAVE was passed, and some wise folks in Aave governance suggested to me that I should first repost the Snapshot proposal before moving to the on-chain proposal. So this is a heads up that we plan to repost the Snapshot proposal in the next few days!

9

Hi folks,

Aman from DAOstar here. I’d like to echo @thelastjosh’s mention that the proposal did pass unanimously back in March. With that in mind, is it necessary for us to conduct another snapshot vote before moving this proposal on-chain? Would appreciate clarity on this matter, @MarcZeller.

Additionally, I’d like to share some recent milestones regarding EIP-4824:

  1. Snapshot X integrated EIP-4824.
  2. Optimism awarded a $100k grant to aid DAOs on Optimism adopt EIP-4824.

Thanks for your time and feedback.

1 Like