[temp check] Renew Service Providers Program for Season 2

🗳️ Meta-Governance
1

(This is a temp check for what I’d like to post as a social vote son)

The Service Provider’s streams were initiated almost exactly a year ago, and while it’s approved for 18 months, it is supposed to be a program reevaluated yearly. Here is the proposed format for this year. This vote intends to be a DAO check on whether to renew the program and if so, under what budget.

Vote

The vote will be a Ranked Choice Vote on either to approve or reject and budget. Options will be:

  • Renew and increase budget to $5.4 Million per year
  • Renew and maintain budget at $3.6 Million per year
  • Renew but reduce budget to $1.8 Million per year
  • Do not renew the program.

The budget is set per year. However the actual required budget will need to cover 22 months, because as detailed below, 1/3 of the streams will be budgeted for 2 years and we will add another 6 months of runway to make sure the program is not interrupted by eventual delays in the 2026 vote.

What is the Service Provider Program

The ENS constitution states that “Any income generated to the ENS treasury is to be used first of all to ensure the long-term viability of ENS, and to fund continuing development and improvement of the ENS system.”. The goal of this program is to create a more diverse and decentralized base of developers and companies involved in the improvement of the ENS system, by creating a guaranteed income stream to support their continued work. Streams last at least one year.

Who can apply?

Any company offering services they believe will add value to the ENS ecosystem is eligible to apply. While this process has traditionally focused on developers, delegates now have discretion to determine what services qualify as beneficial.

Eligibility Requirements:

  • The applicant must be an existing company with an established team and reputation.
  • The company or its team members must have prior experience with ENS, blockchain, or domain-related projects.
  • Neither the company nor its team members may reside in OFAC-sanctioned countries.
  • The company must secure endorsement of at least 10k delegated ENS tokens, either through public backing by a delegate or by demonstrating support via Snapshot.

Submission Process

Candidates will be required to submit a proposal demonstrating their eligibility and outlining their plans. The proposal must include the following:

  1. Past Achievements:
    A list of their accomplishments in ENS, the blockchain space, or domain systems.

  2. Scope of Work and Budgets:

    • A basic scope, which outlines the minimum yearly budget they would accept to perform their work, along with the specific goals and deliverables they aim to accomplish within that budget.
    • Optionally, they may also provide an extended scope, which includes an increased budget and details the additional projects or goals they would pursue if granted this higher budget.

  3. Proposal Format:
    The submission must be provided both as a written document and as a short video (no longer than 5 minutes) where the team discusses the above points.

  4. Quarterly KPIs:
    The proposal must include a set of quarterly Key Performance Indicators (KPIs) to define what “success” looks like for their basic and extended scope. These may include specific targets, such as product releases, user acquisition numbers, or other measurable metrics that can be used to evaluate their progress against their own promises.

  5. Flexibility in Work:
    Candidates are not strictly bound to the projects proposed in their submission and are free to explore new directions or areas of research. However, setting clear metrics and goals helps establish expectations for both parties.

  6. Budget Guidelines:

    • All budgets must be submitted as integer multiples of $100k per year.
    • The minimum budget request is $300k per year, and the maximum is $1.3M per year.

What will be selection proccess look like?

  1. Eligibility & Voting

    • The Working Group reviews candidates for eligibility.
    • Eligible candidates are included in a ranked-choice DAO vote with the option “None Below”.
    • A quorum of 1M ENS votes is required; otherwise, the process halts and a new vote is conducted.

  2. Budget Streams

    • Two-Year Stream: 1/3 of the yearly budget for a two-year duration.
    • One-Year Stream: Remaining 2/3 of the yearly budget for one year.

  3. Evaluation Process
    Projects are assessed in ranked order:

    • If “None Below” is reached, evaluation stops.
    • If the candidate has been part of the Service provider program for at least a year AND if the extended budget fits within the remaining two-year stream budget, assign to the two-year stream . Subtract the extended budget from the two-year stream budget.
    • Assign to the one-year stream if:
      1. The extended budget fits the one-year budget. Subtract its extended budget from the one-year stream.
      2. OR if the basic budget fits the one-year budget, subtract the its basic budget from the one-year stream.
    • If none of these conditions are met, the project is eliminated.

  4. Completion

    • Evaluation ends when all projects are assessed, the remaining budget on all streams reaches zero or “None Below” is selected.

