Service provider program scope and deliverables

Service Provider Program Program Discussion and Admin
1

I’m excited to see the service provider program being renewed for another year. In its first year, it’s already funded some outstanding providers who have delivered real, meaningful improvements to ENS and the DAO.

At times I’ve seen some confusion and disagreement around the purpose of the service provider program. While my opinion here is purely my own, I think it lines up well with Alex’s vision, and so I thought it might be useful to share it here so others can add their two cents as well.

The most essential attribute of a service provider is right there in the name - they are providing a service to the DAO. The program does not exist to fund arbitrary public goods, or as seed funding for a venture - it’s designed to offer payment in return for a service. Providers put forward a proposal stating what they can do and what it will costs, and the DAO, through its delegates, decides if that is a service the DAO needs, and if the cost is reasonable.

Implicit in that is that the service on offer must be something the DAO needs or wants.

So, what does the DAO need? In my mind there are three broad categories:

  1. ENS infrastructure: Anything that improves ENS as a whole. This includes development work on smart contracts, frontends, libraries, etc that increase the usefulness or scope of ENS. The majority providers in the first program round focused on this, and it’s where I hope the majority of service provider program funding will go this year as well.
  2. Outreach and integrations: Efforts to increase the adoption and usage of ENS, such as integration support for wallets, DApps and exchanges, marketing efforts, or other related initiatives.
  3. DAO infrastructure: Anything that improves the operation and smooth running of the DAO. This includes improvements and automation of the DAO’s processes, voting frontends, tools for transparency and accountability, communication tools, etc. Many things in this category will result in producing public goods that are useful to other DAOs as well, which is great - as long as the funding is used first and foremost to build something that the DAO needs and wants.

If your project, however noteworthy, doesn’t fit into these categories, please consider applying to the public goods working group for funding instead. We’re not trying to fund all of Web3 here; even if your project integrates ENS at its very heart, the service provider program exists to build ENS - not the whole ecosystem of products that use or integrate it. The DAO simply isn’t big enough to fund every worthwhile project that uses ENS; we need to focus first and foremost on building ENS itself.

Finally, a note about duplication: Last year we had several providers, all individually credible, who were proposing to build essentially the same thing. As a delegate, if you see this happening, consider choosing the candidate most likely to succeed and campaigning for them with other delegates - even if you think there are multiple good options. As a prospective service provider, look at other proposals and consider how best to differentiate yourself. Unfortunately, due to the nature of ranked choice voting, even with best intentions all around the DAO may end up appointing multiple parties to do the same thing, but we can at least strive to minimize duplicated efforts.

23 Likes
2

Thanks for sharing your personal framework for thinking about the service provider program.

I’d like to highlight a key phrase in your post:

In other words, the post above is Nick’s personal vision for the Service Provider program, it is not the official criteria for the program approved by the DAO.

Here is what the DAO approved regarding scope for the program:

Screenshot 2025-03-06 at 8.06.28 PM
Screenshot 2025-03-06 at 8.06.28 PM1494×776 66.6 KB

Note that Nick’s framework is significantly more specific and narrow than the official terms approved by the DAO.

Nick and other delegates may vote based on whatever reasons they want, but I don’t want delegates to read Nick’s post above and mistake them as the official rules for the program.

1 Like
3

Don’t forget to quote the preceding paragraph, too:

3 Likes
4

Thanks for sharing your personal positioning on the program @nick.eth

@5pence.eth alluded to this in the Metagov calls, but perhaps posts like this could be collated in the new ‘Service Provider’ forum category. Perhaps a ‘Delegate Viewpoints’ section would be useful to supplement the existing categories and allow a public platform for delegates (who are representatives of the DAO) to express their viewpoints on what they would like to see.

Generally I agree with your three categorisations, and your commentary on duplication. I think more intentionality should be given by the DAO to designing this upcoming iteration of the program so as to avoid unnecessary duplication.

I think acknowledgement of this (which I agree with) is indicative of a viewpoint that a misallocation of limited resources will likely occur. That is, in my opinion, a problem.

2 Likes
5

Unfortunately, I don’t see a practical solution within the constraints of the SPP as voted on. An alternative program that avoids this would look quite different - starting with the approval (by voting) of a set of RFPs, and then the election of a single provider for each RFP.

6

Article III continues:
“ENS governance will not allocate funds to a team or individual who does not commit to uphold the same principles outlined in this constitution in their use of the allocated funds.”

Though I think it is unlikely any such team nor individual that secures the required SP votes falls into this category - the Constitution is binding and a reasonable interpretation suggests at least some Governance oversight notwithstanding the DAO vote.

