Service Provider Program Watch

🌱 ENS Ecosystem
1

SPP Watch

The Service Provider Program (SPP) was renewed in April for 4.5m/yr USDC.

It seems useful to have a thread on how the selected service providers are complying with the requirements the ENS DAO has imposed on them.

This is a first draft and hope folks come up with improvements. I suspect most welcome greater visibility into service provider performance.

Requirements

The requirements are described in the Metagov responsibilities section, which is as follows:

Responsibilities for Metagov Working Group
The ENS DAO can terminate streams for any reason following the proper governance procedure and after a DAO vote. Additionally, Metagov or Ecosystem Stewards can and should trigger a Service Assessment if any of these conditions are met:

  • A service provider fails to publish their quarterly report twice
  • A service provider falls short of the KPIs on their proposal twice in a row.
  • A service provider is unresponsive to attempts to contact them
  • A service provider is believed to be actively participating in a behavior or project that is considered harmful to the ENS system or brand.

The program’s renewal also required the service providers to MIT License their work.

All work done directly funded by this program must be Open Source and Freely Licensed (MIT). Service Providers are free to also have proprietary codebases but the works established in their proposals and quarterly reports must also be available on github or other public repositories.

Who Is This For

This thread is for delegates, future SPP applicants, community members, current service providers, and stewards.

2025 Quarterly Reports - Updated as of August 18, 2025

Links to the reports all service providers and when they were posted. Missing reports, mark with a :x:.

Provider Q2 Q3 Q4
eth.limo Aug 4
blockful :x:
Ethereum Identity Foundation Jul 17
Unruggable Aug 12
NameHash Labs :x:
Namespace Jul 14
ZK Email n/a
JustaName Jul 14

ZK Email’s short funding period warranted “n/a.” JustaName, though new, shared a report and it seemed worthwhile to note it above.

Service Provider KPIs

The KPIs are pulled from the service provider applications, as quarterly reports come in it may make sense to track reporting and performance of KPIs.

eth.limo

We will report quarterly uptime with a target SLA of 99%, in addition to aggregate traffic metrics and dWebsite security reports.

blockful

Quarter KPIs
Q1 ENSIP specification documentation completed - Initial ENSjs integration live
Q2* Complete implementation with ENSjs + integrating ENSjs into our frontend for testing usability
Q3* Integration with at least 2 major subdomain providers (base.eth or uni.eth for example) - Developer documentation and examples published
Q4* Full integration support for ENS Manager App and ENSv2 - 3+ production implementations in ecosystem

*Some KPIs inevitably depend on third-parties progress

Ethereum Identity Foundation

Per quarter: a minimum of 3 new EFP integrations with ENS improvements as needed, at least 1 new feature shipped in EIK, at least 1 new feature shipped in EFP app

Unruggable

None

NameHash Labs

Our KPIs for each quarter are to deliver a minimum of 90%+ of that quarter’s total Target Deliverables within the quarter.

Namespace

Dev Portal - KPIs

  • Implement the listed deliverables from above
  • Conservatively: 25+% quarterly growth on measurable outcomes
  • Moonshot: 500k+ offchain subnames
  • Provide usage/growth stats in mandatory Quarterly reports

Namespace App - KPIs

  • Implement the listed deliverables from above
  • Conservatively: 25+% quarterly growth on measurable outcomes
  • Moonshot: 100k L2 subnames
  • Provide usage/growth stats in mandatory Quarterly reports

Namespace SDK - KPIs

  • Implement the listed Deliverables from above
  • Provide usage/growth stats in mandatory Quarterly reports

Agents.Domains - KPIs

  • Implement the listed deliverables from above
  • Conservatively: 25+% quarterly growth on measurable outcomes
  • Aiming for: 100k subnames as AI agent ENS profiles
  • Provide usage/growth stats in mandatory Quarterly reports

Dedicated BD Arm - KPIs

  • Conservatively:
    • Identify and reach out to >100 potential clients through a strategic, relationship-driven approach – leveraging our network rather than relying on cold outreach (no aggressive and spammy DMs/Emails).
    • Aim for 20 high-value partnerships with key industry players.
      Deploy 10 more white-label subname minting websites for clients.
    • Add Subname registrations with 3 wallets
    • Add subname registrations for 3 AI launchpads
    • Enable Subname-as-a-Service for 2 new rollups.
    • Enable ENS services on 2 dev tooling marketplaces
    • Add Subname registration with 2 games
    • Add Subname registrations for 2 payment-related apps.
    • Launch subname-as-a-service with 1 RaaS provider
    • Launch subname-as-a-service with 1 WaaS provider
    • Deploy 100+ ENS widgets across different websites
    • Reach 10,000 SDK installs, measured on NPM

