[EP 5.27] [Executable] Revoke the DAO's ability to upgrade the name wrapper

DAO-Wide Temp Check
21

Is there anything I can say or do to convince the people in power to either fix both bugs, or update public messaging to make it clear that ENS is currently a trusted system, contrary to original design intent?

My read of this discussion is that there is nothing that can be done to change minds, but I am trying not to lose hope that there is an amicable path forward!

the following is mostly a recap of prior discussion/suggestion

Ways to make it more clear that ENS is a trusted system:

  • update docs
  • write a blog post letting people know that you believe a trusted system is better than an untrusted system given the current circumstances
  • link blog post on Twitter

While I think an untrusted system would be better, at this point I just would like to see consistency in user facing messaging with reality. Reality is, ENS is currently a trusted system. The people in power think that we should trust the people in power (unsurprising), and maybe we should, but it does mean that ENS is a not a trustless system as originally designed, advertised, and believed by most users.

22

This is now up for vote.

2 Likes
23

Calldata security verification

The simulation and tests of EP 5.27 can be found here. Calldata matched the proposal description as expected. The proposal was simulated by proposing, passing, executing, and asserting the difference between states after the NameWrapper renounceOwnership and setMetadataService calls.

This can be checked by cloning the repo and running:
forge test --match-path src/ens/proposals/ep-5-27/* -vvvv