A map of all ENS contracts

[AvsA]

@nick.eth

I’m not sure we’ll ever be able to lock in a permanent controller; the controller depends on the price oracle, and oracles have a tendency to change from time to time.

It would have to be a very simple contract like—and I’m not saying we should do this—burn 1 $ens get 1 year on your registration. This would create the scenario where there was a floor price for ens: registration was either $5 or 1 ens per year, so if the price of ens drops below $5 then people would start using it instead and therefore burning the supply. This of course can create some other bad effect.

But it’s an idea to prepare for the imaginary threat which might be unlikely. I think adding a long delay (even maybe up to a year) for removing controllers could also work as a nice protection.

[nick.eth]

@AvsA

I think adding a long delay (even maybe up to a year) for removing controllers could also work as a nice protection.

One risk with this is that if a bug was discovered in a controller, we would not be able to disable it for that long.

[AvsA]

@nick.eth

One risk with this is that if a bug was discovered in a controller, we would not be able to disable it for that long.

Yes, this is the whole conundrum: lock it too much and you can’t protect it from future bugs, let it too loose and you can’t protect from the future community

[ohhkaneda.eth]

This is awesome to see, I had a vision of a ENS info graphic flowchart much like this for “non.coiners”. This will help to with on-boarding. cheers …creating a sudo buy and burn to make a “floor price” is neat my concern would be at the price end points of ENS both high and low. Drastic changes to the ENS price, the discount/premium to the user becomes a mute point and they will just use eth. As to floor price I suggest we make ENS socks . lol

[yoginth.eth]

Wow amazing, thanks for making this , this will be really helpful for all frENS

[yoginth.eth]

@AvsA It would be great if you also list the list of ENS contracts so we can copy and paste that and see in etherscan also used to interact with the contract.

It’s very difficult to copy the address from the image

[AvsA]

Here’s an update on the map, now including the functions that each contract can call

[nick.eth]

This is very clear! A couple of suggestions:

• NFT owners can also call ‘transferFrom’ etc on the registrar.
• The registry controller should probably have a title.
• It should probably be ‘primary’ rather than the wallet, since it has a more direct relationship to the registrar than the DAO wallet does.

[AvsA]

I’m using the names assigned at ens.eth subdomains. I’ve also found a few others worth mentioning like the dnssec and the priceoracle which I’m adding now

[AvsA]

also, @nick.eth I’m not sure what to make of this:

One is the resolver that at resolver.ens.eth, the other for some reason etherscann says is where it will be migrated to, and another is the actual resolver being used on the app…

Not even sure it should be in the scope here since resolver is defined per domain

[nick.eth]

@AvsA

I’m using the names assigned at ens.eth subdomains. I’ve also found a few others worth mentioning like the dnssec and the priceoracle which I’m adding now

Right, but in the case of the controller, which doesn’t have an ENS name, it’d help to label it with something.

@AvsA

One is the resolver that at resolver.ens.eth, the other for some reason etherscann says is where it will be migrated to, and another is the actual resolver being used on the app…

resolver.ens.eth should always point to the latest one. Etherscan likely is pointing to a previous version.

@AvsA

Not even sure it should be in the scope here since resolver is defined per domain

Agreed! It might make sense to mention the .eth resolver specifically, though, since it’s used in the discovery mechanism.

[inplco]

You weren’t kidding when you said v3 is much better. Might go ahead and make this interactive with GoJS later

[AvsA]

@nick I added the latest version as a PR here: https://github.com/ensdomains/docs/pull/93

I believe it’s ready for review. I can update it as the contract changes or new addresses are found.

[nick.eth]

Amazing, thank you. I’ve merged the PR.

[inplco]

I went down the rabbit hole with @AvsA’s mapping of ENS contracts since it overlapped with my ongoing threat analysis discussed in another thread. I cleaned things up into multi-layered SVG separating text, pointers, containers and labels across 4 layers but kept everything else as it was to a very large extent. I can now implement this as an animation by hacking the XML. I’ll post results down here as I have them; you can keep track of things on GitHub as well where the source SVG files also reside if anybody wants them.

You can find the GIF in high-res at ens.inplco.eth, or on IPFS

[nick.eth]

One minor nitpick on both layouts - I really think the controller and the price oracle belong in ENS, not in the DAO.

[inplco]

Okay, I’ll float another version just to see. I can imagine it being in both (especially after ENSIP-10)

[AvsA]

@inplco

I cleaned things up into multi-layered SVG separating text, pointers, containers and labels across 4 layers but kept everything else as it was to a very large extent.

Wow that’s amazing!

@nick.eth

One minor nitpick on both layouts

Another issue that I am not sure it’s solved to my satisfaction are the arrows connecting the registry. For example one of the changes requested in EP1 was to change the owner of ens from root to the DAO, but ownerships aren’t clear. In a first version, registry connections were just a different color arrow and instead of connecting to the registry contract they connected to their owner–but since all owners shown were root, I abandoned it. Maybe we should revisit that.

[Limes]

What is the end goal for the permissions of the multisig.ens.eth? Will there be a point where it’s no longer needed or do you think it’ll always exist?

[AvsA]

Yes. I believe it will be completely phased out.