ZK - Email

  • Successfully deploy ZK email verification resolver on Namechain by launch
  • Onboard at least 5,000 ENS users to verify credentials via ZK email within the first 6 months
  • Reduce proof generation time to under 1 minute on average
  • Achieve 95%+ success rate for verification attempts (our current failure rate is ~1% and we will target that, but we want to keep a buffer for issues with client side proving, RAM, protonmail, load, or odd mail providers).

JustaName

Product Development

  • Quarterly release of significant platform improvements.
  • Infrastructure uptime >99.9% with regular security audits.
  • Launch at least 3 ENS-focused public goods.
  • Support EVM chains into launching their ENS subdomains (similar to base.eth).

ENS Ecosystem Adoption

  • 10,000 subnames issued by May 2025.
  • Target 100,000 subnames by EOY 2025.
  • Manage 300+ active second-level ENS domains by end of year.

Enterprise Integration

  • Onboard at least 1 prominent Web3 brand per quarter.
  • Engage at least 5 significant enterprises (1M+ user potential or recognized legacy brands).
  • Complete 2 deep, customized integrations placing ENS at the core of enterprise UX.
  • Enable at least 3 significant brands to issue identity-powered wallets

KPIs are not fixed and may change over time. For example, one company currently has none, others have a few, and some have dozens. It may be worth harmonizing this for consistency.

Posted in Ecosystem and tagged “service providers.” If needed, we can move this to the service provider category. Feedback on both substance and location is welcome.

Thank you to every service provider working to make ENS great.

5 Likes
3

It’s been a while since SP program was in effect, and I believe it is ecosystems group responsibility to design adequate reporting framework, so far nothing until today. I think the fact that we are only seeing now some sort of effort to design reporting framework reflects very poorly on performance of ecosystem group.

Additionally I raised many times in the past the problem of conflict of interest, it was never acknowledged. While Slobo himself is the recipient of SP grant, he cannot moderate the program, because of CoI. Suddenly now that Slobo’s project been voted out from SP he started to pressure other SPs on KPIs.

4

This is not correct. As confirmed by @netto.eth on today’s MG call, responsibility for reviewing service providers lies with MG.

Your frustration is understandable, but it should not be directed at ecosystem.

Also, your statement on the MG call calling Slobo incompetent was uncalled for. The post is an accumulation of factual information from service provider proposals. It seems more likely that your frustration stems from personal dislike of Slobo rather than the substance of the content.

2 Likes
5

this your subjective feeling, please refrain from posting subjective statements as this is against community guidelines

1 Like
6

Appreciate efforts that support the DAO in tracking service provider performance.

In case there’s any questions about the upcoming Quarterly Report from NameHash Labs, we have a big SPP2 Q1 over-delivery that will soon be reported that goes far beyond our proposed KPIs for the quarter.

Our quarterly deliverables for SPP2 are based on quarters relative to the commencement of SPP2, rather than traditional quarters that are relative to the calendar year. Appreciate how this can be confusing.

Here’s the calendar we use:

SPP2 Quarter Begin End Quarterly Report Due
Q1 Jun 1, 2025* Aug 31, 2025 Sep 10, 2025
Q2 Sep 1, 2025 Nov 30, 2025 Dec 10, 2025
Q3 Dec 1, 2025 Feb 28, 2026 Mar 10, 2026
Q4 Mar 1, 2026 May 31, 2026 Jun 10, 2026

*SPP2 commenced on May 26, 2025. However please note the self-imposed rules for quarterly reports in our SPP2 proposal:

  • Each quarter listed in these tables is relative to (the commencement date of SPP2 funding streams) + (3 months * quarter) ~ ending day of that calendar month.
  • Each quarterly report will be delivered within 10 days of the conclusion of the quarter.

Therefore the table above applies for our SPP2 quarterly reports.

We look forward to sharing an exciting and very successful SPP2 Q1 report with the DAO in early Sept.

2 Likes
7

Hey Slobo, thanks for posting. Some thoughts below.

We already have KPIs and mandatory quarterly reporting baked into the SPP program (voted on and passed by the DAO), which I believe is enough. To my knowledge, there was never a mention of an “SPP Watch” in this year’s program, and it comes across as an attempt at increased oversight layered on top of the existing pressure this role brings. And since it wasn’t defined in the program, I’m not sure how SPs will feel about it being introduced now.

