[6.45] Renewal of the Security Council

Abstract

The ENS DAO Security Council’s veto authority expires on 24 July 2026, when renounceTimelockRoleByExpiration() becomes callable at Fri, Jul 24, 2026, 18:52:59 UTC. This proposal renews the council for a further two-year term. It deploys an updated SecurityCouncil contract that adds a extend() function callable only by the DAO timelock, so future renewals are a single governance vote rather than a fresh deployment and role re-grant. The new contract is audited before it is deployed, with the Meta-Governance Working Group funding the audit. The 4-of-8 multisig and the council’s cancel-only emergency mandate are unchanged, with one signer rotation: lefteris.eth, who is no longer active in the DAO, is removed and coltron.eth, the largest active delegate not currently on the council, is added. This post is the temperature check; after one week of discussion it proceeds to a Snapshot social vote, with the executable grant targeted for the last week of June.

Specification

Background

The Security Council is a 4-of-8 Safe multisig with a single power: to cancel malicious proposals in the ENS timelock. It cannot propose, amend, or initiate any governance action. It was approved through EP 5.7 [Social], EP 5.10 [Social], and EP 5.13 [Executable] (passed 25 July 2024). The current contract is deployed at 0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0 and its authority is time-limited: two years plus a 7-day buffer after deployment, anyone may call renounceTimelockRoleByExpiration() to permanently disable the cancel power, which occurs on 24 July 2026. The threat that motivated the council, a large treasury relative to active voting power, has not changed, so the recommendation is to renew rather than let it lapse.

New contract

The current contract has no way to extend its own expiration, so renewing it requires deploying a new contract, passing an executable proposal to grant PROPOSER_ROLE, and letting the old role expire. We propose deploying an updated SecurityCouncil contract (blockful/security-council-ens) with the same cancel-only mandate and 4-of-8 ownership, plus an extend() function:

function extend(uint256 newExpiration) external {

if (msg.sender != address(timelock)) revert OnlyTimelock();

if (newExpiration <= expiration) revert InvalidExpiration();

if (newExpiration <= block.timestamp) revert InvalidExpiration();

if (!timelock.hasRole(timelock.PROPOSER_ROLE(), address(this)))

revert RoleAlreadyRenounced();

expiration = newExpiration;

}

The key safety property is that only the timelock can call extend(), so only a passed ENS DAO proposal can extend the term and the multisig cannot extend its own power. After this renewal, each subsequent renewal is a single extend() proposal with no redeploy and no re-grant.

Audit

The new contract is audited before it is deployed to mainnet. We are collecting quotes from auditors, and the Meta-Governance Working Group funds the audit. Deployment and the executable grant proposal happen only after the audit is complete and any findings are resolved.

Signer rotation

lefteris.eth is no longer active in DAO governance. Because the 4-of-8 threshold depends on signer availability, securitycouncil.lefteris.eth is removed and coltron.eth ([TBD address, to provide]), the largest active delegate not currently on the council, is added. The council maintains jurisdictional diversity as a legal-resilience requirement: no group of four signers (the signing threshold) shares a single jurisdiction, so no single jurisdiction can compel a passing quorum. The incoming signer is selected so this property continues to hold after the swap. The change is executed on the Safe multisig (removeOwner / addOwner, threshold kept at 4) and does not require a contract redeploy.

Timeline

This post is the temperature check, running one week, then a Snapshot social vote the following week, with the executable proposal in the last week of June, ahead of the 24 July 2026 expiration. The contract is audited and deployed before the executable.

# Step Owner Target date Status
1 Finalize and freeze new contract code Blockful late May 2026 Done
2 Temperature check (this post), one week discussion DAO 29 May to 5 June 2026 Done
3 Audit and resolve findings Auditor / Blockful by mid June 2026 Done
4 Social proposal on Snapshot, ~5 day vote DAO submit week of 8 June 2026 Done
5 Deploy audited contract to mainnet Blockful mid June 2026 Done
6 Signer rotation on the Safe Multisig mid to late June 2026 Not started
7 Executable proposal: grantRole(PROPOSER_ROLE, newContract) DAO last week of June 2026 Not started
8 Old contract role expires automatically n/a 24 July 2026 Not started

Executable actions

