[Temp Check]: Set Primary Names for Core DAO Addresses

DAO-Wide Temp Check
1

Introduction

With all the discussion in the ecosystem around naming contracts in the Contract Naming Season temp check, I think ENS should lead by example and set primary names for its own contracts.

Several contracts are owned by the DAO and therefore require an onchain proposal to update. I’m looking for feedback before submitting the following proposal.

Abstract

Several ENS DAO contracts lack primary names. This proposal establishes reverse records for core DAO addresses.

Motivation

By setting reverse records for core DAO addresses:

Details

Executing this proposal will set primary names for

  1. The ENS DAO wallet
  2. The ENS token
  3. The ENS Endowment wallet

Specification

Call setName("wallet.ensdao.eth") on the Reverse Registrar (reverse.ens.eth) to set the reverse record of 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7.

Call setNameForAddr(0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72, 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7, 0xF29100983E058B709F3D539b0c765937B804AC15, "token.ensdao.eth") on the Reverse Registrar to set the reverse record of 0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72.

Call execTransaction() on the Endowment multisig (endowment.ensdao.eth) with the encoded calldata for setName("endowment.ensdao.eth") to set the reverse record of 0x4F2083f5fBede34C2714aFfb3105539775f7FE64. The Safe transaction looks like this:

To: 0xa58E81fe9b61B5c3fE2AFD33CF304c454AbFc7Cb
Value: 0
Data: 0xc47f002700000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000014656e646f776d656e742e656e7364616f2e657468000000000000000000000000
Operation: 0
SafeTxGas: 0
BaseGas: 0
GasPrice: 0
GasToken: 0x0000000000000000000000000000000000000000
RefundReceiver: 0x0000000000000000000000000000000000000000
Signatures: 0x000000000000000000000000Fe89cc7aBB2C4183683ab71653C4cdc9B02D44b7000000000000000000000000000000000000000000000000000000000000000001

Thanks to @gregskril for his help crafting this proposal

19 Likes
2

Hey @Limes, thanks for the proposal, exciting to see more contracts being named!

Our team is looking at it and will post the calldata review in the next week, since we are now focusing on Endowment permissions to karpatkey - Update #6 review.

5 Likes
3

It’s good to see the contract naming campaign and ENS DAO itself taking the lead with this proposal.

Since it’s a temp check and there is potentially time to consider modifications to the proposal before moving forward, I’d propose adding: 1) some ENS records; and 2) a content hash (IPFS frontend) to the subdomains in the proposal.

Reason I quoted Limes above is he links the subdomains to the etherscan contract urls, and as an example both the contract addresses and etherscan links could be added to the subdomain text records. The content hash could be a frontend that displays the respective subdomain ens records which resolve on the .limo/.link gateways. In my opinion these additional steps perfect ENS as the ultimate self-contained source of truth, while making user friendly, and create synergy between the protocol and multiple service providers.

If the general concept isn’t objectionable to expanding this proposal to include contract naming, record setting, decentralized frontend, I’d propose GeoCities, an ecosystem product that makes frontends available with ens records and also integrates EFP so people can follow the subdomain/contracts/dwebsites. Interestingly one of the ENS subdomains being used already has a few hundred followers on EFP.

IMG_1969
IMG_1969828×1425 72.5 KB

IMG_1971
IMG_1971828×1426 73.8 KB

IMG_1970
IMG_1970828×1428 68.9 KB

1 Like
4

Thanks for the input, Punks, and yes, I’m definitely looking for modifications to the proposal!

I agree that we should have records on these subdomains. It looks like ENS Labs owns the parent domain ensdao.eth, so they can update these directly without requiring action from an onchain DAO proposal.

1 Like
5

This is awesome to see @Limes! :raised_hands:

In preparation for contract naming season, the Enscribe team is currently working on naming best practices for various type of contracts, DAOs naturally being one of these.

Our hope is that ENS can be the torchbearer here for what well-named DAO contracts should look like.

In terms of establishing a recommended approach @nischal.eth will share some specifics shortly which hopefully can feed into this process.

5 Likes
6

+1 on ENS being the torchbearer for what well-named DAO contracts should look like especially in conjunction with Naming Season

4 Likes
7

Hey @Limes @gregskril, Thanks for the proposal

I want to understand more about how the naming process will happen (actual txs) and how Enscribe can help with this.

We want to make sure ENS and other DAOs can easily name their contracts via the Enscribe platform, and for this we need your input so we can include or improve the methods to name contracts via Enscribe.

I believe for naming DAO wallet you will be using the ENS manager app since it’s a smart wallet?

