What's the proposed standard to have primary addresses for contracts?

🧑‍💻 ENS Development Standards
1

I just uploaded a contract and would like it to be identified on Etherscan as it’s proper ENS name. Of course I pointed it the name to it, but it would be better if it also could set itself as the primary name.

I suppose I’d have to add a custom function so it can call ENS and set it, but then I can’t do it for contracts already deployed, and it would mean that I had to create a function that would be called exactly once (or that I needed to add governance to the project to decide how to change it).

What’s the feeling right now about that? Should contracts not have a primary name?

2

Someone else was talking about this in the Discord server and mentioned a particular EIP that could provide a solution, but now I can’t find it…

Also even if you called that method from the contract and set the primary name, Etherscan does not resolve or display primary names for contract addresses. Perhaps that is by design so that people know what they’re looking at is a contract address and not just a normal wallet, not sure. I think it would be good to show the Primary Name if there is one, as long as there’s also still an indicator that it’s a contract address!

These days lots of wallets like Dharma, Argent, etc actually deploy contracts on behalf of customers when they create a new wallet so those contract addresses are used as regular wallet accounts, further complicating the issue.

3

Right now in order to do this you either have to call setName on the reverse registrar at deploy time, or enable an owner to do that post-deployment.

However, we’re working on a suite of contract updates, which includes improvements to the reverse registrar; one is support for the ownable pseudo-standard. The reverse registrar will try static-calling owner on a target contract, and if it returns the address of the caller, allow the caller to set the reverse record on the contract’s behalf.

2 Likes
4

I also think ENS names for smart contracts could have a lot of additional functionality that would essentially make contracts browsable. The feature I am most interested in would be directly calling a NFT smart contract and receiving an NFT in the browser. This NFT could also be dynamic, e.g. html/javascript, basically making a smart contract act like a web server. It would also be possible for smart contracts to have a meta data field, or the ENS resolver, indicating a default subgraph that could be used instead of the contract as a method of quickly accessing data.

The flow would look like this:

Browser :arrow_right: ENS Domain :arrow_right: Smart Contract :arrow_right: Cache Subgraph Link :arrow_right: Query Subgraph :arrow_right: return NFT (e.g. HTML/Javascript) :arrow_right: Render Page

If the user clicks on a hyper link, to another NFT in the same contract it would look like:

Browser :arrow_right: Cached Subgraph Link :arrow_right: Query Subgraph :arrow_right: return NFT (e.g. HTML/Javascript) :arrow_right: Render Page

There could also be a TTL for the subgraph in the contract such that the browser would check for the latest subgraph routinely, in the case the subgraph changes.

There has been a lot of talk, even in the last few days about how Web3 is really not that decentralized, and I think that comes from the control over the interface layer of Web3, e.g. OpenSea. If NFTs could be accessed directly by the browser that would be a provable level of decentralization. Also recently there have been effective attacks on dapps using the interface. I see the dapps as the weakest link in Web3 at the moment.

It would also be possible to have basic contract functionality built directly into the browser as well, e.g. Etherscan contract read and write pages. This could all be accomplished using a browser extension before browsers are willing to support the functionality natively.