[TEMP CHECK] [EP 5.29] Funding request for Unruggable to build and operate a network of gateways supporting the rollout of ENSIP-19: EVM-chain Reverse Resolution

[5pence.eth]

After extensive review of the comments and discussions surrounding this proposal, I wanted to share my analysis of why I voted “For”.

Primary Objections

The main objections to this proposal generally fall into four categories:

1. The USDC funding request is too high
2. The ENS token allocation is too large
3. Questions about operational competency
4. Process concerns about graduating from the Service Provider Program

Addressing These Concerns

Token Allocation

The revised proposal reduced the ENS allocation to match what was given to Service Providers, added a one-year cliff, and included the DAO’s right to revoke. These terms are actually more restrictive than the precedent we set when we distributed ENS to Service Provider teams earlier in the year, which substantially addresses the initial token concerns.

Funding Amount & Competency

What I found particularly insightful is that multiple delegates who opposed this proposal indicated they would support the same funding amount if it were structured within the Service Provider Program. This suggests that neither the USDC amount nor team competency are the core issues at hand.

The Real Question

This leaves us with what appears to be the central question: Should this team be allowed to propose graduating from the Service Provider Program through this direct DAO proposal?

While I absolutely appreciate the concerns about setting precedents and complicating governance, I believe this specific case, despite some imperfections in the process, deserves proper consideration. No one here denies that Unruggable has demonstrated consistent, high-quality contributions to ENS over multiple years. The gateway infrastructure they’ve helped develop will become a critical component of ENSv2. As we move forward with this infrastructure, having additional skilled and known resources working on this, and other tasks, is a good investment in the protocol.

Why I Voted For

My support for this proposal ultimately comes down to two key points:

1. If the primary objection is about process rather than substance (team quality, amount requested, or competency), then we should evaluate the team’s right to make this request on its merits. After all, there currently is no SPP year two that has even been formally proposed, let alone codified by DAO vote (while acknowledging Avsa’s valuable initial thoughts posted in the forum and clear intentions to have the program renewed). I don’t believe it’s appropriate to ask a proven team to put their planning on hold while these details are worked out and hopefully approved in a way that ultimately might or might not work for them.

2. A healthy DAO ecosystem should actively support the growth of independent teams that have demonstrated their value. While this may introduce some additional complexity to our governance, the benefits of having multiple capable teams building critical infrastructure outweigh these challenges.

Looking Forward

This vote represents an important moment in ENS governance. While I respect the desire to maintain clean processes and clear precedents, I believe we must also remain open to evolution when teams demonstrate exceptional value and capability. I believe Unruggable has done that and that we should evolve with their success.

[simona_pop]

I appreciate the conversation around this proposal and all the in-depth dialogue over the past few weeks. This is clearly a significant infrastructure challenge, building and operating a reliable network of gateways across multiple chains, with high uptime and low latency, requires substantial engineering capacity, continuous monitoring, and proactive development.

Over the past few days, I’ve spent considerable time trying to understand if this proposal introduces any technical vulnerabilities that may affect ENS. I want to kindly thank @nick.eth, @ricmoo, @5pence.eth, @brantlymillegan, and the Unruggable team for sharing their insights on the technical aspects. Humbly, as a non-technical delegate, I recognize the importance of obtaining as much context as possible on decisions where I lack full knowledge. Their input has been invaluable in helping me grasp the complexity and magnitude of this undertaking.

Given all this, I believe this is a worthy experiment — and at its core, crypto is built on experiments. Experimentation is woven into the very fabric of our culture; it’s how we explore, iterate, and find better paths forward. We try things out, and if they work, we continue to build. If they don’t, we pivot and learn.

With the safeguards of the fleshed out milestone-based accountability and the ability to cancel funding streams if the work is subpar or milestones are unmet, we are not making an open-ended commitment. If the Unruggable team fails to deliver or refuses to collaborate with third-party providers should the work prove beyond their capacity, we must be firm in turning off the stream. While it’s true that stream cancellations haven’t always been enforced as they should, accountability works both ways — for the teams and the DAO. We need to ensure we take firm action if this experiment does not prove beneficial to ENS. This can also be a setting of precedent for these types of proposals being handled responsibly by the DAO should they not meet the necessary requirements for overall benefit to ENS.

One critical challenge here has been the chicken-and-egg dilemma facing the Unruggable team. They are currently a small, dedicated team undertaking a project of significant magnitude. Without the necessary funding, they can’t hire the talent required to scale their capacity and handle this challenge effectively. Asking them to wait for funding before they can expand places them in a tough position, one that hinders their ability to deliver at the scale needed. As 5pence.eth pointed out:

“A healthy DAO ecosystem should actively support the growth of independent teams that have demonstrated their value. While this may introduce some additional complexity to our governance, the benefits of having multiple capable teams building critical infrastructure outweigh these challenges.”

It’s also important to emphasize that this is not a vote against ENS Labs or Nick. I hold deep respect and appreciation for everything Nick has built and the incredible contributions ENS Labs has made and continues to make. We are all here because of it. I’ve been in conversation with Nick over the past few days, and these discussions have helped clarify the complex nuances of this decision. Avoiding black-and-white thinking is crucial here. Plurality of perspective is what ultimately gets us to a better place. Looking beyond binary choices, we open up our ability to hold two seemingly opposing ideas and synthesize them into a higher understanding so that we may arrive at integrative thinking, where multiple perspectives are woven together to form innovative solutions. This decision reflects that spirit: supporting the Unruggable’s team while acknowledging the capacity and excellence of ENS Labs. Both can contribute meaningfully, and this isn’t a zero-sum scenario.

