[EP 5.22] ENSv2 Development Funding Request

@nick.eth - These are the docs Netto was referring to: Governance Process | ENS Docs

They’re older and haven’t been kept up to date.

It’s this section that is misleading (edit - this is the same link you sent, but I think there’s different interpretations of this section, the last line in particular can be misinterpreted):

Phase 3: Active Proposal — Snapshot / Governance Portal

Use GitHub to flag your PR as Ready for Review. A contributor will:

  1. Merge your PR if it meets the requirements.
  2. Assign your proposal a proposal number in the form EP###.
  3. Schedule the proposal for a snapshot vote.

If your proposal is a Social Proposal or a Constitutional Amendment, that’s it! If the snapshot vote passes, the proposal is passed and you are done.

If your proposal is an Executable Proposal, you will now need to submit it to the governor contract for voting onchain.

Not a big deal, but probably best for us to polish it so it’s clear.

2 Likes

As I mentioned above I am in favour of this so long as we have quarterly reports and a way for the DAO to measure progress.

The commitment from ENS Labs for reports is here: ENS Labs Transparency Reports

With this budget I have high expectations and hope to see a great output and an ENS v2 that will make us all proud and benefit the ethereum (and more) ecosystem.

There is, in my opinion, no reason to vote against the current proposal due to minor text differences. We all agree that we as the DAO need to hold ENS labs accountable.

This is what this proposal does. The executable code simply gives approval to this token stream contract that Nick created to pull USDC from the DAO. That contract can only pull the agreed amount of USDC as a stream.

At any point in time the DAO can revoke approval to that contract and effectively cut the payment stream.

I voted FOR this onchain.

4 Likes

Thanks for quickly publishing the commitment, Nick. It looks great, covering financial and technical aspects!

Labs has a lot of incentives to keep itself accountable to the DAO after making such a public commitment, so I see no reason to vote against it as well. +1 on what @lefteris said.

I’m voting for this. I support ENSv2 and ENS Labs.

3 Likes

AFAIK, there is a single exception in the Working Group rules, rule 10.1 that states:

“In order for a working group to have a funding request included in a Collective Proposal submitted to the DAO during a Funding Window, the funding request must have passed as a Social Proposal in the same Funding Window” — Rule 10.1.1

This may give the impression that all funding requests should follow this procedure, but, as far as I understand, nothing explicitly states that all funding requests must follow it.

In theory—at least in the one I personally subscribe to—the interpretation of governance documentation should follow a permissive approach.

This approach operates on the assumption that, unless something is explicitly prohibited, it can be considered permitted. This encourages flexibility in DAO procedures by favoring implicit permissions over restrictive mandates.

There are, however, instances where the DAO could benefit from a more explicit framework—for example, protocols for funding requests outside of Working Groups or requests that exceed the funding provided by the Service Provider program.

Such a framework would ensure that all entities, including those outside of Working Groups (such as ENS Labs or Service Providers), adhere to consistent procedures in funding-related matters.

Could you cite the specific section that led you to this interpretation? From my understanding, there are no explicit rules stating that all executable proposals must go through a social vote first. Admittedly, this was also my initial interpretation due to the specificity of rule 10.1.1 in the Working Group rules, especially in contrast with the opacity of other protocols regarding funding requests.

I’m obviously voting ‘For’!

I don’t really agree here. For example, would it be okay if I include a personal NFT purchase in an executable vote that follows a successful social proposal? There’s nothing in the rules that says a dog can’t play football I can’t do that.

I’m personally of the opinion that the lifecycle of an EP should be spelled out clearly and in detail, and while exceptions can be permitted - for example, in emergencies - those should be documented.

1 Like

Calldata security verification

The simulation and tests of EP 5.22 can be found here . Calldata matched as expected in the approval operation and the assertion after simulating the proposal, passing it, and executing it.

This can be checked by cloning the repo and running:
forge test --match-path src/ens/proposals/ep-5-22/* -vvvv

Some considerations

The executable code gives an infinite* USDC approval of spending from the ENS DAO to the streaming contract. Therefore, we needed to analyze the streaming contract to understand logic and parameters.

Streaming contract parameters checked

  • Streaming rate is $0.174483, which matches the proposed increase of streaming.
  • Streaming start is 1735689600 (in UNIX timestamp), which means 1 Jan 2025 00:00 UTC.
  • The end time is set to infinite and can only be set by the DAO,

How can the steam be canceled?

  • DAO change USDC approval
  • DAO can change end time

For the streaming to run smoothly, the DAO need to make sure that there is USDC in the treasury.

nick.eth is the admin of the streaming contract and the claim function can only be called by the owner, which can also provide the wallet to receive the claimed USDC.

The streaming contract has a minimal risk surface and it’s really simple, presenting a low risk by itself.

* infinite: There is no infinite value in solidity, it’s the max value of a unit256, which is so big that is basically unreachable. Here is the number in USDC for reference
Disclaimer: That is not an audit of the streaming contract.
4 Likes

Gm, gm! :sparkles:

The results are in for the [5.22] [EXECUTABLE PROPOSAL] ENSv2 Development Funding on-chain proposal.

See how the community voted and more ENS stats:

1 Like

Sorry, I don’t think I articulated my point well. What I meant to say is that the DAO’s ‘operating system’ (governance framework) should be flexible rather than overly regulatory.

I’m not specifically referring to the process of submitting proposals here.

Yes, agree to this 100%—with respect to the governance process itself (.ie submitting proposals), the DAO should follow a clear process and I believe the existing governance documentation already does a good job of spelling that out already: Moderator Checklists | ENS Docs.