But for naming ENS token and ENS endowment contracts, what functionality can we include in Enscribe?

8

Hey, I replied in the ENS Developers telegram group!

Tldr; custom calldata, no UI

1 Like
9

This is an excellent proposal and a fantastic first step towards getting more DAOs utilising ENS names! Perfect timing before the Contract Naming Season proposal goes live as a test case and industry example!

3 Likes
10

A good start - looks good to me!

5 Likes
11

Hello all,

The Enscribe team has prepared a draft on DAO naming best practices and would love to get the community’s feedback. We will be using this for the Contract Naming Season best practices guide.

Google Docs Link

It would be awesome if we can have ENS DAO follow this in the above proposal and set an example for other DAOs to follow. Any suggestions or modifications required in the draft are welcome.

2 Likes
12

The following DAO contracts already have primary names: veto.ensdao.eth

The following DAO working group multisigs already have primary names: main.pg.wg.ens.eth, main.eco.wg.ens.eth, hackathons.eco.wg.ens.eth, main.mg.wg.ens.eth, stream.mg.wg.ens.eth

The following ENS protocol contracts already have primary names: reverse.ens.eth, wrapper.ens.eth, dnssec.ens.eth, root.ens.eth, controller.ens.eth, registrar.ens.eth, resolver.ens.eth

This proposal adds token.ensdao.eth, wallet.ensdao.eth (same as timelock and treasury in your Google doc), endowment.ensdao.eth.

The following DAO contracts unfortunately cannot be named, but still forward resolve: governor.ensdao.eth, tokenlock.ensdao.eth

4 Likes
13

Calldata security verification

This calldata achieve it’s desired outcome, the simulation and tests of the calldata can be found here.

This can be checked by cloning the repo and running:
forge test --match-path "src/ens/proposals/ep-naming-core-contracts/*" -vv

Next step is posting a proposal draft on Tally and then replying here, so we leave no margin for wrong calldata to go onchain. Any help needed, please reach out. :saluting_face:

3 Likes
14

Hey @blockful, draft is here.

@slobo.eth will post onchain once given the thumbs up.

1 Like
15

Thanks for putting this together @Limes. Some thoughts:

DAO Wallet vs Timelock terminology

Since I already heard some folks getting confused in understanding the DAO wallet was actually the timelock, I wonder if timelock.ensdao.eth is a more precise name since it’s the technical term.

Naming the security council contracts

veto.ensdao.eth is a contract that has no delegations anymore. Though it could be used in the future.

This contract and this multisig (aka Security Council) is effectively what’s now protecting the DAO. Both don’t require a DAO vote, since one is a multisig and the other inherited the ReverseClaimer contract.

Happy to join the initiative and take the lead for those contracts. My suggestion is:

  • securitycouncil.ensdao.eth → 0xB8fA0cE3f91F41C5292D07475b445c35ddF63eE0
  • multisig.securitycouncil.ensdao.eth → 0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7

Ownership of domains

This is a tangential topic that came in mind since we are talking about ens/ensdao.eth subdomains.

Back in Jan 2024, because of DAOIP-6, I did a quick research on how DAOs were using ENS.

Here is the spreadsheet. The data isn’t update since then, but I double checked the ENS one and still the same. It might also have some relevant data for the Naming Season proposal and the Organizational Metadata work.

One of the things that caught my eye is the owner and manager role of domains. The majority of listed DAOs owns their domains through a multisig or even the timelock contract, while managing it on an easier access address (like a multisig or EOA).

ens.eth and ensdao.eth are managed and owned by an EOA. The best practice for security and to guarantee this is a DAO owned asset would be the ens.eth and/or at least ensdao.eth to be owned by the timelock/working group multisig, while the manager role could remain as its. By doing this, we are also setting an example.

Looking forward to see this live and name them all!! :fire:

16

That makes sense technically, but I think wallet.ensdao.eth is more informative to a broader audience. It’s established as it already exists and forward resolves and communicates what it is without relying on technical terms like “timelock.”

Agree, would love to see these named. Neither of these require a change to the proposal, just coordination with the owner of ensdao.eth (Labs).

Agree on having it belong to a working group multisig to prevent the need for onchain proposals to make new names/changes.

17

Draft reviewed. Ready to post @slobo.eth!

1 Like
18

Posted

thanks @blockful

1 Like
19

At least two people (@brantlymillegan & @gregskril) have gotten a malicious warning error when interacting with the governor contract via metamask. I personally did not get this error.

Dropping this note here in case others encounter this issue. Greg reached out to metamask.

1 Like
20

The Metamask issue has been resolved

2 Likes