spikewatanabe.eth

# [EP5.13][Executable] 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](https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol#L59) 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.

![security-council-diagram](https://hackmd.io/\_uploads/BJb0bHP\_A.png)

## Motivation

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

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.

Past attacks on DAOs have exploited similar vulnerabilities, with some [being thwarted](https://x.com/AragonProject/status/1656028382939815937) 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](https://discuss.ens.domains/t/introducing-veto-ensdao-eth/19088). 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](https://blockful.io/blog/ens-security-council) after the proposal is executed and there is no attack risk.

## Specification

To enhance security, the [SecurityCouncil contract](https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol) will be deployed, receiving the PROPOSER_ROLE in the timelock, granting it the ability to cancel proposals (callable only by the [Security Council multisig](https://etherscan.io/address/0xaa5cd05f6b62c3af58ae9c4f3f7a2acc2cdc2cc7)) without the power to initiate or modify other DAO actions. **The scope of this proposal is to assign the PROPOSER_ROLE to the SecurityCouncil contract ([Etherscan](https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0#code))\*\*.

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 scenario.

## 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 create operations in the timelock. If the multisig signers are compromised, they could potentially propose and execute malicious changes. Therefore our approach is deploying a new contract similar to the current veto.ensdao.eth contract, which can only do one action: to CANCEL a transaction in the timelock, triggered only by the security council 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 PROPOSER_ROLE. Anyways, after 2 years, [anyone can remove the PROPOSER_ROLE from the contract](https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol#L59).

## 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.

## Relevant links

- SecurityCouncil contract ([GitHub](https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol), [Etherscan](https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0#code))

- Security Council multisig ([Safe](https://app.safe.global/home?safe=eth:0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7), [Etherscan](https://etherscan.io/address/0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7))

- Snapshot proposals:

- [[EP5.7][Social] Security Council](https://snapshot.org/#/ens.eth/proposal/0xf3a4673fe04a3ecfed4a2f066f6ced1539a5466d61630428333360b843653c54)

- [[EP5.10][Social] Confirming the ENS DAO Security Council Members](https://snapshot.org/#/ens.eth/proposal/0xa0b1bfadf6853b5b0d59d3c4d73c434fc6389339887d05de805361372eb17c3a)

- [Forum discussion](https://discuss.ens.domains/t/temp-check-enable-cancel-role-on-the-dao/19090/19)

[CANCELED] [EP 6.13] [Executable] - Service Provider Program Season 2 Implementation

*This proposal was withdrawn by the proposer due to a mistake in the executable code
*
### Abstract
This executable proposal implements the Service Provider Program Season 2 (SPP2) following the approval of EP 6.10 for service provider selection and the budget framework established in EP 6.3.

This proposal transitions our existing streaming infrastructure from the $3.6M annual budget supporting 9 providers to the new $4.5M annual budget supporting 8 providers, including 6 continuing providers and 2 new additions.

### Specification
Following the selection of service providers in EP 6.10, this proposal implements the technical changes required to:

**Adjust Streaming Infrastructure** - Update the master flow rate from ENS DAO to the Stream Management Pod to accommodate the increased budget
**Provide Initial Funding** - Supply one month of USDC funding (375,000 USDC) to ensure uninterrupted service
**Configure Autowrap Parameters** - Set appropriate allowances for automatic USDC-to-USDCx conversion
The Stream Management Pod will continue to manage individual provider streams, adjusting rates for continuing providers and establishing new streams for JustaName and ZK Email.

### Service Provider Allocations
The following providers and allocations have been approved:

Service Provider	Annual Allocation	Stream Duration
ETH.LIMO	$700,000	2 years
Blockful	$700,000	2 years
Namespace	$600,000	1 year
Unruggable	$600,000	1 year
NameHash Labs	$500,000	1 year
Resolverworks	$500,000	1 year
JustaName	$450,000	1 year
ZK Email	$450,000	1 year
Total	$4,500,000	
Technical Implementation
The implementation maintains our existing Superfluid architecture:

ENS Treasury (Timelock) → Stream Management Pod → Individual Service Providers
The Stream Management Pod continues to be controlled by 3 of 5 signatures (3 Metagov Stewards, Secretary, and DAO Governor)
Security measures remain in place, limiting exposure to approximately 50 days of funding in case of contract compromise
Transactions
Transaction 1: Approve USDCx
Target: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC)
Function: approve
Arguments:

spender: 0x1BA8603DA702602A8657980e825A6DAa03Dee93a
amount: 375000000000
Calldata:

0x095ea7b30000000000000000000000001ba8603da702602a8657980e825a6daa03dee93a000000000000000000000000000000000000000000000000000000000574fbde600
Tenderly: Approve USDCx
Transaction 2: Upgrade USDC to USDCx
Target: 0x1BA8603DA702602A8657980e825A6DAa03Dee93a (USDCx)
Function: upgrade
Arguments:

amount: 375000000000000000000000
Calldata:

0x45977d03000000000000000000000000000000000000000000004f68ca6d8cd91c600000
Tenderly: Upgrade USDC
Transaction 3: Set Flow Rate
Target: 0xcfA132E353cB4E398080B9700609bb008eceB125 (Superfluid)
Function: setFlowrate
Arguments:

token: 0x1BA8603DA702602A8657980e825A6DAa03Dee93a
receiver: 0xB162Bf7A7fD64eF32b787719335d06B2780e31D1
flowrate: 142599440769357573
Calldata:

0x57e6aa360000000000000000000000001ba8603da702602a8657980e825a6daa03dee93a000000000000000000000000b162bf7a7fd64ef32b787719335d06b2780e31d100000000000000000000000000000000000000000000000001fa9d6f943a1705
Tenderly: Set Flow Rate
Transaction 4: Set Autowrap Allowance
Target: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC)
Function: approve
Arguments:

spender: 0x1D65c6d3AD39d454Ea8F682c49aE7744706eA96d
amount: 6375000000000
Calldata:

0x095ea7b30000000000000000000000001d65c6d3ad39d454ea8f682c49ae7744706ea96d000000000000000000000000000000000000000000000000000005cc4b9c4600
Tenderly: Set Autowrap Allowance
Transaction Details
Approve USDCx: Allows the USDCx contract to spend 375,000 USDC from the ENS DAO treasury for the initial month of funding

Upgrade USDC to USDCx: Wraps 375,000 USDC to USDCx (Superfluid's streaming token format)

Set Flow Rate: Increases the master stream from 0.114155251141552512 USDCx/second ($3.6M/year) to 0.142599440769357573 USDCx/second ($4.5M/year)

Set Autowrap Allowance: Authorizes the Superfluid autowrapper to convert up to 6.375M USDC over time, ensuring continuous funding availability

### Verification
The testing repository with calculation tools and verification scripts is available at github.com/5ajaki/SPP2-Streams.

### Implementation Timeline
Upon passage of this proposal:

The transactions will be executed immediately
The Stream Management Pod will receive the increased flow rate
Metagov stewards will coordinate with service providers to:
Update existing provider streams to new rates
Establish streams for new providers (JustaName and ZK Email)
Calculate and distribute any backdated payments for rate increases
All providers will continue to be subject to the existing KYC and sanctions compliance requirements established in SPP1.