I believe this post was written with good intentions, to enhance transparency and keep everyone accountable for their work, which I believe is needed. That said, those who warrant closer examination, for any reason, should be treated as edge cases and handled individually and privately, one-on-one, by those that MetaGov appoints in charge for this. I believe that approach is in the best interest of the DAO. It shows respect for the program and the Service Providers we’ve chosen, maintains the ENS reputation, and upholds professionalism in the DAO. I see literally no upside in publicly exposing someone’s shortcomings in their work. Moreover, negligence by one (or a few) Service Providers should not impose stricter policies and scrutiny on everyone else. Yet that’s exactly how this thread comes across. Preemptively.

Note on KPIs and the defined scope of work in our applications:

Even though we’re on track to hit all of our KPIs earlier than expected, I want to advocate for some flexibility there. A single year in crypto moves faster than a decade in traditional industries. Expecting service providers to stick rigidly to their original application without any wiggle room for expansion is unrealistic and counterproductive. I’m sure it’s fine for some, but for some, it’s very limiting and detrimental to their success. Freedom to build, experiment, and pivot to a degree is very important, especially in our industry.

I believe there are Service Providers whose work occasionally may fall outside their original application, but it’s clearly valuable for ENS. Some SPs dedicate time and energy to initiatives beyond their original scope, yet bring real benefit to the DAO and ENS protocol.

I’m sharing all of this to make the case for the fact that 1) extra work shouldn’t be discouraged, and 2) allowing more flexibility around KPIs, as long as the work being done is meaningful and creates a net-positive impact for ENS and the DAO.

We’re on the frontlines of innovation, under heavy pressure to build, contribute, report, and hit KPIs in the ever-evolving space, building solely on ENS, long-term thinking, with no financial certainty year after year. We are here (all-in) because we want to be here, because we like ENS and the DAO, and truly believe in our collective work. We are here for ENS as much as ENS is here for us. And more rules, more scrutiny, layers of oversight, “death by committee”, just risks hurting performance rather than helping.

Totally agree. Most welcome visibility, accountability, and KPIs, generally speaking, not just from Service Providers. And these should apply universally to everyone receiving any kind of DAO funding.

If we’re serious about transparency and accountability, we should hold everyone in the DAO to the same high standards.

5 Likes
8

Excellent feedback. This was partially a by product of trying to have one place for just SPP folks.

However, this can become, as it often does in DAOs just another resource.

image
image500Ă—283 22.6 KB

I thought I’d give it a try and start the conversation.

9

Maybe it might even make sense to start the quarters with a buffer to make them align with the year end. With the first report only being due after 3rd quarter closes. However, not sure if that would require a change to the program terms. Appreciate the feedback.

Keep the comments coming!

10

Just curious, are any developer teams working on a unified dashboard that monitors SP activity across streams?

I appreciate the research Slobo.eth has done to maintain visibility and accountability for grant recipients, and I believe a dedicated dashboard could save delegates time in the future while supporting more informed decision-making.

1 Like
11

I believe @blockful (@zeugh.eth) showed an anticapture dashboard that tracks updates posts / KPIs.

@Meta-Gov_Stewards are working on a thread rn for tracking q updates, KPIs. etc. We are hoping to include a public GitHub so that third-party dashboards can access the information easily!

**Update → correct @'s

1 Like
12

Wouldn’t it be worthwhile to issue an RFP for this? Considering there are many talent pools to draw from, a competitive process may encourage higher quality proposals and broader participation.

Happy to hear blockful.eth are stepping up, just wondering if their bandwidth allows them to tackle this expediently.

2 Likes
13

The idea on getting the updates into a public git is that the info is accessible. Then any third party can access the data more easily.

Blockful is just one example of a developer working on this (they presented on the metagov call). It would be great when the information is more easily accessible for more developers to integrate it. We haven’t had a conversation about RFP’ing a centralized dashboard for SPP2 - it’s a good idea.

2 Likes
14

We are working on a quite simple and straightforward solution, linking teams, their proposals, the budget approved, and quarterly reports. It also shows the date limit expected for the reports of each quarter.

At this time, it’s as far as we’ve designed and shouldn’t take too long to be available.

We considered tracking each KPI separately, but there’s a big difference in how each team described their KPIs. While some are easy to track, others are more challenging to analyze, so we’ve decided to leave that extra work out of this first version.

5 Likes