The on-chain executable portion will contain a single action: ENSTimelock.grantRole(PROPOSER_ROLE, ). Deployment and the Safe signer rotation happen outside the executable transaction. The old contract’s role expires automatically on 24 July 2026 or can be renounced by anyone via renounceTimelockRoleByExpiration(). The exact newContractAddress, calldata, and PROPOSER_ROLE hash are appended once the audited contract is deployed.

3 Likes

@blockful My signer address for this role is: securitycouncil.coltron.eth

Verifiable at: https://etherscan.io/address/0x8E52ca0109E0E981988cd9D4a4DbeE6D8204aFF3

I am reposting my earlier view here, since it is directly relevant to this renewal and may attract more delegate attention:

Update: Smart contract audit complete and contract deployed

Nethermind Security has completed its review of the renewed SecurityCouncil contract (report NM-0945, final commit e196ad7).

Result: zero findings - no Critical, High, Medium, Low, or Informational issues. Documentation and test suite were both rated High. Expected since it’s a code with low complexity, but admin access to the DAO.

The full report is in the repo: security-council-ens/audits

The contract is now deployed and verified on mainnet: 0xdededd439ecf711e61f5aecef631579dba2c65db

The executable proposal to grant PROPOSER_ROLE to the new contract will go live in the next few days.

1 Like

The Security Council is a vital protection for the DAO against governance attacks, and I firmly support renewing it so it can continue to guard against them.

One Council member has publicly stated that he will sign an onchain transaction to veto the current ENS Foundation proposal if it passes without “wide support from non-Labs delegates.” This is not the Security Council’s role. The Council is a backstop to safeguard the ENS Constitution: smart contract exploits, governance captures that strip the DAO of its constitutional authorities, and protocol-level attacks of that kind. It is not a mechanism for individual members to veto governance proposals they happen to disagree with on substance. A duly ratified vote on a legitimate governance proposal that does not violate the ENS Constitution is not a governance attack.

Speaking personally: I will vote against any replacement Security Council that includes a member on record saying they would veto a proposal that does not violate the ENS Constitution. And I will vote against any replacement Council that does not commit to that standard publicly before the vote.

3 Likes

I will vote against renewing the Security Council because enough members will likely use it to block the ENS Foundation proposal.

I support the Foundation proposal because I am more confident in ENS Labs’ ability to execute than I am on management of the treasury by delegates. While unpopular today, I believe this move to be in ENS’s long-term interest.

3 Likes

Thank you for an honest take. At least we can start being honest that this is not about empowering a foundation that is independent or other theatrics like that but about ENS Labs killing the DAO and taking complete control over the protocol.

3 Likes

According to the ENS DAO docs the security council should intervene…

  • If a proposal is approved with malicious intent against the DAO longevity/sustainability
  • If such [a] proposal is approved by any group of voters, but [they are] directly financially incentivised to vote against the DAO’s interests to preserve their own financial stake

In this case, one could make a reasonable argument that The Current Thing proposal acts “against the DAO longevity and sustainability”. One could also make a reasonable argument that the proposal is approved by a “group of voters [that are] directly financially incentivised to vote against the DAO’s interests to preserve their own financial stake””.

There are, of course, counter arguments to both of these, but it seems like the documented purpose of the Security Council is explicitly to think through both sides of the debate on both tests and make a personal judgement call. Someone making that judgement call out of alignment with the majority DAO token holders does not mean that the the security council is abandoning their duties. In fact, the entire purpose of this role of the security council is to explicitly protect against situations where the majority token holder is wrong.

The fact that the majority token holder can simply eject the security council makes the security council pretty toothless in reality, and I’m not sure why it was setup this way because it means the security council cannot actually protect against the exact attack that it was designed to protect against.


If we imagine this exact proposal playing out but instead of the dominate ENS token holder set being ENS Labs it was instead Blackrock (pick your favorite boogeyman), then this proposal certainly looks like an ENS exit rug pull. Blackrock pinky promising to uphold ENS values wouldn’t change that I don’t think. This would be especially true if Blackrock threatened to evict any security council member who signaled that they would block the Blackrock exit rug pull.


Maybe the right question we should be asking is: “has anyone verified that the ENS Labs team and their families are currently safe?” The sudden behavior change looks like exactly what we would expect to see if ENS Labs was compromised. It does seem unlikely given that this would require compromising multiple people simultaneously, but wrench attacks are on the rise so maybe the security council should intervene for the safety and protection of ENS Labs members. :thinking:

2 Likes