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

We greatly appreciate your interest in our work and your willingness to support it!

To be clear, we are not seeking a grant to pursue independent projects or fund optional work. We are requesting stable funding from the ENS DAO to operate the core infrastructure essential for the rollout of ENSIP-19 reverse resolution and to build a team ready to do forward resolution for Namechain.

So far, I believe the discussion has not adequately addressed the necessity and benefits of the work we are proposing for ENS. A direct funding stream from the ENS DAO is not merely our preference - it is fundamentally in the best interest of ENS.

The success of ENSv2 is not guaranteed. Achieving it will require the collective support and hard work of more than just ENS Labs. For this reason, it is in the DAOā€™s best interest to create a stable funding stream for Unruggable, enabling us to dedicate ourselves fully to building ENSv2 and its success.

Our direct experience has demonstrated that the Service Providers renewal process does not allow us to attract and retain top-tier talent. This is not a point for debate - it reflects our lived experience and something we know to be true.

It is also important to clarify that direct funding from the ENS DAO via a stream does not equate to ā€œindefinite approval.ā€ The funding can be paused or discontinued by the DAO at any time. Suggesting that Unruggable should compete in an open funding process - likely involving upwards of 50 teamsā€“ for core infrastructure, upon which the success of ENSv2 and Namechain critically depend, is both impractical and counterproductive. Stable, direct funding ensures that we can focus entirely on delivering on our responsibilities and making the support of L2s and ENSv2 a success.

1 Like

Just playing devilā€™s advocate here, but Service Providers could allocate a portion of their budget to hire a governance analyst tasked with engaging the DAO to ensure alignment of interests.

If Iā€™m not mistaken, this seems to be a standard practice across the ecosystem.

I think the question is whoā€™s running the gateways.

I think they are. Perhaps I am mistaken?

  1. More detailed cost-structure breakdown for $1.2M

Yes this would help.

Our direct experience has demonstrated that the Service Providers renewal process does not allow us to attract and retain top-tier talent. This is not a point for debate - it reflects our lived experience and something we know to be true.

I understand that. Would you guys be okay with an interim proposal to cover expenses until the next tranch of the SP program which I assume would also increase the limits and funding given to projects?


@nick.eth , @AvsA and @katherine.eth what I see here as concerning is that we have someone providing services to the DAO, and saying they do not have enough funding to continue doing so for the ENSV2 plans.

Either the services they provide are good and we want them or they are not and we donā€™t want them.

Can we get a technical breakdown of what Unruggable is doing for the DAO by some third party to perhaps decide if itā€™s worth it. To me it seems it is essential to the ENSv2 plans but I am also not as well versed as others on the technicalities of it.

Assuming it is necessary for the DAO, then we really canā€™t have a situation where a company doing work for the DAO does not have enough funding to operate and we tell them to just wait 6 months to a year for a process that may or may not vote in favour of giving them something.

4 Likes

I proposed this here; Unruggable have expressed opposition to the idea.

We built Unruggable Gateways and have the expertise to operate it. The DAO should demonstrate its commitment to supporting and rewarding key contributions with meaningful governance and development responsibilities. This will ensure talent retention and strengthen ENSā€™s development ecosystem.

The $1.2M cost structure includes $1M for salaries and operational expenses (covering legal, accounting, travel, and other costs) as well as $200,000 for infrastructure costs. This budget is designed to support a team size of 6-8 members.

Interim funding does not resolve any of the core issues that we have presented.


Reliable infrastructure requires dedicated DevOps support, 24/7. Secure funding for top talent is just as critical as funding the infrastructure itself.

Supporting five L2s simultaneously (Arbitrum, Base, Linea, Optimism, and Scroll) presents significant challenges, as each operates differently and is being actively developed in real-time.

This has resulted in several issues we have faced recently, including:

  • Linea recently updated their rollup contract on Sepolia, introducing breaking changes that we were not aware of in advance.
  • Base recently updated to use Fault Proofs. Without advanced warning, users relying on the OPVerifier would not receive valid responses, as state roots are no longer posted to that contract.
  • Optimism recently executed their Granite Network Update in response to a security vulnerability.
  • Lineaā€™s Shomei state manager nodes often lag behind.

