[Executable] Enable Root and Registrar Security Controllers

[nick.eth]

Status	Active
Votes	Tally

Abstract

This proposal enables two break-glass security controllers:

• RootSecurityController, which can disable a TLD by taking ownership and clearing its resolver.

• RegistrarSecurityController, which can disable a .eth registrar controller.

Motivation

At present, remediating a compromise or security vulnerability in critical parts of the ENS contracts requires a DAO vote, which takes a minimum of 9 days. This provides a significant window during which an attacker could take advantage of a vulnerability with no way to stop it. This proposal introduces two security controllers, which permit the security council to disable ENS functionality in an emergency, without granting them broad powers over the ENS system.

Enabling the RootSecurityController allows rapid deactivation of a compromised TLD by transferring its ownership to the controller and clearing its resolver. Enabling the RegistrarSecurityController allows the security council to disable problematic registrar controllers, while still retaining DAO control over the base registrar.

These ‘negative’ powers are in line with the security council’s existing remit to veto DAO votes, but constitute an expansion of their powers; unlike the veto power, this one is not time-limited and would require a DAO vote to remove. However, we believe these powers are proportional and necessary. As they are subject to DAO review, the DAO can easily countermand any changes made by the council and/or remove the council’s ability to make further changes.

Specification

Description

Batch transaction for ENS DAO execution to enable and configure the security controllers.

Transactions Summary

This proposal contains 2 transaction(s) to be executed by the ENS DAO Timelock.

#	Contract	Function	Description
1	Root	setController	Enable RootSecurityController as a root controller
2	Base Registrar	transferOwnership	Transfer registrar ownership to RegistrarSecurityController
3	Root Security Controller	transferOwnership	Transfer ownership of RootSecurityController to Security Council Multisig
4	Registrar Security Controller	setController	Add Security Council Multisig as a controller of RegistrarSecurityController

Detailed Transaction Information

Transaction 1: Enable RootSecurityController on Root

Target: Root

Address: 0xaB528d626EC275E3faD363fF1393A41F581c5897

Function: setController

Parameters:

• address controller: 0x95123B1ec97df0d3c52c728aB38FBbb7A3ca6da6

• bool enabled: true

Encoded Calldata: <TBD>

---

Transaction 2: Transfer Base Registrar ownership to RegistrarSecurityController

Target: Base Registrar Implementation

Address: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85

Function: transferOwnership

Parameters:

• address newOwner: 0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b

Encoded Calldata: <TBD>

---

Transaction 3: Transfer ownership of RootSecurityController to Security Council Multisig

Target: RootSecurityController

Address: 0x95123B1ec97df0d3c52c728aB38FBbb7A3ca6da6

Function: transferOwnership

Parameters:

• address newOwner: 0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7

Encoded Calldata: <TBD>

---

Transaction 4: Add Security Council Multisig as a controller of RegistrarSecurityController

Target: RegistrarSecurityController

Address: 0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b

Function: setController

Parameters:

• address controller: 0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7
• bool enabled: true

Encoded Calldata: <TBD>

---

Notes / Assumptions

• RootSecurityController and RegistrarSecurityController are already deployed.

• Controller ownership is already held by the DAO prior to execution.

[nick.eth]

Just to add that interested participants can read the source of the two new contracts here: Add RegistrarSecurityController and RootSecurityController for security council access by Arachnid · Pull Request #517 · ensdomains/ens-contracts · GitHub

[clowes.eth]

Could I suggest that the RootSecurityController be opt-in?

I’ve been actively engaging with various ICANN working groups, and one thing that they were particularly curious about was how verification of TLD ownership happens, and how it is secured.

Once control of a TLD is taken by its operator, there was a general acceptance that ultimately responsibility lies with them. Whilst I think fallbacks are prudent, I don’t think we should push a specific fallback. Many are never going to buy-in to rescinding control of their security fallback to 8 independent individuals.

