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:
Merge your PR if it meets the requirements.
Assign your proposal a proposal number in the form EP###.
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.
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.
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.
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 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.
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.