Relevant Dates

The Submission process will start on ***, the deadline for submission will be *** and vote will start soon after that. The stream will be activated on ***. Those with the two year stream will be guaranteed a stream until at least february 2027, while the others will be at least february 2026, when they will need to submit again.

Resposibilities for selected service providers

Brand name and association with ENS DAO

Selected providers will be rewarded with the streams, but will also carry the responsibility to represent ENS to the world. They will be granted usage of the ENS brand name (within guidelines).

The stream will be managed by the Metagovernance Stewards, but they are to enact representing the DAO’s intent. They will have access to pause or move streams due to security concerns or upon the request of the service provider. They can only terminate a stream if there is a sucessful DAO vote requesting them to do so (which the DAO is free to do at any point for any reason).

Quarterly reports

Service Providers must provide a detailed written report on their accomplishments every quarter. They are also required to present at working group meetings when requested by stewards and to give at least one presentation at a conference each year (remote attendance is acceptable if necessary). These reports must include any metrics or KPIs promised for the reporting quarter, as well as any new metrics or KPIs proposed for future quarters. Additionally, the report must state the total amount received during the quarter. While Service Providers are encouraged to include financial spending details, this is at their discretion and not a mandatory requirement.

Increased funding

Selected service providers may request specific, non-recurring grants at any time, following the usual governance process on the forum. However, to request an increase in their ongoing stream budget, they must meet the following conditions:

  • They must have been a service provider for at least one year.
  • At least six months must have passed since their most recent stream-related request, whether it was part of a service provider submission or another stream adjustment process, regardless of either it was sucessful or not.

Service Providers can terminate their own stream at any time without notice, thus liberating them from any further obligations towards the DAO. (Note: Terminating their stream does not exempt them from potential liability for any misconduct or unresolved issues.) The ENS DAO can terminate streams for any reason following the proper governance procedure and after a DAO vote.

5 Likes
2

Thanks for continuing to push this forward, Alex!

I don’t understand this - if some of the streams will be for 24 months, how is a budget covering only 22 months sufficient?

This doesn’t have to be decided now, but we should start thinking about how it will look if a service provider applies for 2 years, then wants to reup after only one year.

1 Like
3

Let’s say that the budget chosen is X per month, meaning 12X per year. For ⅔ of the projects, the stream will last a full year, so that would require 8X to cover their budget. For ⅓ of the projects, the stream would last two years so we need 4 * 2 = 8X to cover that stream. That sums up to 16X. Now we need to make sure there’s an extra fat so that projects can be covered for another six months if there’s an issue with the next governance vote (or if we decide, like we are doing now, to postpone it to better time). So we need an extra 6X to cover all these extra months. That adds up to 16+6=22X. Please double check the calculation to make sure I got it right. Now I don’t see any issue adding another 2 months to the fat so that it makes 24X and it makes everyone more confortable with the new round number.

4

Thanks @AvsA for your continued work on this !

Posting here for public visibility based on some things I bought up in Metagov.

I think that it would be extremely useful for there to be clarity on what kind of applicants the DAO would like to see. I think insight from regular working group call participants as well as those with voting power would be helpful.

This information would also be useful in helping delegates make a decision on budget. If there are many obvious things that ‘ENS’ would like to see developed over the coming years then ‘statements of intent’ from potential applicants in response to a list of ‘things we’d like to see’ would likely aid in making that decision.

@Esk3nder.eth provided some insight from the ENS Labs end that was extremely useful. I will allow him to clarify as I don’t wan’t to misquote him but my understanding was that Labs would like to focus on protocol level engineering, and would like to see service provision in vertically integrated areas (DeFi, AI etc).

Delegate bandwidth

One thing that has become apparent over the past months is that delegates have limited bandwidth to engage in complex technical discussions en-masse from potential applicants.

@brennan_agora mentioned that in the context of the ‘Proposal Bond’ put forward by Agora last year it was often the case that after-the-fact, once delegates fully understood what the proposal constituted, they were supportive. At a high level, we need to find away to help delegates engage with the process. We need to find ways of optimising and respecting delegates time.

The above proposal from @AvsA mentions video applications - I think this is a great starting point.

