Changes to the ENS root multisig

💬 General Discussion
1

Recently we’ve been in discussions with the ENS root multisig keyholders about a few small changes to how the multisig is handled. While the keyholders have done a stellar job, they’ve had rather more to do than we initially anticipated, and the multisig tends to suffer from the same issue that most long-term volunteer positions have, where it slips down the priority list. As a result, getting keyholder approval for a change can sometimes be a lengthy process.

In order to try and remedy this, I’ve proposed - and the keyholders have agreed to - a few changes:

  1. All the keyholders besides myself will now serve for a fixed term of 18 months. These terms will be staggered, with one keyholder rotating out every 3 months. The first rotation was scheduled for our third anniversary, May 4th 2020.
  2. Each new keyholder will be paid a stipend of $1000 worth of ETH as compensation for the time required in dealing with multisig requests. Existing keyholders will also receive this stipend.

As always, any changes to the multisig are enacted with the approval of 4 of the 7 current keyholders. I don’t receive the stipend, and while my position on the multisig isn’t rotated out like other keyholders, they can of course vote to replace me at any time.

New keyholders will be proposed each quarter by me, and approved by a majority vote of existing keyholders. Keyholders can agree to serve more than one consecutive 18-month term if they wish; each keyholder receives the stipend for each term they serve.

I proposed the following rotation order to the keyholders:

  1. Vlad Zamfir - 2020-05-03
  2. Jarrad Hope - 2020-08-03
  3. Piper Merriam - 2020-11-03
  4. Dan Finlay - 2021-02-03
  5. Taylor Monahan - 2021-05-03
  6. Aron Fischer - 2021-08-03

Yesterday, I sent out the first rotation request for signing, proposing the replacement of Vlad Zamfir with Sergey Nazarov, CEO of ChainLink.

I’m optimistic that these changes will help ensure the multisig remains vital and active, and can exercise the oversight role that it was designed for. Keyholder rotation makes it possible to relieve keyholders who no longer wish to serve more easily, as well as ensuring a wider number of trusted individuals have an opportunity to participate in the governance of ENS. We welcome proposals from the community for keyholders; we’d like to see people from a wide variety of projects both inside and outside Ethereum participate.

Please feel free to raise any questions or concerns you have about the structure of the multisig with me or anyone else on the team.

-Nick

2 Likes
2

Hi Nick,

Thanks for the update, definitely a good idea to allow for a more diverse and dynamic team-composition.
Could you elaborate a bit on what the tasks and duties of the keyholders are and how often you meet?

3

We don’t tend to meet (physically or virtually), but instead coordinate over email.

Here’s the statement of principles keyholders agreed to:

A root keyholder’s responsibilities are:

  • To migrate the interim register to the permanent one once the evaluation period is over and a permanent registrar has been decided on by the standardisation process, in approximately 2 years.
  • To make changes to the ENS registry, primarily the addition of new TLDs, when community consensus and the view of the keyholder is that this is justified.
  • To eventually act to replace the root multisig with a governance process once the keyholder is confident the proposed replacement is sufficient to the task.
  • To act to limit or revert damage in the case of an unforseen emergency, such as a critical vulnerability in one of the root registrars or the ENS registry itself.

In many regards, the root keyholders can be thought of as similar to the US electoral college: they should act on the community consensus, except where doing so would, in their view, hurt the long term operation or security of the system.

An example of this is the addition of new TLDs: we have deliberately restricted the mainnet deployment of ENS to a single general purpose TLD, ‘.eth’, because we want to avoid overlap between the ENS namespace and that used by IANA for DNS. As a result, no matter how popular a motion was to add new general purpose TLDs, the trustees should - in my view - not act on such a request. In contrast, special purpose TLDs, such as the one required for the proposed reverse lookup standard (EIP 181) may be necessary and warranted.