[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

[jefflau.eth]

@clowes.eth

This proposal represents the actual cost of the work that we are proposing, running and supporting the core infrastructure for ENSv2. It is hard to argue that it is a large ask when ENS Labs has a budget of $9,697,500 per year, and controls an allocation of 1,250,000 ENS tokens for future contributors.

“X has Y funding” is not an argument for why your proposal is reasonable.

@clowes.eth

The audit will be over shortly, and the launch of ENSIP-19 will take place imminently thereafter. The funding of production gateways is just as necessary and critical as the audit.

@clowes.eth

We are asking for a continuous stream controlled by the ENS DAO, for the provision of 24/7 infrastructure critical to the layer two strategy of ENS. If for any reason Unruggable does not fulfil its responsibilities the DAO can turn off our funding (both USDC and ENS tokens) at any time

What many people are arguing here is that this proposal is already in excess of what Unruggable needs. And/or Unruggable is putting its own goals in front of what the DAO has resources for. Much of the work for gateways has been done and no one is arguing that production gateways are not critical, but likely does not require the expansion of the Unruggable team to 6-8 engineers.

@clowes.eth

ENS Labs is using our work while simultaneously discouraging us from taking on further responsibilities. If the DAO follows this path it will set a concerning precedent and discourage contributions to the ecosystem.

That isn’t what ENS labs is doing. We already disputed how much you will need for funding privately. Rather than discouraging you from taking on further responsibilities, we’re merely disputing what we think it will take to run these gateways in addition to insinuating that ENSv2 is at risk if this proposal goes through.

@nick.eth

If the compromise of interim funding and a revised streaming program adjusted to Unruggable’s needs isn’t acceptable, we’re prepared to run the gateways internally ourselves, within the budget already approved for ENS v2. We believe that this may be the safest option anyway given everyone agrees that gateways are a crucial component of the v2 infrastructure. This would also make ENS Labs fully accountable for uptime and low latency.

I also want to reiterate what Nick said as an option if discussions are off the table. We don’t want delegates to feel like they’re torpedoing ENSv2 by not voting for this.

I will also be voting against, and would like delegates to not abstain on proposals that could set unintended precedents

[Premm.eth]

I really appreciate this response to our proposal, as up until this point, the discussions have mostly focused on the methods for funding, DAO procedures, the number of presentations made, milestones, etc. Some have even suggested that this funding request is coming at the “wrong time” and that “the proposal does not require approval before year-end.”

@jefflau.eth

“X has Y funding” is not an argument for why your proposal is reasonable.

@jefflau.eth

What many people are arguing here is that this proposal is already in excess of what Unruggable needs.

Clearly, there is a double standard here when it comes to funding. ENS Labs has a budget of $9,697,500 per year, controls an allocation of 1,250,000 ENS tokens for future contributors, and is expanding its team from 21 to 33. Teams like ours and Eth.limo are being asked to provide critical infrastructure on shoestring budgets, and in the case of Eth.limo, are taking substantial legal risks for which they don’t have the budget.

@jefflau.eth

And/or Unruggable is putting its own goals in front of what the DAO has resources for.

The idea that the DAO cannot afford our proposal is completely false and not based in reality. Additionally, the accusation that Unruggable is somehow in this for themselves is not supported by reality, nor do any comments in this thread suggest otherwise.

Nick.eth:

“So long as Unruggable continues to excel, there’s no reason to believe the DAO would arbitrarily cancel its funding, particularly while it is helping provide core infrastructure services.”

SpikeWatanabe.eth:

“Unruggable’s been with ENS since forever, and there is no doubt that they’ve been very useful community members.”

Cap:

“Unruggable Labs is one of the most important and dedicated ENS contributors. They are one of the very few people who genuinely and passionately care for not only ENS but for building the new Internet that is Ethereum-aligned, decentralized, trustless, ENS-centric, and in line with the original ethos of crypto.”

Coltron.eth:

“It is my understanding that Unruggable is one of the service providers showing up every day for ENS, and it’s clear they’re all in.”

Brantly Millegan:

“If they’re the right ones for the job, I think their proposal is reasonable. If they aren’t, then we shouldn’t be funding them at all. But it seems to me they are doing essential work for ENSv2 plans.”

AvsA:

“Unruggable has clearly demonstrated its value as a Service Provider, and their contributions to ENS core infrastructure cannot be understated.”

Estmcmxci:

“Of course, the DAO should fund developers which have proven to provide integral improvements to the ENS protocol.”

Vegayp:

“Unruggable’s work on gateways is clearly valuable, and I would support funding if milestones and timelines were attached to ensure transparency.”

@jefflau.eth

Much of the work for gateways has been done and no one is arguing that production gateways are not critical, but likely does not require the expansion of the Unruggable team to 6-8 engineers.

Unruggable proposes to manage the critical task of resolving all reverse resolutions from five of the most popular L2 blockchains by operating production-grade infrastructure. To claim that the gateway work is already done is clearly an attempt to distract from the actual proposal. On the contrary, we have detailed in previous replies the need for ongoing maintenance work in response to the frequent updates to L2 rollup architectures.

Considering the current ENS Labs funding per employee for their planned team expansion ($9,697,500 / 33), it amounts to $293,863 per employee. Unruggable’s planned team expansion to 7 (an average of 6-8) members is $171,428 per employee. It is evident that we are not requesting an unreasonable amount of funding for our team, which underscores the double standard in funding teams other than ENS Labs to perform critical work for the ENS DAO.

@jefflau.eth

That isn’t what ENS labs is doing. We already disputed how much you will need for funding privately. Rather than discouraging you from taking on further responsibilities, we’re merely disputing what we think it will take to run these gateways . . .

We are happy to have a straightforward and technical discussion about the cost of our proposal. Unfortunately, this has not been the case so far.

As it stands, ENS Labs is stating what amounts to “it costs too much” without providing any justification.

@jefflau.eth

I also want to reiterate what Nick said as an option if discussions are off the table.

We built Unruggable Gateways. Our gateways are operational and ready for production deployment. ENS Labs’ suggestion of $200k in interim funding with a possibility of additional funding in three months is not grounded in the realities of operating critical infrastructure for the ENS DAO and continues to show a double standard in how teams providing critical infrastructure for ENS are treated. Threatening to take back the work from us if we do not accept this offer should be seen for what it is, a threat to force us into accepting inadequate and insecure, shoestring funding.

We look forward to having a straightforward discussion about funding Unruggable to provide gateway services for Arbitrum, Base, Linea, Optimism, and Scroll, as well as preparing our team to offer forward resolution services for Namechain. The ENS DAO clearly requires the work we are doing, has the funding available, and the only questions remaining are who should perform the work and what it should cost. We stand firmly behind the numbers in our proposal as the minimum necessary to deliver the quality required to operate a global network of 24/7 gateways, on which ENS fundamentally depends.

I would also like to add that, even though this discussion has been contentious, I want to reiterate that we are all on team ENS! This debate is an important one aimed at moving ENS forward. In all our discussions the love for ENS has never been in question.

[thedevanshmehta]

I’m a newcomer to ENS but long time contributor to Arbitrum DAO, so maybe I can give some examples from there that can help resolve this debate.

Initially, Arbitrum DAO was hesitant to support proposals where we have to make 0(n) decisions, where n = number of projects. See for example the debate around the so called Arbitrum Coalition, where Blockworks, Trail of Bits & Gauntlet proposed to give services to the DAO.

https://forum.arbitrum.foundation/t/proposal-the-arbitrum-coalition/19145

That proposal was rejected as similar to the case here, the DAO did not want to approve individual service providers. Instead, we make a 0(1) decision that this is a need we want to address, there is an open application process anyone can apply under with this particular selection process. So even though Arbitrum Coalition got rejected, the same proposal but with an open process got approved (the ARDC). Which was actually good since different members got appointed than those proposed in the coalition.

Tally | Arbitrum | [Updated] Proposal to Establish the Arbitrum Research...

Later on ARB DAO realized that when certain high context and fantastic people apply, we should make 0(n) decisions and not be too hard on that. This is why we appointed Entropy Advisors to take lead on getting DAO affairs in order.

https://www.tally.xyz/gov/arbitrum/proposal/22562217031893796518849144396978331510254494883851105730012486117405397295942?govId=eip155:42161:0x789fC99093B09aD01C34DC7251D0C89ce743e5a4

This is all a long way of saying, if you think there are alternative service providers make it an open process. Unruggable should then take the $200k offered in stopgap funding until the open process can be completed.

But if like Entropy you absolutely want them to be the ones charging ahead, then go the route of considering a 0(1) decision to evaluate them and not just create a general framework.

[5pence.eth]

On Out-of-Band Requests

I believe it’s acceptable for Service Providers or stream recipients to make “out-of-band” requests when facing exceptional circumstances. These could include unexpected infrastructure needs, surprise legal expenses, or work that wasn’t originally scoped in a service provider proposal but requires attention.

At the same time, delegates should absolutely evaluate these requests critically and potentially view them negatively if they don’t meet the bar for “exceptional” circumstances.

Current Situation

Setting aside the complexities that the service provider program adds to this discussion, there appears to be broad agreement on several key points:

1. ENSv2 will require gateways to be run for effective L2 resolution
2. Unruggable has demonstrated exceptional work and has maintained an excellent reputation through long-term, high-quality contributions to the ENS protocol
3. Unruggable wrote the open source gateway code that will be used for the ENSv2 gateways
4. ENS Labs is trusted as an authority on the matter because they employ the core protocol developers and have successfully hosted all critical infrastructure thus far

The Decision

I appreciate @thedevanshmehta perspective:

@thedevanshmehta

This is all a long way of saying, if you think there are alternative service providers make it an open process. Unruggable should then take the $200k offered in stopgap funding until the open process can be completed.

But if like Entropy you absolutely want them to be the ones charging ahead, then go the route of considering a 0(1) decision to evaluate them and not just create a general framework.

Whether intended or not, we find ourselves in an “open process” of evaluating gateway providers. The decision appears to be between two options:

Option A: Unruggable receives the proposed funding and operates the gateways

Option B: ENS Labs operates the gateways instead of Unruggable and covers the costs using their existing DAO funding for ENSv2

(This assumes we aren’t able to find an Option C)

We Need More Info

To make an informed decision between Options A and B, we need to understand the functional differences in outcomes for the protocol to properly evaluate if the increased cost is warranted.

@unruggable, will you expand on your vision for running the gateways? What benefits would your approach bring to the ENS ecosystem that we wouldn’t see without this investment?
For clarification, would success on this proposal mean that the DAO would stop the $400k stream you receive from EP 4.9 and that you wouldn’t apply to future rounds of that program?

@Labs, assuming that running these gateways will cost more than $0, what would you have to sacrifice to redirect some of the $9 million in your funding to support these gateways yourselves?

[nick.eth]

@clowes.eth

You have stated that the ask is too big without any explanation in regard to the costs of modern software development and infrastructure provision.

Unruggable likewise has not provided any explanation of how they arrived at the staffing numbers you say you require.

@clowes.eth

You have stated that the ask is too big without any explanation in regard to the costs of modern software development and infrastructure provision. We welcome all independent analyses of the reasonableness of this ask.

An independent analysis sounds like a good idea, and I’m sure it would go a long way to reassuring delegates. How long will it take you to arrange one?

@5pence.eth

@Labs, assuming that running these gateways will cost more than $0, what would you have to sacrifice to redirect some of the $9 million in your funding to support these gateways yourselves?

We expect that ongoing operation would require one full-time developer working on the code - handling changes from L2s as well as making ongoing improvements - and two devops engineers to maintain the infrastructure, though they would likely not be occupied full-time; this is just the minimum number to ensure people can take time off and so that oncall schedules are not unduly onerous.

In terms of infrastructure costs, we’re seeking quotes from infrastructure providers, as it’s likely to be both more affordable and more reliable if the gateways can be colocated with an existing provider’s nodes rather than running nodes independently.

@Premm.eth

Threatening to take back the work from us if we do not accept this offer should be seen for what it is, a threat to force us into accepting inadequate and insecure, shoestring funding.

There’s no “threat” here, nor any work to “take back”. You’ve said yourself that Unruggable is not funded to operate the EVM Gateway; that’s why you’re seeking funding here. I’m pointing out that Labs is also capable of running the gateways, and is prepared to do so if necessary.

[lightwalker.eth]

I support Unruggable’s request to “graduate” from the Service Provider Program and receive an indefinite funding stream.

Let’s put aside for the moment questions if X or Y is the right funding amount. When a Service Provider ships infrastructure for ENS that gains widespread adoption (as Unruggable will imminently achieve) the DAO should consider them to be sufficiently derisked.

A sufficiently derisked provider should “graduate” from the Service Provider Program to receive an indefinite funding stream. I see no reason why they should have to wait until the end of a stream to make this transition.

The key problem: Service Providers have the foresight of sudden binary survival outcomes under uncertainty.

This “graduation” mechanic is part of a solution. Providing a potential 2-year stream is better than a 1-year max, but it doesn’t fundamentally address the risk of a hard cliff with extreme uncertainty and outcomes.

Here’s an example of the problem: When a team’s entire funding is going up for a binary vote in a few months, it can create a huge amount of uncertainty for the future.

All businesses experience uncertainty, but this is not normal uncertainty. In normal business you generally don’t have radical binary survival outcomes where being a few votes shy of funding mean you immediately shut down your whole org.

Maybe a team does a good job, but is it good enough to “keep the lights on” at all? Will the team be a few DAO votes short of another competing proposal and therefore have their funding radically drop to 0? Will they be a few DAO votes short and have to lay their entire team off? Should Service Providers freeze their hiring for 6+ months before the next voting cycle?

Underperforming teams need to have their funding cut. No one’s debating that. However, unless its a special situation, I hope a mechanism could be created for the second derivative of a funding stream not to experience sharp changes (either up or down). We need mechanisms for funding streams to be gradually adjusted across time. If the DAO determines a team is doing well, gradually increase their share of a pool of funding. If a team is struggling, gradually decrease their share (perhaps until 0).

Additionally, the total pool of funding that’s being distributed should also be gradually adjustable across time in response to changes in DAO revenues without radical sharp changes.

ENS will benefit if we can provide more continual market feedback mechanisms to all contributing efforts. If a team should change course, it’s good to let them know early. If a team is doing well, provide them with better long-term stability so that they can make better long-term decisions.

---

Congrats again to the Unruggable team for their dedication to build and ship these new gateways. Your work is key to the ENS multichain narrative. You’ve also shown the success potential of the Service Provider Program to create value for the ENS DAO and the broader ENS Ecosystem.

Well done !

[ENSPunks.eth]

There is a lot to unpack in this thread between the draft proposal, the total request for funding, and the service provider program.

I support Unruggable and their desire to seek additional funding from ENS DAO to operate/maintain the ENSV2 gateway they developed while a service provider. However, even as I write this, I think it is at least foreseeable I would have a different reaction to other Service Providers making supplemental requests for funding, even if for work outside the original scope of the service provider funding.

Insofar as the proposed amount of the funding, I don’t have the requisite experience or background to evaluate the reasonableness of the funding request. Generally, I am not for adding unnecessary formalities, but this funding request (and thread discussion) likely justifies an evaluation from an independent 3rd party as has been suggested and discussed through this thread.

In case it helps more technical delegates, I will sum up my non-technical understanding and outstanding questions. Unruggable is asking for USDC (I’ll call “Operational Funding”) and $ENS allocation (I’ll call long term DAO/Protocol Alignment). I believe Unruggable doesn’t just desire but requires, for all the reasons they stated in the thread, the requested allocation for the long term DAO/Protocol Alignment. While Unruggable is of the opinion the Operational Funding is consistent with industry standards, Nick.eth is of the opinion the Operation Funding exceeds the budget necessary for the operation of the Gateway. Reading between the lines - which I probably shouldn’t do but I did - I take this to mean that ENS Labs specifically could operate the gateway for less than the requested amount, which Unruggable doesn’t necessarily dispute, but believes is due to the ENS Labs existing alignment to the DAO/Protocol which has secondary effects like their ability to recruit, hire, and retain world class talent.

If my summation is at least somewhat correct, my remaining questions are:

1. Is there anyone outside of Unruggable and ENS Labs qualified and in a position to operate the Gateway?

2. If there are other teams qualified to run the Gateway and they would have interest in doing so, would their requested funding be reasonably consistent with Unruggable’s Operation Funding and likely include request for token allocation for long term alignment?

3. If it were realistically just Unruggable and ENS Labs in a position to operate the Gateway, is Lab’s ability to operate it with less funding and/or no token allocation directly attributable to the existing long term alignment with the DAO and Protocol vis-a-vis token allocation? In other words is it essentially an upfront cost to get Unruggable into a position where they will be able to attract world class talent to Unruggable, benefiting the ENS Ecosystem overall?

Lastly out of all the existing service providers I find it persuasive that Unruggable should potentially get “spun out” of the Service Providers program and as what I’ll call a “core infrastructure provider.” However, whether this needs to happen or not, I do not know, and I will probably defer to Alex, and others, with a more insightful vision for the Service Providers Program and the best way to move forward.

[clowes.eth]

Thanks, Spence/Nick, for steering the conversation back to the substance of our proposal, especially the costs and value Unruggable would provide to the ENS DAO by supporting reverse resolution for L2s through gateway services.

@5pence.eth

For clarification, would success on this proposal mean that the DAO would stop the $400k stream you receive from EP 4.9 and that you wouldn’t apply to future rounds of that program?

Yes, absolutely. We would withdraw from the Service Provider program and not apply to future rounds. This means the overall increase in the DAO’s support for Unruggable would be $800,000 USDC per year (not $1.2M as it may appear). I acknowledge that we should have communicated this more clearly.

@nick.eth

@clowes.eth

You have stated that the ask is too big without any explanation in regard to the costs of modern software development and infrastructure provision.

Unruggable likewise has not provided any explanation of how they arrived at the staffing numbers you say you require.

In the Team Expansion section of our proposal, we outline the addition of an expert blockchain engineer and a DevOps engineer. Additionally, we anticipate needing a second DevOps engineer to support our production deployment. Our DevOps engineers will be strategically located to provide 24/7 network monitoring and response.

This expansion will enable our current team to focus on research and development for the evolving L2 landscape, communicating with rollup providers to stay ahead of their development roadmaps, maintaining and iterating on the codebase including verifiers that will need updates as L2s evolve, supporting external teams like Base (who have already expressed interest) in leveraging the Unruggable Gateways network, and continuing to contribute to the ENS ecosystem.

We put a lot of thought into analyzing these numbers, and as Nick mentioned earlier, this is already a reduced ask from our original proposal.

We need to be realistic; without this level of funding, it won’t be possible to deliver a high-quality product to the ENS DAO or support the rollout of ENSIP-19, which ENSv2 critically depends.

We have also committed to reducing our dependency on DAO funding if the operators of the L2 chains we support provide direct funding.

@nick.eth

@clowes.eth

You have stated that the ask is too big without any explanation in regard to the costs of modern software development and infrastructure provision. We welcome all independent analyses of the reasonableness of this ask.

An independent analysis sounds like a good idea, and I’m sure it would go a long way to reassuring delegates. How long will it take you to arrange one?

To clarify, I was suggesting that we would welcome comments from other independent DAO participants with specific domain knowledge (i.e. unassociated with ENS Labs or Unruggable).

@5pence.eth

@unruggable, will you expand on your vision for running the gateways? What benefits would your approach bring to the ENS ecosystem that we wouldn’t see without this investment?

Having built the gateways, we possess an intimate understanding of their architecture and operation.

With this funding, we will continue building a specialized team focused on researching all available options, identifying the most effective approaches, and delivering optimized results tailored to ENS’s unique needs.

Specialized teams with unique skill sets, dedicated to specific challenges, can achieve results that larger, less-focused teams often cannot.

In short, we will succeed because we are a small, agile team with a single focus and a clear, well-defined measure of success - uptime and latency.

As we’ve said before, we’re committed to providing these services to the ENS DAO. While this debate has been lengthy and at times challenging, we truly appreciate the energy and dedication to ENS that has come through in this temp check. It’s clear that, as a DAO and a community, we all care deeply about the future of ENS and are committed to making ENSv2 a complete success!

[superphiz]

I support this proposal and look forward to voting in favor of it as an ENS delegate.

[thedevanshmehta]

@clowes.eth

We have also committed to reducing our dependency on DAO funding if the operators of the L2 chains we support provide direct funding.

I wanted to know tangibly how this would work. Let’s say that Arbitrum decided to fund $50k for integration - would an equivalent amount now be returned to the DAO, used to extend your existing contract as a no cost extension or taken by unruggable as a bonus?

The reason i ask is that this offers a compelling reason for why ENS may want to delegate this function to service providers rather than the labs taking it on themselves. I can see arbitrum funding unruggable to do this service, but don’t see us doing the same for ENS labs as easily.

So while the L2 expansion is imminent, ENS Labs offers backstop funding to unruggable to ensure the work is done at high quality. If alternative funding comes in, either contract gets extended at no cost or some funds returned to the endowment. If no funding comes in, then the entire $800k is spent by ENS.

There is a moral hazard issue where unruggable doesn’t have an incentive to apply for extra funds if the backstop is offered but we see loan guarantees in the real world all the time, like the US Export Import bank for example.

[Premm.eth]

There are many ways that Layer 2s can “pay” for these services. Ultimately, it is the ENS DAO that is providing reverse resolution services to Layer 2s, initially without asking for anything in return. Over time, as L2s recognize the value of these services, it is likely that they will be willing to reimburse the ENS DAO with grants of their own.

I can envision a scenario where a grant is given both to Unruggable, in cases where enhanced services are provided - for example, offering highly optimized gateway services that go beyond what the ENS DAO is already funding - and simultaneously, funds are allocated directly to the ENS DAO as reimbursement for the upfront expense of funding Unruggable.

The most likely scenario is that an L2 not included in this proposal will eventually request gateway services. In such cases, Unruggable would be free to provide those services independently, without any moral hazard.

[AvsA]

I’ve had two calls with Unrugabble about this topic. I do think providers are within their rights to ask for out of band resources, and there should be a way for Service providers to “graduate” into their own stream, and I believe that Unrugabble definitely deserves the funding.

However…

I have provided a framework in which I believe this should happen in the Service Provider Season 2 program.

• Service providers have asked for more certainty on the continuity of the program: I have made all efforts to clarify that we intend to renew it and put forth dates
• Providers complained about instability of having to ask every year: I have proposed a two year stream for those who have overwhelming support
• Providers have asked for larger amounts: I am in favor of increasing the top ask from 1M (which nobody asked last year) to 1.2M to fit Unrugabble’s ask.
• Providers asked for less dependency on a binary political choice: I am open to more suggestions but there’s no way around the fact that any job requires supervisions, annual revisions, milestones etc. I am open to suggestions on how we can do this better.

While I would love to see more projects get larger funding and to have more healthy competition for ENS Labs, I would prefer that the follow the established process for this. It’s my opinion that with the Streams vote coming in the beginning of next year, there’s no point in having a separate out of band vote just for Unrugabble. I do not see what’s so urgent they can’t wait for another 2 months (specially considering the next 2 months are the holidays) or ask for a temporary bandaid to support whatever they need. I also would not like a contentious proposal to go forward that would hurt the relationship between labs and some service providers.

If Unruggable feels certain they will have the vote for this, then they would be even more confident that they would get it via the Service Providers stream.

@Premm.eth

AvsA:

“Unruggable has clearly demonstrated its value as a Service Provider, and their contributions to ENS core infrastructure cannot be understated.”

This quote should NOT be taken as a support for this particular proposal. I am supportive of the team. I would vote for a smaller ask and I would vote Unruggable for the stream renewal. I would NOT vote for the proposal as is.

[slobo.eth]

I’ve worked with the Unruggable team closely this year. They have been instrumental in helping NameStone (a fellow service provider) launch several projects. I also had the pleasure of spending time with Thomas and Prem during a casual offsite in Prem’s home state.

Despite my personal and professional relationship with Unruggable and their team, I feel the need to vote against this proposal for the benefit of ENS.

Unruggable’s core competency is gateway development. This has been stated and demonstrated by work completed so far. I can also vouch for their expertise in smart contract development and server-side programming.

As Unruggable stated, running gateways is critical infrastructure, and no one in this thread disagreed. My perspective is that ENS needs the best teams doing what they are best at.

I have not seen Unruggable’s qualifications for managing globally distributed infrastructure, aside from their work on developing gateways. After all, the best sports car drivers aren’t typically the engineers who designed them.

Could Unruggable learn to manage gateways at scale? Likely, but the question remains—would they be the best choice?

While Unruggable might eventually excel as an infrastructure provider, I see no compelling reason for ENS to take this risk now. ENS Labs, with more infrastructure experience, has indicated they can handle this within their existing budget. The choice is between investing $5 million ($1.2 million + $3.8 million in tokens) in a less-experienced team, though capable, or relying on a proven team at no additional cost. As it stands the choice is clear.

Lastly, the best company to handle infrastructure may not yet have been considered. It does not appear we, as ENS, have explored enough options.

To reiterate, I have great respect for Unruggable and their team of developers. However, when it comes to critical infrastructure, we must prioritize what is best for ENS.

[184.eth]

These are interesting remarks.

… in cases where enhanced services are provided - for example, offering highly optimized gateway services that go beyond what the ENS DAO is already funding

Is there sufficient definition or metrics for this to be assessed? Such a framework would allow delegates to make an informed assessment of product and value today, and in the future.

… an L2 not included in this proposal … Unruggable would be free to provide those services independently

The list of L2s in this proposal are “Arbitrum, Base, Linea, Optimism, and Scroll”.

How would you distinguish independently provided services from that which overlaps and utilises resources, products & development funded by the DAO? Additionally, with a loose example of unruggable receiving Optimism grants in 2024, how would the DAO delineate between outcomes stemming from independent initiatives and those derived from DAO funded work?

[estmcmxci]

@clowes.eth

To clarify, I was suggesting that we would welcome comments from other independent DAO participants with specific domain knowledge (i.e. unassociated with ENS Labs or Unruggable).

This discussion could benefit from input by independent experts to ensure an accurate assessment of the infrastructure costs. It might also help other delegates, including myself, who are not specialists in this area, to contribute more confidently.

—

@Premm.eth

Ultimately, it is the ENS DAO that is providing reverse resolution services to Layer 2s

I don’t necessarily see it this way. ENS DAO and its governance processes facilitated the creation of the Service Provider Program, which led to the establishment of Unruggable. Unruggable provides reverse resolution services to Layer 2 networks.

I primarily see the DAO as a mechanism for capital and resource allocation.

—

@AvsA

I also would not like a contentious proposal to go forward that would hurt the relationship between labs and some service providers.

I share some of the concerns raised here. Members of Labs have indicated they plan to operate the Gateways regardless of Unruggable’s objections. Perhaps we could revisit this path to ensure alignment and consensus among stakeholders before moving forward.

—

To @slobo.eth’s point, I don’t think we have considered all the options here. If Labs decides to operate Gateways at scale, it can be done without incurring additional costs. We should remain prudent stewards of capital.

This proposal has raised some important questions for me. While the team has done outstanding work, I believe it’s worth exploring alternative options or refining the approach to ensure alignment with our long-term goals and financial priorities.

[Griff]

I think this proposal is directionally correct. The ENS amount is VERY large. I would like to see a 2 year cliff and some sort of real vesting requirement… like milestones that need to be achieved to receive the ENS rather than the traditional “token unlock”. This is too much money to be given without some sort of formal agreement of what must be accomplished to hold Unruggable accountable.

I also think we are ready to see a tam graduate out of being a Service Provider and into the same level as ENS Labs. Of course the Labs team could do everything for us, and even do it for a bit cheaper, because they could hire a few more people and have all the other infra in place that it takes to run a business. But is that what we want? Unruggable needs to cover not only dev costs, but also, all the other overhead it takes to build and maintain a company (accounting, admin, etc) and I see their request, as expensive as it is, as reasonable especially when compared to ENS Labs.

The Service Provider effort was aiming to increase the number of independent teams building out ENS, and it succeeded. I would like to double down on that and see another team work along side Labs the way it is done with client teams on Ethereum. Unruggable is definitely a great option to elevate past Service Provider and into this status.

That said, I wouldn’t vote for the proposal as it stands as it doesn’t have enough accountability built in, but that is an easy fix.

[thedevanshmehta]

@AvsA

I do not see what’s so urgent they can’t wait for another 2 months (specially considering the next 2 months are the holidays) or ask for a temporary bandaid to support whatever they need. I also would not like a contentious proposal to go forward that would hurt the relationship between labs and some service providers.

@Griff

I wouldn’t vote for the proposal as it stands as it doesn’t have enough accountability built in, but that is an easy fix.

these 2 points are compelling reasons to take stopgap funding until the formal service provider round with in-built accountability systems and increased funding to meet unruggables needs.

I’ve seen in arbitrum that when a proposal gets contentious, proposers choose to withdraw rather than try ramming something through in the hope it squeaks through.

[hacktar]

Based on visible discussions, the proposal will likely require modifications before approval:

1. The amount of requested ENS tokens may need revision
2. A more detailed fund utilization plan will likely be required
3. The funding model might need to shift from perpetual to discrete with specific milestones
4. Clearer accountability mechanisms may be necessary

The proposal appears to have baseline support but will probably require a second iteration with greater detail and some substantial modifications before proceeding to a formal vote. The team’s track record and the strategic importance of gateway infrastructure work in their favor, but the financial structure needs refinement.

While I strongly support the technical vision and acknowledge the team’s valuable contributions to the ENS ecosystem, several key concerns need to be addressed before this can move forward.

I will be voting NO on the current iteration of the Unruggable Gateways funding proposal.

The gateway infrastructure is crucial for ENS’s future, and I believe a more structured approach would better serve both the protocol and the team’s objectives.

This is not a rejection of the team or the project, but rather a call for a more refined proposal that better aligns with prudent treasury management and governance best practices.

[brantlymillegan]

@nick.eth

Unruggable likewise has not provided any explanation of how they arrived at the staffing numbers you say you require.

@nick.eth

An independent analysis sounds like a good idea, and I’m sure it would go a long way to reassuring delegates. How long will it take you to arrange one?

These are fair questions, but a standard that Labs itself does not follow in their requests for much larger amounts of money. I look forward to similar breakdowns from Labs in their future budget requests.

[lefterisjp]

So I don’t like how contentious this proposal has become. Regarding the proposal itself I would like to repeat that the ENS amount is quite high and should be reduced.

Also agree with @Griff that a cliff would make sense to exist for claiming it.

Now onto the funding request.

I would strongly prefer the option for a bridge funding proposal and continuing with the Service provider program in the next year but moving this very same amount as part of the SP program.

But I also understand the SP program is made in a way that bigger asks have way less chance of being filled in. So we do have a problem to solve here. How do we make the Service provider program work for a funding request of this size @AvsA? Also why not have ENS Labs go through the same program? Why is it an exception and if it is why can’t others also graduate from the Service provider program?

Let’s analyze the funding request a bit.

Infra

$200k is for infrastructure costs for a year. This is something I am not able to judge, but may sound reasonable? I don’t know. Perhaps could be reduced? I really can’t judge this number as I have not ran such infra at this scale.

Operating

$1m for operating expenses and salaries of a 6-7 person team. Let’s say roughly $50k for travel/admin/legal?

Then if it’s 6 people that leaves us with $950k. So it’s 950/6 = $158.3k / year / per person on average. Which is quite high for me. But I do understand my salary views may be distorted due to living in Berlin/Europe.

Comparing the request with others

The only other similar request I have to compare with is ENS labs itself which asked for a $9.7m per year for a team of 20 people and wanting to grow to 35.

Using same calculations and adjusting for the team size of 35 let’s say roughly $300k for travel/aldmin legal. That would leave us with $9.4m for salaries. Trying to see the average per employee $9,400,000 / 35 = $268,571.42. Which is more than $100k more per year per employee than what Unruggable is requesting here.

So according to the standards ENS labs has for their own payroll I would say this request is low.

Though I do have to say that being asked to compare salaries of other people while looking at my salary as a European dev makes me feel very very uncomfortable.

---

I still don’t know how I will vote on this proposal. But some remarks:

1. This is a DAO and not a company. The DAO is heavily centered around ENS Labs and its close associates. We should allow it to be more like a DAO and give chance to other companies apart from ENS Labs.
2. Seeing people from Labs here say the request is too much while their own request a few weeks back was quite higher seems weird to say the least.
3. If operating the gateways is the problem some delegates stick with, the request could be separated into two. One for running the infrastructure and one for further development of the gateways. This way it may be easier to judge the two different things on their own merits? Though I am not sure I see why Unruggable could not operate the gateways. Have they given any reason to believe they are not fit for that purpose? Also keep in mind they developed them.
4. I am excited to see more companies take leading roles in both developing and running infrastructure for ENS and the DAO. Centralizing everything around a single company increases the bus factor and turns this more and more into a fake DAO.
5. We should all be on the same team. This proposal became a bit too contentious for my liking. I would like to see us work together towards making ENS great and making sure that all participants in the DAO, all companies and individuals building on it and dedicating years of their lives into it get properly rewarded and have aligned incentives. Think a bit on the message you want to show to the world for people wanting to come and contribute to ENS and the DAO.