In addition to this I think there is value in offering ‘office hours’ in which applicants can have 15 minutes to discuss, and answer questions pertaining to their proposal.

Whilst there is obviously truth to the argument that applicants need to be able to succinctly and clearly present their ideas, I do also believe that their is value in the DAO financially supporting some sort of ‘Technical liaison to the DAO’ who can aid non-technical delegates in understanding the value/merits of a proposal. Even if that is a part time role specifically over the Service Provider period.

4 Likes
5

Do you think it’s better to define this in the scope of the proposal or to let each delegate vote their own opinions?

Last year, while I voted only for developer teams, I would be open to seeing proposals based on marketing, outreach, events organization etc. But I don’t know if it’s my place to say that a delegate that only votes for development teams is wrong.

6

I see. This definitely should be expressed in some other way than “months’ budget”, then, given not every month has the same cost.

1 Like
7

Well the plan is to renew the one year stream next year, so if that’s done at the same budget level, then every month will have the same cost

8

As written, though, each month does not have the same cost, and we need to make it clear to voters now. Here’s my suggested rewording:

We expect the streaming program to be reviewed and reapproved annually. However, each iteration needs to include budget to cover both 1- and 2- year grants as described below. Additionally, 6 months’ runway is added to both components to allow for delays in the reapproval process.
As a result, the budget for this year will incorporate:

  • 100% of the base budget for the first year of operation
  • 33% of the base budget to fund the second year of the two-year streams.
  • 50% of the base budget for the 6 months’ runway at the end of each component.

The total budget for this iteration will thus be 183% of the approved annual budget. For example, if a budget of $3.6 million per year is approved, the executable proposal will need to approve up to $6.588 million.

In subsequent years, the budget will be reduced proportionally to allow for the ongoing expenditure on multi-year streams. Further, the 6 months’ runway serves as a buffer and is not expected to be spent, meaning the long-term average, assuming a stable grants program, will be in line with the budget approved by the DAO.

FWIW, I think the ‘runway’ could be reduced to 3 months; we should be aiming to reapprove in January each year and a 6 month delay seems unreasonable.

1 Like
9

Appreciate all the great work on this program, Alex. I have a few things to address that could smooth along the agreements with the service providers as well as enhance accountability.

On the subject of the quarterly KPIs, I think this is a great addition and these KPIs should be added to the underlying agreements with service providers. We may want to make it clear from the outset that considerable thought should be given to these KPIs because the continued failure to meet them could result in a loss of funding. With this in mind, we may want to take a page from the EF’s grant program that permits revision of grant proposals during the evaluation process whereby someone from the DAO could potentially help breakdown proposals in modular parts and develop reasonable KPI’s that become part of the underlying agreement. This could help to ensure that the KPIs at issue are neither too simple nor too burdensome.

Concerning the ‘flexibility in work’ section, my suggestion would be to have this apply to projects that fall under a certain monetary value or are projects that are experimental, early days, or otherwise nascent in many ways. We would not want a project that is significantly funded and for which the DAO spent a great deal of time refining the proposals and KPIs to have the ability to unilaterally change direction.

And finally as a general matter, for the proposal format I would suggest – again taking a page from the EF – that the candidates address whether there is a specific problem they are attempting to solve, how the project would benefit ENS, and whether the project complements others’ efforts or projects.

Looking forward to working with you on this important program again.

3 Likes
10

@AvsA - When you mention “The Working Group”, which specific working group would this be? This seems like a critical role for whichever group takes it on, and I think we’ll want to be crystal clear about the evaluation responsibilities.

Of the four eligibility bullets, I notice the first two could leave room for interpretation:

  • The applicant must be an existing company with an established team and reputation.
  • The company or its team members must have prior experience with ENS, blockchain, or domain-related projects.
  • Neither the company nor its team members may reside in OFAC-sanctioned countries.
  • The company must secure endorsement of at least 10k delegated ENS tokens, either through public backing by a delegate or by demonstrating support via Snapshot.

Should we consider making these more technically defined so that stewards have specific criteria to measure against? Anything we can do to remove subjectivity and potential debates about personal preference in the evaluation process will be crucial.

@Alexu - I think we need to be especially careful here.