.

I agree with this. 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 (here or the service provider program). @nick.ethā€™s suggestion to provide them with $200k now for infrastructure etc would seem to indicate he thinks itā€™s worth having them do this work.

So as of right now, Iā€™d vote to support this funding request as-is.

5 Likes

ENS Labs developed the original version of EVM Gateway. ENS Labs also made significant contributions and design inputs to the enhanced version of the gateway that Unruggable developed. Because of this weā€™re intimately familiar with it and its operation.

We believe Unruggableā€™s budget request to be significantly in excess of whatā€™s required to operate production-level gateways. Given that Unruggable emphasizes that they cannot stand up production quality gateways without this funding, and because of the time sensitivity of ensuring that gateways are operational to prevent delays to v2 development, we propose the following:

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.

Weā€™d continue to be excited to work with Unruggable on improvements to the gateway code, which presumably could continue under the aegis of the streaming program once the issues around hosting production infrastructure are resolved.

Unruggable Gateways is a complete redesign of the EVMGateway codebase. It is architected completely differently. We communicated with Labs during our development process and added generic functionality that allows for supporting the proposed ENS v2 specification. No major direct contributions were made by ENS Labs.

Unruggable has been working on the Gateway codebase at the request of ENS Labs since March 2024. Unruggable has made efforts for months to communicate about the costs associated with running this infrastructure. All requests were refused.

If Unruggable Gateways was part of the ENS v2 budget it was never formally disclosed.

We built Unruggable Gateways. We have been setting up, and testing gateway infrastructure for months. Unruggable are the best team to operate gateways.

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.

I just want to go on record and say that I will likely abstain if this goes to a vote, as I donā€™t feel confident in my ability to appraise Unruggableā€™s work specification. I would feel more comfortable if a third party could assess the funding request before proceeding to a vote.

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. Despite this, I do not support this proposal because I believe it is too large of an ask at the wrong time.

Points I object to:

  • Service Providers: I want to see the service provider program run itā€™s entire course, with an evaluation of all providers, before committing to such a significant expansion to one provider. This seems procedurally correct, preventing an environment where providers front-run one another with large asks. We need to flesh out what the next iteration of this program looks like so we can meet the needs of these service providers moving forward and scaling the program. I want to ensure that the 2-3 providers making meaningful contributions (spoiler alert on my opinion) all have a fair pathway to expansion and growth. Thereā€™s already a discussion on two-year streams here: A Brain Dump on Service Provider Program Season 2.

  • ENS Allocation: Generally donā€™t agree with the rationale. We have been okay with proposals finding a sponsor. A 100k allocation sets a significant precedence. Also, this request is a slippery slope for all providers who submit exectuable proposals to receive a 100k ENS allocation.

Points I support with revision:

  • Infra Costs: If infrastructure costs block important development, I would support a revised proposal to cover these costs. I would also extend this rationale to requests from other providers if the needs were justified.

Reccomendation

I recommend that they put forward a proposal to cover infrastructure costs while waiting for the full cycle of the service provider program before proposing such a significant expansion

1 Like

The release of cross chain reverse resolution is imminent. See:


In the linked thread AvsA specifically notes:

Developers building solutions for core infrastructure should be supported. There is no element of front-running.

We agree with this:

This proposal requests 25,000 tokens allocated annually (vested over 4 years).

This is the cost. Interim funding does not resolve any of the core issues that we have presented. Reliable infrastructure requires dedicated DevOps support, 24/7. Secure funding for salaries is just as critical as funding the infrastructure itself.

1 Like

We ought to consider the financial impact the DAO will face should the request be approvedā€”@avsa emphasized the importance of taking a holistic view of the DAOā€™s finances to calculate an annual spending cap.

ā€”

Of course, the DAO should fund developers which have proven to provide integral improvements to the ENS protocol, but we must also consider the broader picture. We need to ensure the request aligns with the DAOā€™s income limits, which we have yet to confirm.

At the moment, it cannot be objectively determined whether a $1.2 million per annum investment into a third party development team would yield asymmetric returns into the DAOā€™s treasury.