With respect to the additional points Nick brought up, particularly vis-a-vis returning SP’s, I think they are in a unique position compared to first time applicants and returning (unsuccessful applicants). Specifically, unlike the later, who will presumably submit nominations with proposed budgets the returning applicants can give transparent and itemized breakdowns reflecting how their budget was allocated/spent, or not, in the first year.

Why It Matters: The DAO can’t confirm alignment with Article III. This minimizes risks of misallocation and could be helpful to delegates concerning themselves with “duplicates” as described by Nick. For example, if multiple teams are working on the same thing, the deciding factor could reasonably come down to which team was more effective with SP stream in the first year, which is about more than just absolute dollar amounts.

Benefits:

  • Accountability: Proves stewardship, builds trust.
  • Informed Governance: Delegates assess past impact.
  • Constitutional Fidelity: Upholds Article III’s mandate.
2 Likes
7

In my view, from a business perspective, our focus should be on developing ENS infrastructure that drives adoption and usage. Specifically, we should concentrate on attracting a new audience interested in owning second-level .eth domains and, more importantly, on developing infrastructure that helps retain these newly captured domain owners. This segment is crucial because it underpins the revenue generation powering the service provider program.

We should avoid prioritizing subdomains on other ecosystems. These subdomains, often minted for free or through third parties without revenue sharing with the ENS DAO and don’t contribute to the adoption of second-level .eth domains at all. In many cases, they are used primarily for airdrop hunting rather than for delivering long-term value.

Funding for subdomain and gateway projects should come from ecosystem-specific grants rather than from the DAO itself. For example, Optimism once provided such grants. I received one for building Opti.domains, where we developed the first OP Dispute Game Gateway, a generalized gateway for the superchain, and a UI for migrating ENS domains to Optimism. Despite these efforts, our team—and other grantees—haven’t received sufficient support from Optimism, largely because their vision is that governance should thrive independently of foundation support. Unfortunately, this approach makes it challenging to drive adoption within the Superchain under current market realities.

$1.2M/year might not be enough for the long term, especially as more chains are launched every year. There are now more than 20 chains in the Superchain. However, the revenue gain from this is less than 1% of the grant paid. Why don’t we collect money from these chains if they want the DAO to develop and maintain the gateway for them?

Ultimately, the most impactful areas for increasing the adoption of second-level .eth domains lie in decentralized web (dWeb) initiatives—such as eth.limo, DNS services for .eth domains, website builders, and services like Vercel for ENS. However, only one project (eth.limo) was selected in the first service provider program, while many of the other selected projects focus on subdomains and L2 gateways. These latter efforts neither increase second-level domain adoption nor contribute to revenue growth for the ENS DAO.

It’s best to have two teams competing on the same topic. This setup creates an environment where both teams are driven to deliver the best product as quickly as possible. Adding more than two teams, however, tends to yield diminishing returns, with no significant improvement in speed or quality.

This contradicts your perspective on DAO infrastructure in the first service provider program.

In my view, the current DAO infrastructures are now sufficient, with most having already raised fund.

Rather than channeling additional funds directly from the DAO, these infrastructures should be supported by ENS Labs through traditional outsourcing contracts.

RFP is the best option, but the topic should be set by someone with deep understanding and strong business skills—someone who knows what ENS really needs and how much it should cost to boost adoption of .eth 2LD domains. The DAO itself doesn’t have this level of business expertise.

Also, having two funding pools is better than one. If five existing established teams each ask for $800K to $1.2M, there won’t be room for new, promising teams, which kill innovation. If the Solana accelerator saw this, they might laugh.

We should look at how Optimism’s governance grant has evolved for RFP and learn from how Solana accelerators fund new, high-potential teams.

$2k - $50k grants distributed by Ecosystem Working Group stewards. (Ref: ENS Ecosystem Working Group Grants 2025)

For those who say new team should apply to Ecosystems grant, don’t you see a huge gap between $50k and $300k? (Note: Maximum to Minimum comparison)

2 Likes
8

Yes, I have changed my opinion since then.

There’s a great deal still to be improved. For example, the proposal pipeline is still almost entirely manual, with multiple steps (temp check, proposal onchain/snapshot, updating the governance docs) that require manual copy-and-paste work and as a result are often forgotten or done incorrectly. Likewise there’s a lot that can be done to improve transparency both in terms of explaining the impacts of an executable vote, and in better exposing delegates’ voting records, as well as financial transparency for the DAO.