For streams that could be over 1 million USDC per year, we’d need extremely clear guidelines about what constitutes critical failure and cut-off. I can imagine this leading to some contentious arguments between the decision makers and the failing provider if we all aren’t working from crystal clear, DAO-approved guidelines.

How would you envision structuring these KPI evaluation criteria in a way that would make failure self-evident?

11

Hey Spence, I’m in violent agreement that we would want this to be spelled out very carefully. I suggest the underlying agreement contain language that would permit the termination of funding to stream recipients only after repeated failures to meet KPIs or material breaches of the agreement. These provisions would require the DAO to provide written notice of the failure to meet certain KPIs, then the recipient would have a significant cure period to correct the deficiencies (or develop a plan of action to correct the deficiencies), and then only after repeated failures would the DAO have the discretion to terminate funding.

That’s the very broad strokes of the process but we can build into this however many steps and stages we would like.

1 Like
12

Would that mean that the DAO could exercise this discretion through a social proposal?

Would the funding termination be subject to a social proposal rather than an automatic or predefined mechanism?

13

I think there would be value in some sort of DAO focus group informally having a think about what they’d like to see. This is more for prospective applicants than the delegates. It could also coincide with some marketing of the program across platforms (X for example) to try and get more teams involved in the ecosystem.

Delegates can vote how they choose of course, and (as I see it) the program would still welcome novel ideas outside of the list of ‘things we would like to see’.

As with everything in life, this is a trade-off. The DAO should (of course) be financially prudent but it’s a balancing act. If the DAO want’s teams to think outside the box, and develop novel solutions to as-yet unknown problems there needs to be some level of flexibility.

Is the implication here that some Service Providers in the first year didn’t deliver? In principle the original terms gave the DAO powers to stop streams, but again it requires human bandwidth - a resource that is in limited supply.

This comes full circle to my original point, namely that the program needs clarity on what it intends to achieve. Objective clarity. If that is literal ‘service provision’ - ‘the DAO wants this, who will do it, and for how much’, well defined KPIs make much more sense.

No. it couldn’t and shouldn’t (IMO) be.

14

Thanks @AvsA for your continued work on this and the comments from everyone else on the thread!

One theme stands out: we need a framework that handles everything from smaller, experimental teams to those offering more critical infrastructure. Reading through @clowes.eth’s comments, the suggestion to clarify what kinds of applicants the DAO would like to see makes sense, especially given ENS Labs’ focus on protocol-level engineering.

@5pence.eth raises important points about eligibility criteria and Working Group responsibilities. Perhaps we could tighten the language around “established team” and “prior experience” with specific metrics, while clearly defining which Working Group owns the evaluation process.

On the KPI framework, I appreciate @Alexu’s suggestion for a staged approach to enforcement. This could work alongside an interim “top-up” mechanism for urgent needs between formal cycles, helping us maintain program integrity while providing needed flexibility.

Hope this helps! Excited to see where we can take things from here!

3 Likes
15

We should establish clear categories—such as an “Experimental Research” group to explore innovative technologies and a dedicated alternate website builders team—to ensure every funded initiative directly meets ENS’s needs. Funding decisions would then be based on how proposals address unmet needs, offer innovative solutions, and include clear, impactful roadmaps.

Specialized categories not only enables high-risk/high-reward projects that might be overlooked in standard models but also diversifies our service portfolio to drive valuable initiatives. Any new categorization should be developed through broad community discussion, allowing us to adapt as the ecosystem evolves. This balances accountability with innovation by measuring tangible impact rather than solely on financial metrics or historical performance.

It’s also important that service providers are not overlapping with ENS LABs Development. I would suggest collaborative discussions amongst provider candidates as well as initiatives accepted in the past so that everyone is on the same page.

1 Like
16

In addition to the above and other ideas, taking a page from the Optimism Developer Advisory Board could help bridge the technical divide. We, as a delegate and grants council related member at the OP Collective, are benefited from them on various perspectives.

A dedicated advisory board (or member) in this context would break down complex proposals into clear, digestible summaries for non-technical delegates, and enhance oversight and accountability in evaluating service provider proposals during their terms.

We believe it’s worth exploring how such a board could integrate with a potential SPP review team (most likely Metagov WG + alpha?)

1 Like