We are requesting funding from the ENS DAO to build a production network of gateways. These gateways will support the rollout of reverse resolution for Arbitrum, Base, Linea, Optimism, and Scroll. We also plan to continue our research and development on the ENS protocol and actively contribute to the ENS ecosystem with a focus on resolving names from L2s. Our funding request focuses on infrastructure, talent acquisition and retention, and ongoing development to sustain this critical ENS infrastructure.
Request
We are requesting $1,200,000 USDC annually and 24,000 ENS tokens (vested over 2 years with a one year cliff).
This request gives consideration to the feedback on our Temp Check on the ENS DAO forum.
Executable Code
This proposal constitutes two streams:
A stream of $1,200,000 USDCper year (12 months).
A stream of 24,000 ENS tokens over 2 years (24 months) with a 1 year cliff (12 months).
Both streams are controlled directly by the ENS DAO Wallet. They can be cancelled at any time with a DAO vote should Unruggable not fulfil their promises.
After in depth consideration and discussion, we’ve decided to vote in favour of this proposal. Despite not following perfect procedure (especially considering the upcoming service provider streams discussion), we think the Unruggable team are an incredibly important technical contributor to ENS and should be supported.
I believe the existing streaming system should be prioritized, and that it would make sense to leverage exiting service providers (for both cost savings and managing tremendous DevOPs loads). I have plenty of suggestions for a future proposal. Ask me. :)
Unruggable is ready to graduate out of the Service Provider program and build out their team to support ENS in a larger capacity. They are working on the most important feature - L2 Resolution, and I trust them to execute on that in coordination with ENS Labs, and other partners.
Unruggable is a solid team, but this should be part of the streaming provider program. More detailed rationale here: https://discuss.ens.domains/t/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/19902/70
The ENS protocol is a Public Good. The revenue from the protocol flows to the ENS DAO to be used to maintain the protocol and fund other public goods.
I dislike many things about this vote. While I would prefer this process to have unfolded differently, using the ENS DAO Constitution and Ethereum's Infinite Garden Principle as a guide, I believe that funding Unruggable's initiatives here is in the best interest of both ENS and Ethereum.
https://docs.ens.domains/dao/constitution
https://ethereum.foundation/infinitegarden
I look forward to working with unruggable and funding their work in february, when the Service Provider program is renewed. If this was a smaller ask, or if the renewal of the program wasn't happening so soon, or if they were already been a service provider for longer, I would have voted for the proposal.
I maintain my previous comment that Unruggable is one of the few service providers showing up daily for ENS; it’s clear they’re all in and have been of immense value. Despite this, I have unresolved concerns/questions about the procedures for graduating providers from the service provider program. I would rather see a scalable system for evaluation and graduation before bypassing the service provider program altogether. I also encourage Unruggable to heed the suggestions for interim or gap funding as needed. My previous comment here: https://discuss.ens.domains/t/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/19902/30
Unruggable has a proven track record, with many years of contributions to the ENS ecosystem. They built the Unruggable Gateways and have the skills needed for ongoing maintenance and improvements. The Service Provider program isn’t designed to support teams operating core infrastructure. Unruggable has demonstrated their reliability, and everyone agrees they have excelled so far. They are best positioned to operate the production gateways and maintain the core infrastructure they have built for ENS. Funding them will ensure they can continue this critical work, supporting ENS's L2 strategy.
While we all appreciate Unruggable's contributions to the ecosystem, this EP is premature and an overreach of what the service provider program is here for. For Service Providers to peel off from a generous funding program in order to establish individual streams (that again, are in an amount that the Program can provide for) is redundant from a process perspective. For that reason, I am against this EP.
My full reasoning for this can be found here https://discuss.ens.domains/t/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/19902/82?u=simona_pop
Unruggable did a good job improving the EVM gateways, originally developed by ENS Labs. However, this proposal fails to demonstrate that Unruggable is the best team to manage global infrastructure. After all, the best sports car drivers aren’t typically the engineers who designed them.
This proposal bypasses the service provider programme and is being pushed forward prematurely, despite ongoing discussions and feedback. Such practices are detrimental to the ENS DAO.
I believe there are updates to the Service Provider Program, particularly the extension of funding terms beyond one year, that address Unruggable's core needs. This is in addition to the already gracious terms that are given to service providers. If this proposal fails to go through, I hope to see them apply to be a service provider again in the new year.
We are the best placed team to manage the research into, and deployment of productionised gateways noting that we built the codebase and have the appropriate domain knowledge. We have an incredible, and well documented track record in the ENS ecosystem and our proposal is for streamed funding conditional on us executing our milestones. Thank you for your support !
I have great respect for the content of the proposal, the proposal team and their track record. I also appreciate the recent clarifications and engagement about the proposal in the dicussion forum. It seems that one of the main motivations for this proposal is around limitations of the Service Provider Program and its funding process. Finally, after reading the threads and discussing with others, I feel it would be more beneficial for the ecosystem if the team were to address the limitations of the Service Provider Program in a separate proposal directed specifically at the Service Provider Program. With their deep understanding of the issues, they can help to improve the process of bringing more qualified, trusted service providers onboard to benefit the ENS ecosystem and ensure that ENS maintains its public good orientation as an open and inclusive ecosystem of builders, innovators and experimenters. Private domain naming services (that raise private funding, and have more stable funding horizons) have their own advantages, but also their drawbacks, and part of the discussion we are having reflects the tension that alternative models present. Of course we want to be fast, competitive and efficient, but we are also building intentionally, slowly, with an eye on the long-term as well as on inclusion. I have a lot of respect for the ENS team, the creators of the Service Provider Program and the spirit in which ENS operates, which has gotten us this far. ENS itself is a long-standing collective experiment, and one of the projects we can be most proud of in the Ethereum ecosystem. I unfortunately will vote against this proposal in the hopes the team will resubmit one or more proposals that address the two important take-aways I see from the past day's discussions. First, we need to ensure that qualified teams can be hired to develop important improvements to the system (+ that they feel valued + that they don't go elsewhere). And second, we *also* need to improve the processes through which ENS is run and by which ENS engages service providers going forward. As the Service Provider Program is only in its first year, I am hopeful that folks will continue to step up to improve it. Voting against, but in gratitude.
While I appreciate Unruggable's technical contributions to ENS and CCIP Read gateways — and would support their continued involvement in the service provider program — I don't feel they are the best team to operate this infrastructure.
Unruggable is an amazing team! I am proud to lead them as CEO and know that we will do a great job on gateways to support reverse resolution for Arbitrum, Base, Linea, Optimism, and Scroll. 2025 is going to be a fantastic year for ENS!
Bypasses the stream provider program that funded these ecosystem projects. Did not demonstrate why the streaming provider program doesn't fit their need.
