ENS Logo
Docs

[EP5.7] [Social] Security Council

Abstract

The primary mission of ENS DAO is to govern the protocol and allocate resources from the treasury in line with the DAO's constitution and broader objectives. However, due to changing economic dynamics, the DAO is increasingly vulnerable to attacks aimed at draining its treasury.

To safeguard the DAO's integrity and longevity, a Security Council with the authority to cancel malicious proposals is needed. To avoid perpetuating centralized power, the Security Council's authority will have a built-in expiration date. After two years, anyone will be able to call a function that revokes the council's power to veto proposals, ensuring a time-limited mechanism to counter malicious attacks while promoting more delegation and governance distribution.

Motivation

As ENS continues to grow, its treasury in ETH is always growing. Simultaneously, the percentage of tokens actively delegated is on the decline.

Dune.png

This imbalance creates a risk where an attacker could acquire enough $ENS to gain control of the DAO at a cost lower than the treasury's total value. This has been a growing concern since March 2023.

image

Past attacks on DAOs have exploited similar vulnerabilities, with some being thwarted by components with veto power. Currently, the ENS governance process involves a proposal passing through the governor, relying on delegated voting power for approval. If approved, the governor queues the proposal in a timelock contract, delaying execution by two days. While the governor can cancel proposals, it follows the same pathway as a malicious proposal, introducing potential risks.

The short-term solution was delegating 3.8M $ENS to a contract that can only vote "Against"; more details about this can be found in Nick's forum post. The attack is still profitable and, depending on market conditions can be up to a 3x ROI, like in Dec 2023. We need a mid-term solution to cancel the attack, which is this proposal. An article about this research done by the Blockful team will be published here after the proposal is executed and there is no attack risk.

Specification

To enhance security, a veto contract will be deployed. Controlled by a Security Council multisig and will have the PROPOSER_ROLE in the timelock, granting it the ability to cancel proposals without the power to initiate or modify other DAO actions. The scope of this proposal is to assign the PROPOSER_ROLE to the veto contract,

To ensure decentralization, the contract will also feature a time-based expiration mechanism that allows anyone to revoke the PROPOSER_ROLE after two years. This window provides time to strengthen delegation and address current vulnerabilities, facilitating the DAO's transition to a more secure governance model.

Security considerations

Assigning the PROPOSER_ROLE to a multisig within the timelock contract is overly broad for our requirements as it allows the address to add proposals directly to the queue. If the multisig signers are compromised, they could potentially propose and execute malicious changes. Therefore our approach would be to deploy a new contract similar to the current veto.ensdao.eth contract, which can only do one action: to CANCEL a transaction in the timelock. That would be a trivially simple contract and it would be hard locked to only accept calls from a newly created SAFE multisig.

The risk is mitigated but one scenario remains: if the whole multisig is compromised then a malicious entity could kick other signers and effectively stop the DAO from executing proposals by canceling all transactions, including any that would remove this contract from the proposal role. Anyways, after 2 years, anyone can remove the proposal role.

With that in light. the following considerations are essential for ensuring the Security Council's multisig operates securely:

  • Availability of Signers: It is critical to avoid scenarios where signers are unavailable during emergencies. Events like the Shanghai attack, where real-life occurrences prevent signers from accessing their wallets, must be avoided. Council members should ensure wallets and necessary equipment are accessible at all times.
  • Secure Wallet Practices: Security Council addresses should be exclusive to ENS-related operations. Private keys must be stored using best practices to minimize exposure to risks.

Finding the right balance for the multisig threshold is crucial. A higher threshold can complicate coordination but reduces the risk of malicious activity. A lower threshold, while more agile, could make the DAO more susceptible to attacks or unintended consequences if a few signers are compromised. The suggested composition is a 4/8 multisig.

Council Operations

It is in the best interest of everyone to make clear the expectations and responsibilities ENS DAO put on those members, backed by the reputation, other roles and gains those might have in the organization.

The security council is expected to act only in emergency, in the given following situations or similar cases:

  • If a proposal goes against the ENS constitution
  • If a proposal is approved with malicious intent against the DAO longevity/sustainability
  • If such proposal is approved by any group of voters, but directly financially incentivised to vote against the DAOs interests to preserve their own financial stake.
  • If any approved proposal goes directly against the DAO for the sole benefit of an attacker.

Those definitions are not exhaustive, and the trust deposited in the elected members for the council also encompasses the trust in their capacity to:

  • understand ENS DAO thoroughly
  • listening to the community feedback on extreme situations
  • take quick action on behalf of the DAO
  • comprehend the proposals being approved and their repercussions

The Security Council members will be the same signers for the veto.ensdao.eth, their identities are known, have signed a pledged to uphold the ENS constitution and live in countries with a solid legal system.

Type
๐Ÿ‘จโ€๐Ÿ‘ฉโ€๐Ÿ‘งโ€๐Ÿ‘ฆ Social
Contributors
Last Modified
2 hours ago
Results
snapshot
Proposer
0x76A...BbB8
For
100%
Against
0%
Abstain
0%