Alternatively, it would be cool if when a TLD is allocated to the operator e.g. [Draft][Executable] Assign Ownership of the `.kred` TLD to Verified Multisig Controller the executable optionally calls a setter on RootSecurityController that sets the address of the fallback (be that an EOA , or a contract).

Something like:

address fallback = fallbackOverride[label];
if (fallback == address(0)) {
    fallback = address(this);
}

root.setSubnodeOwner(label, fallback);

[Premm.eth]

I think a drawing might help to make this change more clear?

[nick.eth]

@clowes.eth

Could I suggest that the RootSecurityController be opt-in?

I’ve been actively engaging with various ICANN working groups, and one thing that they were particularly curious about was how verification of TLD ownership happens, and how it is secured.

Once control of a TLD is taken by its operator, there was a general acceptance that ultimately responsibility lies with them. Whilst I think fallbacks are prudent, I don’t think we should push a specific fallback. Many are never going to buy-in to rescinding control of their security fallback to 8 independent individuals.

As it is, the Root has a ‘lock’ mechanism. The owner of a TLD can call lock() at any time; doing so removes the ability for the root owner or controllers to change that domain in the future. At the moment, .eth is the only locked domain, but any TLD owner can call it if they wish.

For unlocked domains, the DAO retains ultimate control over the domain via the root - so I look at this as the DAO delegating security operations over TLDs it is ultimately responsible for to the security council. A TLD operator who does not want this can lock the domain, and set up whatever ownership model works best for them independent of this.

[clowes.eth]

Ah yes, that makes sense. Supportive.

[blockful]

Contracts were verified and tested, achieving the intended outcome. Here is some documentation to help understanding better this change and next steps to test the calldata.

---

What Changes in Practice

• Before: only the DAO timelock can remove registrar controllers or change
  root controller status, requiring a full proposal cycle.

• After: the security council can immediately disable a compromised
  registrar controller or TLD, while the DAO retains full governance control
  over long-term configuration.

Some visual documentation, as suggested above by @Premm.eth.

Scope of Authority

RootSecurityController (owned by Security Council Multisig)

Enables emergency TLD shutdown:

• disableTLD(label) — takes ownership of a TLD and clears its resolver

This allows the security council to rapidly disable compromised or vulnerable
TLDs without waiting for a full DAO vote.

RegistrarSecurityController (owned by ENS DAO Timelock)

Preserves DAO governance over .eth while enabling emergency controller shutdown:

DAO (Owner)

• addRegistrarController(address)
• removeRegistrarController(address)
• setRegistrarResolver(address)
• transferRegistrarOwnership(address)

Security Council (Controller)

• disableRegistrarController(address) — emergency removal only

Rollback Plan (Return to “Before” State)

If the DAO decides to revert to the original model, it can
execute the following actions via the ENS DAO Timelock:

1. Revoke RootSecurityController from Root

   • Call Root.setController(rootSecurityController, false)
   • Effect: RootSecurityController loses the ability to manage TLD ownership.

2. Transfer Base Registrar ownership back to the Timelock

   • Call BaseRegistrar.transferOwnership(ENS_DAO_Timelock)
   • Effect: RegistrarSecurityController is no longer the registrar owner.

3. (Optional) Remove Security Council controller permissions

   • Call RegistrarSecurityController.setController(securityCouncilMultisig, false)
   • Effect: Security council can no longer disable registrar controllers.
   • Preference: Step 2 already removes the controller’s authority by restoring
     timelock ownership of the registrar, which avoids accumulating legacy
     permissioned contracts in the execution path.

After these steps, control returns to the pre-proposal state where only the DAO
timelock can manage registrar controllers and root permissions.

Verifying locally

Source code available here.

1. Clone: git clone https://github.com/blockful/dao-proposals.git
2. Checkout: git checkout cf43a94
3. Run: forge test --match-path "src/ens/proposals/ep-enable-security-controllers/*" -vv

Next steps

As we don’t have the contract addresses of RegistrarSecurityController and RootSecurityController, we could not create a Tally draft, neither recommend a calldata. Once the draft is ready, we’ll proceed to check the calldata.

