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.
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?
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.
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.
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
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.
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.
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.
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.
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.
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 !
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