[RFC] Governor Nexus: Modular Security Upgrade for ENS Governance
Abstract
This RFC introduces Governor Nexus, a modular governance framework intended to modernize the ENS Governor while preserving full compatibility with the existing Timelock contract.
The proposal combines security hardening, improved operational UX for delegates, and a ruleset architecture that allows different proposal classes to follow different approval logic. The objective is to reduce governance attack surface now while making future governance evolution safer and easier.
Motivation and Security Context
ENS governance covers protocol upgrades and treasury operations. The current governor parameters and mechanics expose avoidable risks:
- Proposal spam can force a war of attrition as an attack
- Very short pre-vote response windows make defensive coordination unfeasible before voting starts
- Operational friction makes active participation harder
- Governance upgrades are currently strict and costly
Governor Nexus addresses these issues through targeted parameter changes, new mechanisms, and modular proposal rules.
A dedicated assessment using the Anticapture framework places ENS at Stage 0, with multiple critical/high-risk elements identified. It is currently not at risk, given the security council being in place.
The updates in this proposal would make ENS a Stage 1 governance, leaving only parameters that are not directly related to the governance contract needing attention to reach Stage 2.
For readers who want to verify detailed findings before reviewing this RFC, see the ENS Governance Security Assessment.
Key Findings from Current Governor
| Risk | Severity | Summary | Governor Nexus Feature (Solution) |
|---|---|---|---|
| Insufficient voting delay | Critical | Coordination window is too short for adequate defense | 2-day voting delay |
| No active proposal limits | Critical | DAO can be flooded to hide/force malicious proposals | Per-proposer caps |
| No continuous threshold enforcement | Critical | Proposers can dumb their tokens after submission | Proposal cancelation if below threshold |
| Vote immutability | Medium | No correction path if a voting UI is compromised | Mutable voting |
| Governance interface security unverified | Medium | Unknown DNS/TLS/frontend posture should be treated as high risk | Mutable voting |
| No late vote extension | Medium | Last-minute flips can pass without response time | Late vote extension |
| Routine operations require full governance vote (no optimistic path) | Low | QoL and delegate-load issue for low-risk actions | Optimistic path for routine operations |
| Uniform approval thresholds | Low | Policy calibration opportunity to improve governance UX | Tiered approval thresholds |
See ENS Governance Security Assessment for full analysis.
Goals and Non-Goals
Goals
- Reduce exploitable governance attack paths in the current system
- Increase review and coordination time for proposal safety
- Improve participation efficiency for delegates and service providers
- Enable future governance upgrades and changes with less cost and risk
Non-Goals
- Replacing the existing Timelock(wallet.ensdao.eth) contract
Changes Specification
1. Core Security Parameters
| Parameter | Current (Assessment Baseline) | Proposed | Rationale |
|---|---|---|---|
| Voting Delay | 1 block (~12s) | 2 days | Improves review and coordination time before voting starts |
| Vote Mutability | Immutable | Mutable during voting period | Allows correction after interface incidents |
| Per-Proposer Active Limit | None | 2 | Limits individual spam throughput |
2. Governance Mechanisms
2.1 Continuous Threshold Enforcement
Proposers must remain at or above proposal threshold for the full lifecycle of their proposal. If proposer voting power drops below threshold, the proposal becomes cancelable by any address.
This prevents spam by threshold bypass and hit-and-run behavior using temporary voting power.
Expected behavior:
- Threshold is checked at proposal creation.
- Proposer voting power is checked when any address calls the
cancel()function. - If the proposer’s voting power is below threshold,
cancel()is permissionless to execute.
2.2 Proposer Self-Cancellation
Proposers may cancel their own proposal before the voting process is finished, to recover safely from mistakes, avoiding unfruitful governance cost and workload.
This is an error-recovery path for good-faith proposer mistakes and does not replace security-driven cancellation paths.
2.3 Multicall Voting
Delegates may vote across multiple proposals in a single transaction to reduce gas and operational friction.
This primarily improves delegate QoL during high-proposal periods and helps maintain participation quality when governance load spikes. It also allows for delegates to vote in multiple proposals in case of a spam attack.
2.4 Proposal Bonds
This has been already previously brought up a few times, and even approved on Snapshot.
Anyone may submit a proposal, without meeting the Threshold, as long as they stake the necessary ENS for it, which can be slashed if the proposal is deemed unnecessary.
Selecting Proposal Bond as Proposal Type (read proposal types below) will ask for an amount of ENS to be staked, and vote options are Yes, No, Abstain, and No + Slash. In case Slash wins, the ENS staked goes back into the DAO treasury.
This does NOT substitute our standard voting, but extends the ways a proposal can be made as one more proposal module.
2.5 Extended Vote Subsidies
Gas subsidy support should include:
- Contract-wallet voting paths (Safes, multisigs)
- Votes with reason strings
Currently only EOAs voting without comments can use the subsidie to vote for free.
2.6 Late Vote Extension
If a proposal flips from failing to passing in the last 24 hours, and it hasn’t been extended before, voting is automatically extended by 48 hours.
The extension trigger is intentionally narrow (late fail-to-pass flip) so normal proposals are not delayed when outcome direction is stable.
2.7 Optimistic Approval Path (Low-Risk Operations)
For designated low-risk operational actions:
- Proposal passes by default after 15 days
- Proposal fails only if opposition reaches 500k ENS
- No quorum requirement
Eligibility should be explicitly enumerated and conservative, limited to routine operational actions where full-vote overhead is disproportionately high.
Proposal Types and Approval Rules
Governor Nexus routes proposals to a ruleset module selected during propose(). They are
| Proposal Type | Condition | Approval Threshold | Quorum |
|---|---|---|---|
| Standard | Default path | Simple majority (>50%) | 1M ENS |
| Optimistic | Predefined low-risk operations | Pass unless 500k ENS oppose | None |
| Bond | Lock-to-propose | Simple-majority (>50%) | 1M ENS |
- Proposal type is declared at creation and should be immutable thereafter.
- Other proposal types can be introduced later through governance.
Architecture
Governor Nexus uses a modular router architecture:
+------------------------------+ +-----------+
Users ----------> | Governor Nexus Core | -----> | Timelock |
| (proposal lifecycle, vote | | |
| casting, timelock admin) | +-----------+
+------------------------------+
^
|
+--------------------+--------------------+--------------------+
| | | |
+------------------+ +--------------------+ +------------------+ (more modules)
| Standard Ruleset | | Optimistic Ruleset | | Bond Ruleset |
+------------------+ +--------------------+ +------------------+
Governor Nexus Core responsibilities:
- Owns Timelock admin rights
- Maintains proposal state and canonical vote accounting
- Dispatches proposal validation and pass/fail checks to rulesets
Ruleset responsibilities:
- Define quorum and thresholds
- Define type-specific voting and approval logics
- Remain individually changeable through governance
Migration
- Once governor is finished and ready for audit.
- Contracts are audited and approved for deploy.
- Governor is deployed on Ethereum.
- Proposal to transfer Timelock admin to new Governor.
- Future proposals go through new governor
No Timelock contract migration is required.
Proposed Timeline Template
| Window | Milestone |
|---|---|
| Week 0 | RFC posted for discussion |
| Week 0-2 | Open community feedback and iteration |
| Week 3 | Finalize spec and request audit quotes |
| Week 4 | Temperature check for design approval and audit budget |
| Post-temperature-check | On-chain proposal for funding |
| Post-audit | Migration proposals and rollout |
Next Steps
This RFC requests feedback on parameter values, mechanism changes, and module boundaries. After feedback is incorporated, the next governance action is a temperature check for validation of the specs and for funding the contracts audit, followed by hardening and deployment.
blockful’s work on this project is already covered under it’s Service Provider proposal.