[Premm.eth]

Thanks for the drawing, but from the drawing it’s still not clear to me. Can you make it a bit more clear? I am not able to understand it as it is now.

[clowes.eth]

@nick.eth

I look at this as the DAO delegating security operations over TLDs it is ultimately responsible for

@blockful

This allows the security council to rapidly disable compromised or vulnerable
TLDs without waiting for a full DAO vote.

OK. This sets of my radars. Instead.. can we just not have compromised or vulnerable TLDs? I appreciate that blockchain technology is new and there are still (unfortunately) hacks etc but generally TLD operators have incredibly talented engineering and security teams and work with a ‘prevention is better than cure’ approach to their implementations. If TLD operators need the DAO as a backup.. they possibly shouldn’t be operating a TLD.

I appreciate that having to hire blockchain engineers etc is a barrier to entry for TLD operators integrating with ENS. We should be creating a value proposition that warrants TLD operators wanting to front those costs.

Refreshing my memory on the ‘Security Council’, I also note that the documentation states (emphasis mine):

The ENS DAO Security Council is a 4-of-8 multi-sig with a limited mandate: to cancel malicious proposals that threaten the DAO, particularly those that would compromise the treasury. It was created to address vulnerabilities stemming from low voter participation relative to treasury size.

---

Edit: Is it documented anywhere all of the TLDs that are integrated at the moment?

[netto.eth]

@clowes.eth

can we just not have compromised or vulnerable TLDs

In an ideal world, yes. But in practice that’s a really hard assumption to rely on. Most mature DeFi protocols end up with some kind of “guardian” or emergency multisig as a standard risk-management tool. The recent Balancer incident is a good reminder that even contracts that have been live and “battle-tested” for 5+ years can still fail. Having this lever is usually better than dealing with user and reputational damage.

@clowes.eth

The ENS DAO Security Council is a 4-of-8 multi-sig with a limited mandate: to cancel malicious proposals that threaten the DAO

That’s fair. When we proposed the Security Council, the scope was intentionally narrow and focused on canceling malicious proposals. Expanding that scope could make sense, but it should come with clear docs on what the new responsibilities are, how they’re exercised, and probably a compensation review given the added responsibility (Disclaimer: I’m on the Security Council).

[clowes.eth]

@netto.eth

Most mature DeFi protocols end up with some kind of “guardian” or emergency multisig as a standard risk-management tool.

These are crypto native products.

We are talking about integrations with the DNS. Using Verisign as an example..

Verisign’s infrastructure processes an average of 329 billion Domain Name System (DNS) transactions each day, operating at a peak of more than six million transactions per second so far this year. Verisign’s resolution infrastructure is engineered to handle peak query loads significantly greater than the highest ever observed, to ensure continuous operation regardless of demand. This infrastructure has delivered 100 percent DNS availability for .com for more than 27 years without interruption.

Anyone that we should want to integrate with ENS is not going to need a 4/8 multisig to protect them.

@netto.eth

Expanding that scope could make sense, but it should come with clear docs on what the new responsibilities are, how they’re exercised, and probably a compensation review given the added responsibility

The scope was defined that way for a reason. Proposing scope creep AND a pay rise for something we should not need is disingenuous.

If we want to give more consideration to DNS integration security we should be engaging more with the ICANN community (which I am already doing), and we should be listening to what they have to say. I will ping some of the people I have connected with and see if they have any opinions on this.

---

Found the list of TLDs - Supported TLD List | ENS Docs

[nick.eth]

@netto.eth

@clowes.eth

The ENS DAO Security Council is a 4-of-8 multi-sig with a limited mandate: to cancel malicious proposals that threaten the DAO

That’s fair. When we proposed the Security Council, the scope was intentionally narrow and focused on canceling malicious proposals. Expanding that scope could make sense, but it should come with clear docs on what the new responsibilities are, how they’re exercised, and probably a compensation review given the added responsibility (Disclaimer: I’m on the Security Council).

