We are writing to inform you about the status of the aavedao.eth ENS name, which controls the Aave DAO Snapshot.
We were recently alerted by a community member that the ENS registration, previously under different stewardship, had expired two weeks ago. Given the operational security risks, we took the temporary step of acquiring the ENS for 0.7 ETH to prevent it from being claimed by a malicious actor. For the time being, the Snapshot space is secured.
Having control of this ENS means having administrative access to the Snapshot. This includes the ability to change space settings or cancel pending proposals, so it plays a part in the DAO’s operational security.
Now that it’s secured, we want to open up a conversation with the DAO and Service Providers about what to do next.
We’re looking for suggestions on where this ENS should be transferred and how it should be managed to ensure there are no issues going forward.
Well done, thanks for being proactive on that matter.
Following recent conversations, in our opinion, this asset should be part of the broader framework : owned by the DAO but managed by a SP who gets a delegated mandate for that.
Hello, and thank you @AaveLabs for retrieving the ENS aaveDAO.eth.
Snapshot management is delegated to @ACI as part of the Dolce Vita service. That said, @ACI has no particular claim or desire to retain ownership of the domain itself.
Ownership should be transferred to the Aave Protocol Embassy (APE), a multisig operated by service providers and delegates, with day-to-day management mandated to @ACI. This would reinforce a healthy precedent: DAO-owned assets, with management and operations delegated under a clear mandate to a service provider.
For reference, the APE multisig address is: 0xa9e777D56C0Ad861f6a03967E080e767ad8D39b6
Thank you to Aave Labs for acting quickly and re-registering aavedao.eth this could have become a serious governance or security incident.
I’m strongly supportive of the DAO-owned / delegated operations approach here proposed by Marc. Concretely, transfer ownership of aavedao.eth to APE (or another DAO-aligned multisig vehicle), and keep ACI as the day-to-day operator/admin for Snapshot, since ACI has been doing an excellent job and continuity matters.
As next steps, it would be great to add a few basic safeguard like an expiration/renewal monitoring alert, and a simple runbook for “critical governance assets” (ENS, domains, keys, access permissions) so this doesn’t happen again.
Happy to support this direction, it’s a good example of strengthening governance resilience without slowing down execution.
While the discussion is still ongoing, from my personal point of view I want to highlight that the underlying concern here is not about ownership (since this ENS can be transferred wherever the community decides), but about the operational security.
For a period of weeks, anyone from the public could have gained full access to the Snapshot environment, removed administrators, added new administrators, removed proposals, and fully control the Snapshot space. Therefore, we should not take operational security lightly, as this represented a serious security risk.
To prevent future lapses, a new multisig with demonstrably high operational security standards and consisting of security-oriented participants should be established to manage the ENS and other critical OpSec assets where it makes sense. Alternatively, the proposed APE multisig could be reconstituted with a broader group of security oriented participants who are willing to adhere to rigorous security and prevention practices.
As mentioned by @emereb, basic safeguards like an expiration or renewal monitoring alert, etc. should be implemented and put in place.
I think it’s important to send it to an existing Multisig just to keep the amount of different multisigs being used within the DAO relatively small. So we don’t loose oversight.
APE in my opinion is a great choice to transfer it to with different parties involved from delegates like me to different SP.
Additionally it’s not a Multisig that is being used daily, so there is also a lower chance of doing a mistake. And everyone within APE can create a reminder for expiration.
this is probably a dumb question, but how would someone owning the aavedao.eth ENS give full access to the snapshot environment including the role/rights to add administrators?
i agree stuff like this is concerning though. the same thing happened with paraswap/cowswap. it took weeks for anyone to notice labs had redirected revenues previously going to the dao to themselves. what sorts of procedures, safeguards, automation, alerts, operational security practices need to be in place to make sure we are aware of when things are expiring or when revenue sources are removed?
for a protocol securing tens of billions of dollars, even small stuff like this has the potential to decrease trust. it’s a good opportunity to identify other potential areas for things to fall through the cracks.
I believe the ENS expiration incident occurred because no specific individual or service provider was explicitly responsible for renewals. This is a straightforward operational issue and can be easily avoided by assigning clear ownership and setting a calendar reminder at least one year before expiration.
The owning by an other entity can have consequences on snapshot, important put not critical ones. I wanted to point that snapshot is used to get gouvernance point of view but it’s not used for critical execution that always go to AIP on-chain vote. If a incident will have hapend on snapshot the resolution can have been done without to must difficulties.
That said, it’s good that Aave Labs detected the issue early. Let’s transfer the ENS back to APE, assign clear responsibility for renewals, and move forward.
@TokenLogic, please also ensure that the fee advanced by @AaveLabs is refunded in the next Funding Update.