ENS DAO Governance Security Audit Report
1. Audit Info
- Assessment Type: Governance and Security Review
- Framework: Anticapture Governance Security Framework
- Resilience Stage: Stage 0
2. Scope and Objective
This assessment reviews the current ENS Governor against the Anticapture framework, which focuses on attack profitability, spam resistance, response time, safeguards, and governance frontend risk.
At the time of this analysis, ENS is at Stage 0, meaning at least one high-risk implementation detail. The current configuration leaves meaningful exposure to:
- Fast-execution governance attacks with limited response time
- Attention-dilution attacks via proposal spam
- Interface-layer deception with limited voter recovery options
- Routine operations still requiring full governance votes
The findings include 2 critical, 1 high, 3 medium, and 4 low risks.
3. Severity Classification
| Severity | Count | Description |
|---|---|---|
| Critical | 2 | Immediate threat to treasury or protocol control |
| High | 1 | Material attack paths with realistic exploit conditions |
| Medium | 3 | Elevated governance risk that should be addressed |
| Low | 4 | Operational quality and participation frictions |
4. Findings Overview
| ID | Severity | Title | Category |
|---|---|---|---|
| C-1 | Critical | Insufficient Voting Delay | Response Time |
| C-2 | Critical | No Active Proposal Limits | Spam Resistance |
| H-1 | High | No Continuous Proposer Threshold Enforcement | Spam Resistance |
| M-1 | Medium | Governance Interface Security Unverified | Governance Frontend Vulnerability |
| M-2 | Medium | No Late Vote Extension | Response Time |
| M-3 | Medium | Vote Immutability | Governance Frontend Vulnerability |
| L-1 | Low | Routine Operations Require Full Governance Vote (No Optimistic Path) | Response Time / Operational Efficiency |
| L-2 | Low | Uniform Approval Thresholds for Unequal Risk | Operational Efficiency / Governance UX |
| L-3 | Low | No Batch (Multicall) Voting | Operational Efficiency |
| L-4 | Low | Limited Subsidy Coverage for Contract Wallets | Operational Efficiency |
5. Detailed Findings
C-1: Insufficient Voting Delay
- Severity: Critical
- Category: Response Time
- Current Value: 1 block (~12s at assessment time)
- Recommended Value: >= 2 days
Description
The current voting delay leaves almost no time between proposal creation and vote start. For a DAO of ENS size, this prevents practical review and coordination before voting begins.
Attack Vector
- Attacker submits a malicious proposal.
- Voting starts 12 seconds after proposal is created.
- Existing voting-power distribution is effectively locked in before delegates can react.
- It is humanly impossible to “rally the troops” to delegate/redelegate to support governance defense.
Recommendation
Increase voting delay to at least 2 days to enable technical review, delegate coordination, and incident response.
C-2: No Active Proposal Limits
- Severity: Critical
- Category: Spam Resistance
- Current State: No per-proposer active proposal caps
- Recommended State: Bounded concurrent proposals
Description
Without active proposal limits, attackers can flood governance with simultaneous proposals, reducing reviewer attention and increasing the chance a malicious proposal is missed.
Imagine 20 delegates having to vote against 10000 proposals while one attacker only needs to vote yes on 1.
Attack Vector
- Attacker (or cartel) submits many proposals in a short window.
- Gas costs of voting against multiple proposals gets too big compared to cost of approving one.
- Malicious payload gets approved through a war of attrition.
Recommendation
Implement a per-proposer cap of 2 active proposals
H-1: No Continuous Proposer Threshold Enforcement
- Severity: High
- Category: Spam Resistance
- Current State: Threshold checked only at proposal creation
- Recommended State: Continuous threshold enforcement
Description
A proposer can satisfy threshold at submission, then immediately transfer/sell/return voting power while the proposal remains active.
Attack Vector
Vector A: Financial-Risk Cancellation (Hit-and-Run)
- Attacker temporarily acquires voting power.
- Submits a malicious or low-quality proposal.
- Disposes of voting power immediately after submission.
- Proposal stays active despite the proposer having no continued economic exposure.
Vector B: Proposal-Limit Circumvention
- Attacker reaches threshold on Address A and submits up to the per-proposer active limit.
- After submission, attacker moves delegated voting power away from Address A.
- Attacker re-accumulates threshold voting power on Address B (or additional addresses).
- New proposals are submitted from fresh addresses while old proposals remain active.
- Effective spam throughput scales beyond the intended per-proposer limit.
Recommendation
If proposer voting power drops below threshold during lifecycle, make the proposal cancelable by any address.
M-1: Governance Interface Security Unverified
- Severity: Medium
- Category: Governance Frontend Vulnerability
- Current State: Contract review complete, frontend controls unverified
- Recommended State: Up to date, verified, DNS and other interface certificates
Description
On-chain correctness does not protect against interface-level deception. DNS, TLS, and other controls require separate verification.
Unknown interface security posture should be treated as a risk until verified.
Recommendation
Create an interface security minimum report to be shared between interface providers and the metagov stewards and/or a third party specialized auditor.
It should contain and guarantee security across the full web delivery stack:
- Domain control hardening: DNSSEC (Domain Name System Security Extensions), CAA (Certification Authority Authorization) records, and registrar lock to reduce domain takeover risk and prevent unauthorized certificate issuance.
- HTTPS (Hypertext Transfer Protocol Secure) enforcement and monitoring: modern TLS (Transport Layer Security) configuration, CT (Certificate Transparency)-based certificate monitoring, and HSTS (HTTP Strict Transport Security) to ensure browsers always use HTTPS and suspicious certificates are detected.
- Verifiable frontend releases: immutable, reproducible build and deployment flow so what ships is exactly what was reviewed and can be re-built deterministically.
- Browser-side execution hardening: strict CSP (Content Security Policy), SRI (Subresource Integrity) for third-party assets, and a hardened set of security headers to reduce XSS (Cross-Site Scripting), injection, and supply-chain exposure.
M-2: No Late Vote Extension
- Severity: Medium
- Category: Response Time
- Current State: Fixed voting deadline
- Recommended State: Auto-extension on last-window outcome flips
Description
A fixed deadline enables timing attacks where outcomes are flipped near close, leaving insufficient time to respond.
Attack Vector
- Malicious proposal remains failing for most of the period.
- Community de-prioritizes active defense.
- Attacker deploys votes late to flip outcome.
- Vote closes before opposition can mobilize.
Recommendation
If a proposal flips from failing to passing in the last 24 hours, extend voting by 48 hours.
M-3: Vote Immutability
- Severity: Medium
- Category: Governance Frontend Vulnerability
- Current State: Votes cannot be changed after casting
- Recommended State: Votes remain mutable until voting closes
Description
Immutable votes remove recovery options if a governance UI is compromised or misleading. If delegates discover a signing mismatch after voting, they cannot correct the on-chain record.
Under the framework, this is a meaningful resilience gap but secondary to core timing/spam controls.
Attack Vector
- Attacker compromises frontend or delivery path (DNS/CDN/provider).
- Interface displays expected action but submits altered vote calldata.
- Delegates sign and cast unintended votes.
- Votes are locked and cannot be corrected before deadline.
Historical Note
Interface compromise has repeatedly been a primary attack surface in crypto operations, independent of contract-level correctness.
Recommendation
Implement vote mutability so delegates can overwrite a prior vote until the voting period ends.
L-1: Routine Operations Require Full Governance Vote (No Optimistic Path)
- Severity: Low
- Category: Response Time / Operational Efficiency
- Current State: All proposals require full governance flow
- Recommended State: Optimistic path for low-risk actions
Description
For low-risk operational actions, full-cycle voting can create unnecessary overhead and delegate fatigue.
Recommendation
Introduce optimistic approval where:
- Proposal passes by default after a fixed review window (for example 15 days)
- Proposal fails if opposition reaches a defined veto threshold (for example 0.1% of supply)
L-2: Uniform Approval Thresholds for Unequal Risk
- Severity: Low
- Category: Operational Efficiency / Governance UX
- Current State: Uniform approval logic across proposal classes
- Recommended State: Risk-adjusted thresholds
Description
Uniform approval logic can make governance less expressive and less ergonomic for delegates reviewing mixed-risk proposal flows. In the current design context, this is better framed as a policy-quality and UX optimization opportunity rather than an immediate exploit driver.
Adopting higher tiers of approval for big movements would allow the DAO to be safe from protocol changes or treasury drains with 16% more cost for an attacker, while keeping normal operations respecting the >50% majority rule.
Recommendation
Adopt tiered thresholds, for example:
| Proposal Class | Approval Rule |
|---|---|
| Standard operations | Simple majority (>50%) |
| Treasury transfer <=5% | Simple majority (>50%) |
| Treasury transfer >5% | Supermajority (>=66%) |
| Governor/core governance upgrades | Supermajority (>=66%) |
L-3: No Batch (Multicall) Voting
- Severity: Low
- Category: Operational Efficiency
- Current State: One proposal vote per transaction
- Recommended State: Batch voting support
Description
Delegates face avoidable gas and operational overhead when voting across multiple active proposals.
Recommendation
Support multicall voting for multiple proposal IDs in one transaction.
L-4: Limited Subsidy Coverage for Contract Wallets
- Severity: Low
- Category: Operational Efficiency
- Current State: Subsidy mechanisms do not fully optimize contract-wallet participation
- Recommended State: Broader subsidy compatibility
Description
Institutional delegates and service providers often vote from contract wallets. Limited subsidy compatibility can suppress participation.
Recommendation
Extend subsidy pathways for:
- Contract-wallet voting patterns
- Votes with reason strings
6. Conclusion
The current ENS Governor has multiple governance risks that can compound during adversarial conditions. The highest-severity gaps are response-time controls and spam resistance, with interface-security verification remaining an important medium-risk area.
A governor upgrade that introduces voting delay hardening, mutable votes, proposal limits, continuous threshold enforcement, late-vote extension, and tiered approval thresholds would materially improve resilience without requiring a Timelock migration.
7. References
- Anticapture Dashboard: https://anticapture.com/ens
- Anticapture Glossary: https://anticapture.com/glossary
- Anticapture Documentation: Welcome to Anticapture | Anticapture
- ENS Governor Contract Source: https://etherscan.io/address/0x323a76393544d5ecca80cd6ef2a560c6a395b7e3#code
Assessment prepared using Anticapture governance security framework.
We will follow up this post soon with a few upgrades that we have mapped to tackle each of those issues, as well as some other quality of life improvements on the governance process.
We invite all members to feedback on this matter regarding presented risks or others we didn’t map.