On the process side, I echo a lot of the concerns raised here about the need for due process.
The current limitations of the Service Provider Program make it difficult for teams to scale effectively. If we expect them to meet the demands of such a large undertaking, we should give them the resources and support necessary to grow sustainably. Asking them to wait for funding can risk stalling progress and prevent them from building the capacity they need to deliver. Yes, the SP programme is new and improvements should and can be made. Feedback from other service providers in this thread indicates that while the program has great positive aspects, there are areas requiring improvement to better support the growth and stability of essential services within the ENS ecosystem.

Do I wish this proposal spent more time in discussion? Yes.
Several solutions were proposed, including interim funding until the next SP vote, changing the SP structure or increasing SP budgets. It is frustrating that these pathways weren’t pursued, as they might have led to a more unified vote. However, here we are. I also think a lot more public and transparent conversations need to happen - concerns around intentions, technical skill and collaborative stance have not been expressed here. We need to become better at sharing doubts and having tough conversations in public - context is incredibly important in making decisions and again, should intentions here not be in the best interest of ENS, we need to take decisive action.

I want to emphasize that this decision is not made lightly. It reflects a careful balance of the trust expressed in the Unruggable team, acknowledgment of the magnitude of the task, and a desire to uphold due process within the DAO while pushing for improvements to said process.

In conclusion, I will cast a Yes vote for this proposal, with the understanding that milestones and accountability mechanisms will provide the safeguards needed to hopefully set this up for success for ENS. This is an opportunity to experiment responsibly, invest in critical infrastructure, and uphold flexibility and oversight. If the experiment doesn’t serve ENS, we will turn off the stream — but until then, let’s give it the space to succeed.

[nick.eth]

@clowes.eth

In the conversations that we have had, many have said that we could have just waited for next years Service Provider streams. Unfortunately this overlooks the fact that the Service Provider program is not designed to support the operation of core infrastructure

You keep asserting this, but without evidence. What about the service provider program makes it unsuitable? Your current EP expires in one year; why is this a better fit for your needs than the service provider program?

@clowes.eth

We need a stable stream (albeit one that can be turned off by the ENS DAO at any time) that is not constrained by a fixed-sized budget or subject to annual (or biennial) renewals

Can you elaborate on what you mean by “not constrained by a fixed-size budget”?

[clowes.eth]

@nick.eth

You keep asserting this, but without evidence. What about the service provider program makes it unsuitable?

We love the Service Provider program! We just don’t think that in it’s current form it is appropriate for funding core infrastructure.

Our position is that the program should be used for bootstrapping new teams, and further iterations should not be overly complex. Unfortunately, the discussions that have taken place around the Service Provider program in direct response to our Temp Check have only introduced more uncertainty and possible complexity into the program.

The operation of core infrastructure should be a standalone consideration put directly to the DAO, and we should be held accountable each year. These proposals can be put to the DAO at the same time as, for example, the ENS Labs request to minimise delegate load.

@nick.eth

Your current EP expires in one year; why is this a better fit for your needs than the service provider program?

The stream is ongoing if the appropriate USDC approvals are made. The executable approves funding for 1 year to minimise risk of financial loss to the DAO should unknown bugs in the Superfluid contracts be found.

Next year, alongside our accountability reporting, we would submit a proposal directly to the DAO to increase the allowance. We expect this to be a formality as we will deliver on our promises.

@nick.eth

Can you elaborate on what you mean by “not constrained by a fixed-size budget”?

I was alluding to the fact that the Service Provider program has a fixed budget of $3.6M, and is a competitive process. This year we have spent close to 25% of our time on DAO funding. Financial prudence is necessary, but if we are successfully delivering on our promises we should be able to minimise that process overhead and focus on contributing to the ecosystem.

[nick.eth]

@clowes.eth

Our position is that the program should be used for bootstrapping new teams, and further iterations should not be overly complex. Unfortunately, the discussions that have taken place around the Service Provider program in direct response to our Temp Check have only introduced more uncertainty and possible complexity into the program.

You haven’t engaged with these attempts at all; if they didn’t meet your needs, why not explain how it would need to change?

@clowes.eth

The operation of core infrastructure should be a standalone consideration put directly to the DAO, and we should be held accountable each year

This seems directly at odds with what you said earlier:

@clowes.eth

We need a stable stream (albeit one that can be turned off by the ENS DAO at any time) that is not constrained by a fixed-sized budget or subject to annual (or biennial) renewals

@clowes.eth

I was alluding to the fact that the Service Provider program has a fixed budget of $3.6M, and is a competitive process

Do you anticipate needing more than 3.6M in annual funding? Why couldn’t the program cap be adjusted accordingly? It’s the same money, regardless of how it’s allocated.

@clowes.eth

This year we have spent close to 25% of our time on DAO funding.

I’d suggest that this could have been substantially lower if you weren’t determined to resist all offers of compromise and instead force this through.