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.
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
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
@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
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
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…
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.
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.
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?
, this will be really helpful for all frENS 
