Voting Report (Avsa.eth)

Service Provider Program Program Discussion and Admin
1

This year we’ve had a lot of great teams with strong talent. In an ideal world, we could afford to fund most of them. But the reality is that we have limited resources. In fact, given the decaying subscription revenue and the extended bear market, the DAO is currently spending more than it realistically should. That said, I see this spending as an investment in great teams.

The pressure is therefore on to make sure the teams we fund are the ones most capable of ensuring not only a sustainable third season of the SP program, but also a much stronger financial position for the DAO as a whole next year.

This is why ranked choice voting is so useful here — we are not just voting yes or no, we are prioritizing the proposals, hoping that as many can be funded as possible in the right order.

My Criteria:

  1. Strategic Importance to ENS — exceptional teams that I believe can take ENS to the next level and expand its scope.
  2. Crucial Tools from Solid Teams — talented teams building essential infrastructure, but not necessarily expanding ENS’s boundaries.
  3. Extended Asks — bonus scope from teams above.
  4. Nice-to-Haves — good ideas that would be beneficial, but aren’t priorities.
  5. None Below — proposals I don’t believe should be funded at this time.

Strategic Picks

NameHash
An outstanding team who shipped a lot last year — and more importantly, have a clear strategy and understanding of ENS’s financial sustainability. I trust them to execute and prioritize responsibly.

Blockful
Their contributions to ENS governance and protocol development speak for themselves. Disclosure: I have a financial stake in Blockful, but that stake exists because I support them — not the other way around.

Ethereum Identity Foundation (EIF)
I didn’t support EFP last year, but this year I think they’ve clearly matured into a project with broad identity utility across Ethereum. I trust Brantly to ensure they become the default stack for ENS identity.

Namestone
Slobo.eth has delivered time and again. Namestone has become foundational for offchain resolver infrastructure, and I want to see that continue.

Unruggable
I voted against them in their off-season request for funding last year, not due to lack of trust, but because I felt their proposal belonged in the SP program. Now that they’ve applied through the right channel, I’m fully supportive.

Unicorn.eth
I was skeptical last year, but they built and delivered. Their strategic vision for onboarding users through ENS subdomains is compelling, and I’d like to see them go further.

Solid, But Not Strategic

eth.limo
This is critical ENS infrastructure. Their proposal doesn’t add much that’s new — but it doesn’t have to. This is a public good we must fund.

Agora
They’ve built valuable governance infrastructure, and I want to avoid over-reliance on any single provider. Agora is a solid alternative to Tally and Snapshot.

Tally
Like eth.limo, this isn’t about innovation — it’s about continuity. Tally is integral to our governance workflows, and we should support that.

Lighthouse Labs
I wasn’t very familiar with their work before, but I appreciate their contribution to the SPP2 interface itself. That kind of practical involvement matters.

Namespace
They’re doing real work, but their scope overlaps with many others. I’m supportive, but it doesn’t stand out. See edit at end of this post

Promising Experiments

3DNS
This is a bold and visionary proposal. I’m excited about what they’re trying to do — bringing traditional domains into ENS natively is a huge opportunity. The only reason it’s not ranked higher is that they’re a newer team without much prior presence in ENS governance.

ZK Email
I admire the ambition here — linking zero-knowledge proofs with ENS identity is a cool idea. But it feels more like ENS is being asked to fund ZK research that may or may not yield useful results.

dWeb.host
Tools for decentralized websites are always welcome. I used to think this was central to ENS — in practice it’s more niche. That said, dWeb seems capable and aligned.

ENScribe
Naming contracts with ENS is important. But the budget here seems high for the scope offered. Good project, not urgent.

WebHash
Useful tooling, but overlaps heavily with dWeb.host and others.

JustaName
Seems like a decent team, but very similar to Namespace and Namestone — and with less history of contributions. See edit at end of post

None Below

These are proposals I don’t think should be funded this year. Some are AI-driven governance tools, some appear to be established projects looking to tack ENS onto their pitch, others just lack a compelling need.

I’ll refrain from naming all of them here, but I will call out one:

Wildcard Labs
Their proposal this year is nearly identical to last year’s. And while they were funded then, they offered no updates, no public engagement, and made no visible effort to contribute to the ENS community in the interim. The last mention of Wildcard Labs on the forum before this application was… their last application. That’s not acceptable. This was a stain on the Service Provider Program and might be a good argument for having a dedicated working group to make sure to follow Service Providers.

Have I treated your project unfairly? Do you think I have overlooked something important? Feel free to contact me directly on telegram At AlexVanDeSande and we can have a chat.

Updates: I’ve spoken with many teams over the last few days, looked over adoption metrics, GitHub activity and even heard from developers from competitor teams, and have decided that I had overlooked both Justaname and Namespace’s contribution, specially given their ask sizes. I have since reviewed my position and updated my ballot.

5 Likes
2

@Avsa

Thanks for your message — I’ve just read your post regarding our team’s lack of updates on this forum, and I wanted to respond sincerely and give more visibility into what’s been happening behind the scenes.

You’re right to point out that we haven’t communicated enough publicly. We did share many of our challenges — technical and otherwise — during Ecosystem working group calls, but I now realize that wasn’t enough. That’s on me, and I take full responsibility for it.

When we were accepted into the program, our vision was ambitious but simple: let users manage their ENS records from any L2. We wanted to make ENS truly accessible, no matter which chain users were onboarded from. That vision guided everything we did.

