I am very happy that the DAO has overwhelmingly voter in favor of creating alternate Streams for service providers. Next steps are in the hands of Metagov governance but I am here to offer my full support.
I originally believed that ideally the selection should happen concurrently with the Election of DAO stewards. That’s a moment in which a lot of attention is being given to the DAO and its candidates and it seems they should go together. But that is also in a couple of weeks and I don’t believe there’s enough time to put the process together, and expect service providers to prepare a well thought budget plan. I still hope we should still plan to have the stream commence no later than February but that would still mean an election in January which might not be great. That should be in the hands of MetaGovernance (both the current and the next group).
Nick and Catherine have criticized the wording of the voted snapshot on not being specific enough.
I have responded to that by opening a draft of the full rules for the working group, below. These are not final rules but a draft that I had previously shared with some interested parties and wrote using their feedback:
To support service providers contributing to the advancement and sustainability of the Ethereum Name Service (ENS).
Participants must have expertise in blockchain and ENS-related development.
Submissions must be made on the ENS Forum and include a detailed proposal with objectives, milestones, timelines, and financial requirements.
For increased transparency and accountability the main receiving address must be an ethereum contract or secure wallet that is directly controlled by the entity and must have its primary ENS name set.
A Service Provider candidate must alert on their submission any potential conflict of interest or already existing financial relationship to the DAO other related entities. This includes (but is not limited to): a team member is also a Steward or Steward candidate (since Stewards are supposed to oversee Providers); a team member who already receives financial compensation for work related to ENS from another entity already being compensated by the DAO (ENS Labs, Karpatkey, other service providers or service provider candidates) and others. The Meta-Governance Working Group may, at their sole discretion, elect to impose conditions for the participation of the team in the case it is selected.
The application period will open concurrently with the 2023 steward election application window and the vote should happen in the same week as the election for the 2024 steward term.
The meta-governance working group can, at their sole discretion, postpone the selection and submission deadlines for both this and the next selection cycles, to avoid scheduling conflicts with other governance events, major holidays or conferences. The first election must happen no earlier than february of 2024 and the next ones must happen before may of each year. Any need to postpone it further requires a social vote.
- The meta-governance working group will release and may amend requirements and a prescribed format for applications.
Fees are to be proposed in increments of $200,000 USD per annum, with a cap of $1 million annually.
Service providers must commit to operating for at least one year.
A service provider who intends to cease operation after a specific date or deliverable must specify this in their application.
The meta-governance working group will, at their sole discretion, curate proposal submissions and determine which will proceed to a vote. They will not unreasonably deny a vote on a valid proposal.
The meta-governance working group will post a snapshot vote at the end of the application period.
The snapshot vote will use approval voting, and include every service provider who submitted a valid application for consideration.
Proposals must secure a minimum of 1 million ENS in approvals.
A None of the Above option will also exist. Candidates with less approval than the NOTA should be disqualified.
Selection of winning proposals uses the following process:
Sort proposals in descending order by the number of votes they received. For each proposal:
If the proposal has fewer than 1 million votes, halt and do not consider any further proposals.
If the proposal’s requested budget exceeds the remaining budget, skip the proposal and proceed to the next one.
Otherwise, add the proposal to the set of selected proposals, and deduct its requested budget from the remaining budget.
(see discussion below)
- After a period of 12-15 months, a new vote must be taken place to reassess the stream. The process will be identical to the one outlined in 3.3 and current Service Providers must apply again, to show their commitment to continue providing service and have the opportunity to reassess their desired budget.
- The exact scheduling of the vote and application process falls to meta-governance working group can, at their sole discretion, under the condition that the new providers must start no later than 18 months after the beginning of the old stream, to guarantee that there will be no interruption of service.
If a Service Provider becomes unresponsive or is deemed unfit by its oversight committee, and attempts to solve the issue privately have failed, then it may initiate the termination process as follows:
- Raise the issue on a Working Group call and give a minimum 1 week period for the provider to respond publicly
- If the issue is still unresolved, initiate a snapshot vote to remove the Service Provider, with a minimum of 5 days.
- If the above vote passes, then an Executable proposal will be made to terminate the stream.
- All outputs will be licensed under MIT
- Changes to these rules can only be made by a simple majority vote of the ENS DAO with a Social proposal. The social proposal shall only be initiated after a minimum discussion period on the governance forum of five days.
- The Meta-Governance Working Group will be responsible for overseeing the application process, funding distribution, and adherence to these rules.
- Each provider should provide quarterly reports to the DAO, outlining the progress and impact of the funded projects.
- Each approved service provider stream will be assigned to a specific working group which will act as the main point of contact and oversee the service stream.
The Ecosystem Working Group will generally serve as the primary overseer. They are tasked with the following:
Monitoring the progress of the service provider in relation to the goals set out in the proposal.
Facilitating communication between the service provider and the ENS DAO.
Initiating the termination procedure if the Service provider becomes unresponsive, insolvent, or encounters any major legal or ethical issue that makes the Working Group consider them unfit.
- The Ecosystem Working Group may delegate oversight responsibility to the Public Goods or Meta-Governance Working Groups if the nature of the service is more aligned with their mandate.
- Collaboration between the overseeing working group and the service provider should be regular and documented, ensuring transparency and accountability.
The Meta-Governance Working Group holds responsibility for questions regarding the overall stream and budget allocations. This includes:
Approval of budget allocations for the service streams.
Reassessment of budget allocations based on performance reviews and community feedback.
Addressing any financial discrepancies or concerns raised by the overseeing working groups or community.
- Regular updates (at minimum once a month) will be communicated by the service provider to the assigned working group and summarized to the community through forums, community calls, or governance meetings.
- All discussions, decisions, and relevant documentation will be made publicly accessible, maintaining the principles of transparency and accountability inherent to the ENS DAO.
Finally how would the stream happen? I propose these options:
1) Use ENS Labs implementation: Ens labs has their own stream, which has been live since EP14.
Pros: It’s a very simple contract with less than 40 functional lines of code (ignoring ERC20 code and comments) and has been working for for over a year without issues. It doesn’t require almost any setup like moving funds or wrapping tokens: the current implementation simply has an approval to spend an unlimited amount of USDC from the ENS main wallet.
Cons: It’s a very simple contract. It doesn’t allow for multiple streams to different parties, it doesn’t even has a setting to adjust a stream rate. In fact the only way to stop the stream is to remove the approval at the USDC level in the DAO wallet. We would have to deploy multiple contracts for every provider every year – even recurring providers would have to either require us to redeploy new streaming contracts or give them unlimited approval on USDC which would add more risks.
2) Use Superfluid.finance
Pros: Superfluid also has been around for many years. It has been audited and battle tested with X millions of dollars for N years. The process would be: the DAO would have to wrap the USDC into a super-token wrapper (ideally we would only wrap enough to cover 18 months of stream so we have margin) and then approve different amounts of streams to the receivers. That would all happen in a single transaction. Superfluid allows the contract later to simply deposit (wrap) more tokens to extend the whole stream or adjust any particular stream (including adding more).
Because superfluid is a standard, it means streams can be divided and sent forward. This is useful in two ways: a provider can, instead of unwrapping their USDC, decide simply to give part of their stream directly to developers, further increasing transparency on the system. Another option would be the DAO to approve the full stream not to providers directly but to a wallet controlled by the working group, which could then create substreams to providers. This would allow them to take actions much more swiftly if needed or make new stream adjustments without a new executable vote (which can be a double edged sword). Superfluid has also a robust ecosystem of apps being built on this modularity, including streaming DCA exchanges like Ricochet and Aqueduct.
Cons: it is a more complex contract which has a bigger attack surface. Although it has been audited, increasing the exposure of any major contract can lead to new bugs being discovered and exploited.
Conflict of interest alert: I (Avsa) am a seed investor in Superfluid. I am an investor in them because I am a fan of streams as a concept and have been a user of superfluid for a while and not the opposite. Also, I am invested in ENS by much much more than superfluid
3) Other providers: Sablier, Llama, Sushi Furo, Ajira Pay
There is a healthy ecosystem of Streaming providers to choose from. I have not experienced most of them. I had tried out Sablier for a year but stopped using it because it lacked some important features (like the ability to extend a stream by adding more funds at a later date) which I really needed. As far as I know Sablier is focused mostly on token vesting and doesn’t have the “re-stream” capability that allows multiple streams to be daisy chained.
As mentioned I have a conflict of interest with Superfluid so I think I should not be the person to make that decision, other than personally endorsing them.