ENS Labs focuses on building ENS’s core infrastructure - maintaining and improving the DAO’s tooling is not inside our remit.

9

100% in agreement with this.

Agreed. A personal opinion - I don’t get the whole subdomain thing. I think that the logic from the Service Provider/ecosystem end is that we can’t do anything with the second level namespace and as such the third level is what is available to us.

The direct value add from a truly successful subdomain project would not be direct DAO revenue but rather bringing eyes (and usage) to ENS. uni.eth and base.eth subnames are great examples of this, and are certainly successes from a number of names registered point of view but I’d be intrigued to see alternate measures of success like ‘How many are used as primary names’.

I don’t agree with the latter point noting that Unruggable Gateways was designed for primary names, and down the line Namechain forward resolution - it is core ENS infrastructure. I accept that whilst Namechain is ‘in development’ it’s value to the second level namespace is minimal.

I note you link to Unruggable’s proposal from the end of last year. It is still my view that not enough resource has been committed to Gateways - their maintenance and their marketing. L2 rollup creators need to want to be supported - at the moment my read of the room from… talking to them… is that they don’t really care all that much. There is very much a chicken and egg problem whereby L2 providers are busy innovating (ZK, Interop etc) and want to see demonstrable value add and competence in advance of committing resource. That proposal noted a similar point that if we could increase bandwidth with appropriate resource we could innovate further on the tech, build/maintain relationships, and create solutions that over time other chain operators would scramble to support and want to pay for.

True. Competition is good, it creates accountability and incentivises innovation. I think the first iteration of the program gives us data - teams x, and y did this, did they do it well? did it add value? do we need them both/all?

ENS Labs is not the DAO. The DAO should pay for DAO infrastructure. If that should be through the Service Provider program is a different question. I won’t labour the point - i’ve said it before - but core infrastructure, i.e stuff we definitely need that has been demonstrably executed by competent teams should be funded directly by the DAO.

The long and the short of my opinion is that all third party developer teams who provide value in excess of their cost to the DAO should be funded. Yes, I accept, value is a subjective term.

Agreed. Further to this, the value per dollar on smaller teams seems to me to be significant.

Also worth noting that rollup teams are innovating. Other external teams are attacking ‘identity’ as a concept, and at EthDenver I saw a few that are doing it really well. ENS can not rest on its laurels and hope to live perpetually on its first mover advantage/network effects.

I wanted to also acknowledge your contributions here @chomtana and thank you for taking the time to contribute in depth. It’s useful to bring in insight from other ecosystems too. It is bemusing to me that so many stand to gain financially from the program yet very few opine (at least publicly) on it.

2 Likes
10

Chiming in as someone deep in the subname trenches.

Although I’m in favour of building infra, I want to note that building something doesn’t automatically equal adoption and usage.

Are you suggesting we prioritize businesses that maximize profit? That doesn’t seem to align with the ENS DAO’s mission. I’m not against it, actually, I quite enjoy that aspect of crypto. But if that’s the approach, speculation-driven businesses would have priority I assume. Right now, no other model in crypto drives more usage or revenue than speculation (more or less). Just look at the ENS hype cycle when 3 and 4-letter names were trading on ENS Vision for 50-100 ETH. During those few months, registrations surged more than at any other time.

Subnames are currently in my opinion the best and only way to horizontally scale and grow the ENS userbase and let people, communities, apps, companies, rollups, etc. run their own namespaces… collectively participating in a paradigm shift from machine-readable addresses to human-readable names as primary identifier. This directly aligns with the ENS Constitution - to become a global namespace (extend DNS and I assume be present everywhere else - hence our multichain support). I am biased, yes, but I also spent two years talking to hundreds of potential clients from different industries, and they all like subnames. Especially the tokenization part and using .id version of their brand for usernames.

It would be ideal if other L2s wanted to pay us and we then integrate ENS there, but that’s not the case, unfortunately. We’re currently looking into enabling some out-of-the-box subname-as-a-service for RaaS providers and I assume monetization can happen somewhere but my primary objective is to integrate .eth offchain subname registrations everywhere and wait to see how we can leverage Namechain once it’s live.

As far as the Subname $$ value goes - I agree, they don’t currently add $$ value to the DAO but if that’s an issue, that can be changed. Also, currently, the majority of subnames are offchain (estimated around 15M) which can easily be migrated to Namechain (at least that’s what we’re pushing for) which would directly add $$ value to the DAO.

This is an overgeneralization. Out of an estimated 15M subnames, I doubt that there is more than 0.5% used for airdrop farming. Just an assumption.

Everything else, I agree with you.

2 Likes