We shouldnā€™t make bets on sentiment alone. We need a technical analysis as well. I believe itā€™s important that we maintain objectivity, and unless there is a comprehensive analysis to assess its viability, risks, and potential returns, I would caution delegates on supporting the proposal as currently is.

We should adopt greater stringency and implement tighter financial controlsā€”honestly, I believe weā€™re falling short in this area as a DAO.

This is not to say that the work Unruggable has done isnā€™t valid (it is); rather, itā€™s a call for us, as a DAO, to take a comprehensive view and produce a reliable budget and financial outlook. This would support the needs of the protocolā€™s development teams while also ensuring its long-term sustainability.

Maybe weā€™re putting the cart before the horse here; perhaps the DAO needs more financial structuring and planning before committing to a request of this nature.

1 Like

While we havenā€™t contributed to the code of v2 - since our agreement with you was that you would take that over - weā€™ve provided significant and ongoing design feedback on the new VM architecture as well as on the wider project.

Iā€™m not sure what this is referring to. You havenā€™t asked us for funding, to my knowledge. We were sent an earlier version of this budget request and offered similar feedback to that which weā€™ve subsequently shared publicly on this forum.

The EVM gateway work was conducted and paid for using a grant from the DAO under the streaming program; as per that program itā€™s licensed using an open-source license. The DAO can make the decision on how to fund hosting instances of those gateways, and which provider should do that, independently of funding the development of them.

1 Like

In our previous discussions with ENS Labs they offered similar feedback, namely that it cost too much. They did not give any further technical explanation why they believe this to be the case.

Suggesting that a grant of $200k and maybe getting funding in the future to operate ā€œa crucial component of the v2 infrastructureā€ is neither reasonable nor in the best interest of the ENS DAO.

We believe that they are aware of the costs of software development and infrastructure operation as well as the need for appropriate incentives. ENS Labs requested a budget of $9,697,500 per year, and has an allocation of 1,250,000 ENS tokens for future contributors:


ENS Labs have not provided a compelling justification for the reason why Unruggable, who built this software, should not operate it. 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.

If the DAO were to have ENS Labs provide this infrastructure it would not be aligned with the stated goals of the Service Provider program.

Dividing responsibilities across specialised teams is generally considered a best practice in software development. ENS Labs historically struggled to operate the eth.link service at a professional standard due to their own bandwidth constraints.

Our focus is on attracting talent to the ENS ecosystem and doing what is best for the ENS protocol.

1 Like

TL;DR

Proposal

Unruggable is requesting direct DAO funding of $1.2M USDC annually plus 100,000 (vested over 4 years - 25,000 per year) ENS tokens. This request is to fund the operation of a network of gateways, using their Unruggable Gateways codebase, to serve as core infrastructure for cross chain reverse resolution (ENSIP-19), and ENSv2.

Commenters on the temp check have called the funding excessive, and suggested using a combination of interim funding ($200k) and seeking further funding later, as well as amending the Service Providers program.

  • Service Provider process and precedent.
    • Against: Funding for alternate teams should be done using the existing Service Providers program.
    • For: There is universal agreement that Unruggable Gateways is core infrastructure for ENSv2. As such it warrants secure, direct, DAO controlled funding. No other Service Providers are currently building core infrastructure.
  • Reasonableness of the ask.
    • Against: The ask is too much.
    • For: The ask has been carefully considered, is aligned with industry standards for modern software development and infrastructure operation, and allows Unruggable to operate infrastructure as an independent team while attracting and retaining high-quality engineers. We believe independent token holdings decentralise governance, while aligning our interests with ENSā€™s success.

Conclusion

Unruggable built Unruggable Gateways (both the verifiers and the gateway server infrastructure) on which ENSv2 critically depends. The funding is in line with industry standards, and allows for setting up an independent development team to support the ENS L2 strategy, which is vital to the success of ENS.

Despite the difference of opinion expressed on this temp check, we have an excellent working relationship with ENS Labs, with open lines of communication and close technical cooperation. We look forward to continuing to work with them on the ENSv2 roadmap !

2 Likes

Thank you for this tl;dr @clowes.eth - definitely helpful having a round up of the comments above regarding pros and cons highlighted above. Looking forward to this moving forward - it will be great to see some milestone reporting added for extra transparency on proof of work as you progress

1 Like