Just to add that while this is an extension, it’s (deliberately) still in line with the type of responsibilities the council already had: the council can only revoke permissions or veto things - it doesn’t have any positive rights to enact things.

@clowes.eth

These are crypto native products.

We are talking about integrations with the DNS. Using Verisign as an example..

Verisign’s infrastructure processes an average of 329 billion Domain Name System (DNS) transactions each day, operating at a peak of more than six million transactions per second so far this year. Verisign’s resolution infrastructure is engineered to handle peak query loads significantly greater than the highest ever observed, to ensure continuous operation regardless of demand. This infrastructure has delivered 100 percent DNS availability for .com for more than 27 years without interruption.

Anyone that we should want to integrate with ENS is not going to need a 4/8 multisig to protect them.

I’m not sure why being crypto-native would make them less secure than a crypto initiative by a third-party? Either way, “simply don’t suck” isn’t a good strategy, and it’s a best practice to have safeguards in place for when things do go wrong. There’s also not much downside to this since, as stated above, the council can only revoke permissions, not grant them.

[5pence.eth]

@nick.eth

still in line with the type of responsibilities the council already had: the council can only revoke permissions or veto things

What permissions can the Council revoke? I thought it was just the ability to cancel a malicious proposal.

I also disagree a bit with the quoted statement - when the council was voted in under EP 5.13, it was under the assumption that its limited power could be revoked at any time by anyone after 2 years. Unlike the original Security Council design, where anyone could permissionlessly revoke the council’s authority after 2 years, this proposed power would require a full governance proposal to remove - a much higher bar. We should be sure to clarify that.

To be clear, I support this proposal’s initiative and I encourage everyone to support it. But, I think it should be amended to clearly state its purpose and effects, which are to expand the Security Council’s role beyond its initial mandate and without the same built-in sunset. We’ve set a high bar for proposal clarity lately - let’s hold this one to the same standard.

---

@netto.eth

and probably a compensation review given the added responsibility (Disclaimer: I’m on the Security Council).

@netto.eth’s comment here brings up another interesting point: After the council was first voted in, there was a request for compensation. In response, we delivered 2-year vesting contracts with 1,000 ENS to all 8 members.

We should ensure the existing Security Council members would be willing to undertake this additional responsibility for the previous compensation amount. If not, we need to establish what the Council members do want and make that a part of this proposal, before the proposal goes live.

Ideally, the council members would make any additional compensation requests known before the proposal goes live, rather than after.

[nick.eth]

@5pence.eth

What permissions can the Council revoke? I thought it was just the ability to cancel a malicious proposal.

That is their current ability, yes. My point is that the council’s mode of operation is negative: they can cancel and revoke things, not enact them. I believe this extension is in line with that, and is the minimal set of permissions required to provide a safeguard against exploits.

@5pence.eth

I also disagree a bit with the quoted statement - when the council was voted in under EP 5.13, it was under the assumption that its limited power could be revoked at any time by anyone after 2 years. Unlike the original Security Council design, where anyone could permissionlessly revoke the council’s authority after 2 years, this proposed power would require a full governance proposal to remove - a much higher bar. We should be sure to clarify that.

Yes, good point. I’ll update the description accordingly.

@5pence.eth

We should ensure the existing Security Council members would be willing to undertake this additional responsibility for the previous compensation amount. If not, we need to establish what the Council members do want and make that a part of this proposal, before the proposal goes live.

I’ve discussed these contracts with the council and got general agreement on them, but compensation was not explicitly discussed.

[nick.eth]

This is now live for voting onchain.

[blockful]

Live proposal calldata security verification

Calldata executed the expected outcome. The simulation and tests of the live proposal can be found here.

To verify locally:

1. Clone: git clone https://github.com/blockful/dao-proposals.git
2. Checkout: git checkout 0ee8b50
3. Run: forge test --match-path "src/ens/proposals/ep-6-33/*" -vv