The first major hurdle came when Optimism announced they were shifting to fault proofs. At the time, we had already built a resolver based on their existing system. It left us at a crossroads: ship what we had — knowing it would be obsolete — or pivot and rebuild around a future, still-in-development standard. It was made more complex by our goal of building a unified Superchain resolver that would support all OP Stack chains, some of which had signaled a move to fault proofs but without any clear timeline.

We brought this to the Ecosystem working group early and were advised to separate the implementations for fault-proof and Bedrock chains. That was a difficult but necessary change in direction. We went back, rebuilt our architecture, and eventually launched our records management frontend at ETHSafari 2024 — with support for Optimism, Base, and Mode.

That launch should have been a win — and on paper, it was. But in practice, it exposed a fundamental flaw in our approach, one we hadn’t fully considered. Since our goal was to let users update records from any L2, and have them resolve correctly, it meant our gateway would need to check every supported chain for each resolution request — to determine which record was most recent. That might be fine for two or three chains. But not ten. Not dozens. Not the entire L2 ecosystem.

When we realized this, it was absolutely devastating. This wasn’t a bug — it was a foundational limitation. I remember the exact moment it hit us — it felt like we were staring at the edge of something great, but also realizing we had no way to cross. It was the hardest day I’ve had building on ENS. We were days away from an Ecosystem call presentation, and I truly didn’t know what we were going to say. It felt like our platform, the one we had poured so much into, might not be viable after all.

Then — almost out of nowhere — we got a lifeline. Optimism announced upcoming support for Superchain interop. That changed everything. With interop, users could interact with any L2 (e.g., Mode), but have their records ultimately saved on Optimism. Suddenly, our gateway no longer needed to query multiple chains. Resolution could scale, and so could our platform.

We shared this breakthrough with the Ecosystem working group and quickly followed up by launching records.xyz — our L2 records manager — with support for Base and Optimism. We haven’t expanded to more chains yet because interop isn’t live, and scaling without it would take us back into the same architectural trap.

We did deliver a working platform. We’re proud of that. But we also recognize that our biggest failure was in communication. We should’ve posted more often and more transparently, even when things were hard — especially when things were hard. I let embarrassment and self-doubt get in the way of building in public. That’s on me.

But I also want to be clear: my team does not deserve the criticism. They worked relentlessly under difficult and changing circumstances. They stayed committed to the vision, even when it nearly broke us. If there’s fault here, it’s mine alone.

I’d be grateful if you — and the rest of the DAO — would take a fresh look at our application and what we’ve built. We tried to do something that hadn’t been done before. We almost failed. But we didn’t. And we’ve grown a lot through the process.

1 Like
3

Thanks for the long response @stevegachau.eth . I appreciate that development can be challenging, we can work a long time in a solution to only find that it’s not workable, or that the whole market can change underneath us. I’ve gone through that experience multiple times in many startups. But still, it’s a crucial lesson to always keep your main stakeholders (be investors, partners or in your case, DAO delegates) in the loop. Preferably in a documented way they can later check (if they don’t participate in all ecosystem calls). Failing is part of the process, but communicating failure properly is better than silence. I do hope you and your team will learn and grow from that experience and maybe we will work together again in the future.

But, right now, this year that doesn’t change my vote.

4

Thank you for your support! Our team looks up to you and your contributions to ENS and everything you’ve done!

With that, it’s important for me to clarify:

I’m not sure who ‘many’ others are – there’s Namestone and JustaName, and the overlap is in ‘subname infra / tooling’.

As far as differentiators go:

  • I believe Namespace is the only team with an SDK that offers unified support for L1, L2, and Offchain subnames. + Front-end apps for name+subname registration, minting, management, record updates (on different chains - almost ready in v2), and listing with the biggest set of features for customizing subname registrations, and other cool features like registration widget, subname frames, etc.

  • Secondly, I’m not sure if other teams have specifically mentioned in their applications a dedicated BD+DevRel team to actively drive adoption through partnerships and developer integrations, and other GTM and distribution strategies, as we do, because we believe that resolution and integration across the Web3 ecosystem is what make ENS powerful and superior to competitors. With respect to other teams doing good in this area, I believe we have already done very well and probably have the best pending integrations and partnerships, especially considering the resources and leverage discrepancy. Shoutout to JustaName for doing good work on this and shooting for enterprise adoption. And shoutout to Brantly, who I believe will do exceptionally well here in the upcoming years with EIK.

  • Also, I don’t think anyone explicitly said they’ll be building in the AI agent space, more specifically, building an ENS-based AI agent registry as an identity layer for agents. Which is a new, untapped market with a lot of potential, currently being overlooked… which also makes us different.

  • I also don’t think anyone truly embraced the spirit of public knowledge-sharing as much as we did. We shared everything from kickstarting quarterly reports (that are now mandatory), market research, case studies, shared industry insights, use cases, value prop for different products, distribution strategies, potential partnerships, wrote and published >100 pages of articles, and so on, which also makes us little different.

We’ve consistently delivered more with less than almost anyone – products, apps, features, partnerships, integrations, BD efforts, appearances, events, publishing, and so on.

The reason I’m saying all of this is because we’re confident in the uniqueness and value of our work, and after putting our hearts and souls into ENS for 2+ years, we just wanted to make sure we’re accurately represented and not be viewed and remembered as someone who “didn’t stand out”, as you said, because we extremely value your opinion and analysis, and I’m sure others do too.

I apologize for the lack of clarity in our application, and if I wasn’t able to convey what I had hopefully answered in here. I’ll work on improving that.

Fully respect your voting choices, happy to answer any questions or clarify any points. Once again, thank you for your vote, Alex. It truly means a lot! :saluting_face:

2 Likes