[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

DAO-Wide Temp Check
1

Proposal Temp Check Changes

December 16th 2024. We have made the following changes to our proposal in response to feedback. Our original proposal follows.

Request

We are requesting $1,200,000 USDC annually and 24,000 ENS tokens (vested over 2 years with a one year cliff).

Based on feedback we have:

  • Added milestones to our proposal
  • Significantly reduced the amount of ENS tokens in our request
  • Added a one year cliff to the vesting of the ENS token allocation.

If this proposal is successful we will withdraw from the Service Providers program, and request our stream be stopped by the Meta-Governance Working Group.

Milestones

We are adding the following milestones for accountability.

Gateways

  1. Recruitment: Hire a DevOps Engineer and a Blockchain Engineer to lead infrastructure deployment, and performance optimisation.
    Timeline: Complete hiring by Q1 2025.

  2. Production Gateway Deployment: Launch scalable, redundant gateways across five chains (Arbitrum, Base, Linea, Optimism, and Scroll) in five globally distributed regions (North America, Europe, Asia-Pacific, Middle East/Africa, South America).
    Timeline: Deployment complete by Q1 2025.

  3. Infrastructure Optimisation: Finalise infrastructure design and demonstrate cost reductions through performance and efficiency optimisations.
    Timeline: Initial optimisation complete by Q2 2025, with ongoing improvements.

  4. L2 Collaboration and Documentation: Collaborate with L2 developers to enhance gateway compatibility and API stability. Publish documentation detailing performance improvements and best practices.
    Timeline: Ongoing, with quarterly reports.

  5. Resiliency Benchmark: Maintain 99.9% uptime (excluding external dependencies) over a monitored evaluation period, with transparent reporting on outages and performance metrics.
    Timeline: Achieve benchmark by Q4 2025.

Unruggable
Unruggable2200Ɨ238 12.2 KB

Summary

We are requesting funding from the ENS DAO to build a production network of gateways to support the rollout of reverse resolution for Arbitrum, Base, Linea, Optimism, and Scroll. These gateways will enable trustless ENS reverse name resolution as outlined in ENSIP-19. Our funding request prioritizes infrastructure, talent acquisition and retention, and ongoing development to sustain this critical ENS infrastructure.

Request

We are requesting $1,200,000 USDC annually and 100,000 ENS tokens.

This funding request covers infrastructure costs ($200,000) and staff salaries and operations ($1,000,000). The goal is to establish a stable funding stream to enable execution, long-term planning, and strategic investments in infrastructure, talent, and innovation.

We propose vesting the ENS tokens over a four-year period, with governance rights granted upon proposal approval.

Detailed Proposal

Of the 16+ million ENS names currently registered, nearly 90% use gateways. With ENSv2 and the rollout of reverse resolution from L2s (ENSIP-19), the number of name resolutions that utilize gateways will greatly increase. We anticipate that over the next few years, 99% of ENS names will be resolved using gateways.

Building on our research into ā€˜ENS Chain,ā€™ we turned our focus to developing Unruggable Gateways, a powerful yet flexible extension of the original evmgateway codebase that allows trustless resolution of data from other blockchains. The first release candidate is currently undergoing an audit supported by the Metagov working group. There are currently live verifier deployments on testnet and operational gateways to support the testing of ENSIP-19.

Unruggable Gateways comprises two core components:

  • Verifier smart contracts

    Deployed on Layer 1, these contracts are the primary focus of the audit scope.

  • Gateways

    HTTP servers that handle client requests for data from supported chains and deliver proofs to the ERC 3668 callback on Layer 1, enabling data resolution.

This funding request supports the continued maintenance and ongoing development of the Unruggable Gateways codebase, as well as the operation of production gateways that can reliably serve responses to client requests at scale. It covers the infrastructure costs and the costs associated with supporting that infrastructure, including increasing the size of the Unruggable team.

Infrastructure

Core Infrastructure

To protect ENSā€™s standing as a trusted blockchain primitive, our gateways must be ready to handle traffic spikes proactively. With infrastructure costs scaling with demand, we cannot rely on reactive measures alone to manage sudden surges. Ensuring redundant, scalable gateways in advance is critical to maintaining reliable service and trust in ENS.

For context, the ethers.js package has over 1,400,000 weekly downloads, while Viem exceeds 500,000 weekly downloads. Both treat ERC-3668 as a first-class citizen, with specific focus on ENS name resolution.

The reverse address, and avatar are resolved on every Uniswap page load for example.
The reverse address, and avatar are resolved on every Uniswap page load for example.1265Ɨ73 11 KB

The reverse address, and avatar are resolved on every Uniswap page load for example.

Name resolution, both forward and reverse, occurs in ecosystem applications during every page load. As we transition to a gateway-centric approach to ENS data resolution, we expect requests to our gateways to grow significantly.

Redundancy and Disaster Recovery

Operating redundant infrastructure is a necessity and there are significant associated costs. Failsafes geolocated around the world are required to to ensure quick response times from any location under any scenario, such as natural disasters. We also need to be able to adapt to inconsistent load patterns by automatically scaling our infrastructure in response to demand.

Monitoring and Security

Continuous monitoring is crucial to identifying and resolving issues before they affect users. Distributed Denial of Service (DDoS) attacks are a common threat to gateways and APIs. Additionally, bad actors, web crawlers, and bots must be properly managed. A proactive approach is essential to mitigating these risks effectively.

Research and Development

We aim to stay ahead of the curve by continuously improving and optimizing our gateways. We intend to dedicate resources to iterating on, and refining our gateway solution in response to actionable data from real world usage.

Unruggable Team

Unruggable currently consists of four team members: Prem, Thomas, Raffy, and Mely.

We are requesting funding directly from the ENS DAO to expand our team and secure predictable, ongoing financial support. Attracting and retaining top talent requires financial stability, as high-caliber engineers and DevOps professionals are unlikely to join or remain with an organization facing financial uncertainty or reliant on annual funding applications.

Our interpretation of the Service Provider program was that it was designed as a proving ground for ecosystem participants to demonstrate their ability to contribute to ENS development with the goal of further decentralizing the protocol. We believe that we have demonstrated our ability to do so. This represents a natural and successful outcome of the Service Provider program and can serve as a model for how DAOs onboard new development teams.

Team Expansion

We plan to add 2-4 team members over the coming year including an expert blockchain engineer and a DevOps engineer. Our compensation aligns with industry standards, aiming to recruit and retain top-tier talent.

Token Allocation Justification

Gateways play a critical role in ENSā€™s future, serving as core infrastructure for ENSv2. Our work on Unruggable Gateways is instrumental in advancing the protocol, and we will continue to contribute significantly.

Our ENS token request reflects our commitment to both development and governance responsibilities. To align incentives, we propose a four-year vesting schedule for the ENS tokens.

This allocation will enable us to submit executable proposals to the ENS DAO, requiring 100,000 tokens. We believe this request is justified based on our ongoing commitment to ENS and the DAOā€™s goals of decentralizing governance. Coupling our USDC funding with vested ENS tokens will further align incentives and demonstrate our long-term commitment to ENS.

Transparency

We will provide quarterly financial statements and technical progress reports, similar to those offered by ENS Labs for their funding requests.

Audits

We are currently undergoing the audit process for Unruggable Gateways across the five outlined ā€œrelease chains,ā€ funded by the ENS DAO Metagov working group. In the future, as we add new chains to support ENSIP-19 reverse resolution, we will request additional audit funding on a case-by-case basis. These costs are not included in this budget request.

Conclusion

Unruggable is dedicated to the success of ENS.

Co-founders premm.eth and clowes.eth have been committed to ENS for years and are well-known within the community and ecosystem.

raffy.eth is a best-in-class engineer with a history of significant contributions to ENS, and mely.eth is a passionate, well-respected advocate for ENS.

We have a proven track record and the technical skills needed to effectively contribute to ENSā€™s continued development.

We are requesting funding to operate a production gateway network to support the rollout of ENSIP-19. While this funding is not currently focused on forward resolution from other blockchains, including Namechain, we anticipate being able to support this functionality using the same gateways in the future.

This proposal aligns with the ENS DAOā€™s interests, as a production gateway network is critical infrastructure for ENS. It represents a concrete step toward decentralizing ENS development, enabling more focused efforts across ecosystem teams, enhancing productivity, and advancing the vision of a scalable, functional, cross-chain ENS protocol.

Contact Information

Prem Makeig (premm.eth) - CEO and Co-founder

  • ENS Forum: premm.eth
  • X/Telegram: @nxt3d

Thomas Clowes (clowes.eth) - CTO and Co-founder

  • ENS Forum: clowes.eth
  • X: @GUA
  • Telegram: @thomasclowes

Thank you for considering our proposal. We are excited about the opportunity to contribute to ENSā€™s future and look forward to your support.

Appendix

Who Are We?

Unruggable is a UK-based limited company with no outside investors. Our company culture prioritizes high performance and the belief that our success is tied directly to the quality of our team members. Moving forward, we aim to attract passionate, talented individuals committed to ENSā€™s overall success. As a performance-oriented, for-profit company, we believe this structure is essential for ENSā€™s continued growth.

What Have We Accomplished Over the Past Year?

This year, we focused on ENSv2 and supporting L2-based development teams:

  • We researched and produced a presentation for ENS Labs at EthGlobal London, exploring potential ā€œENS Chainā€ solutions, including optimistic and ZK-based chains.
  • We conducted follow-up research on ZKVMs to leverage validity proofs, reducing finalization times for pre-existing solutions such as OP Stack chains. This included attending the Frontiers conference in SF and connecting with Mark Tyneway of OP Labs to explore creating a ZK-based OP Stack chain with one-hour fast finality.
  • We built Unruggable Gateways (Gateway Documentation), a flexible and generic solution for proving the state of data on L2s against L1 Ethereum, enabling trustless forward and backward resolution of ENS names from any supported L2.
  • We launched our gateway network with support for Arbitrum, Base, Linea, Optimism, and Scroll.
  • We are actively and consistently engaged across all working groups, regularly contributing to discussions across Metagovernance, Ecosystem, and Public Goods.
  • We are active and consistent participants in DAO governance.
  • We are active and consistent contributors to the ENS discussion forums.
  • mely.eth is an incredibly passionate and active advocate for ENS on social platforms.
  • We supported developers at EthGlobal San Francisco to build on Unruggable Gateways.
  • We supported other ENS Service Providers (e.g., Namespace, NameStone) in launching subname projects on L2s and contributed to the development of Durin, a developer kit for creating L2 name services using ENS.
  • We have spearheaded making ENSIPs an independent process with independent editors. Prem is a founding editor alongside Nick Johnson and Steve Katzman.
  • We have engaged in active research into potential improvements to (and extensions of) the protocol. For example:
    • Direct contributions to ENSIP-19 including proposing a default fallback enabling EOAs to set a primary name on every chain in one transaction.
    • LinkedResolver as an architectural approach to ENS moving forward.
    • Using aliases for ENS name resolution, allowing users to manage records for all their ENS names in a single profile.
    • Utilizing Hashed Bytes Storage in conjunction with our gateway solution for trustlessly reading large data packets stored on chain.
    • Utilizing Hooks, a new resolution method enabling secure onchain data resolution, including zk proofs, solving long-standing challenges in ENS resolution.
    • Prem co-discovered a significant protocol bug in ENSv2, leading to a major protocol update.
  • We have built ENS specific tooling on EthTools.com to make ENS more accessible and to improve the development experience. For example:
  • We have adapted more generic EthTools.com tooling to allow for usage in verification of call data in relation to the ENS Governance process. For example: see here in relation to this proposal.
10 Likes
2

I support this team and proposal :+1:

4 Likes
3

Itā€™s great to see service providers doing useful things that go beyond their stated commitments. It just goes to show that streaming for service providers was a great idea and a long-term investment.

Totally support 1.2kk USDC grants, since the contribution is enormous. ā€œ4 year ā€“ 100k $ENSā€ sounds great too ā€“ the list of major vote holders has remained virtually unchanged for a year and a half, so it would be a good to expand this list for the governance quality.

2 Likes
4

If Agora (@kent_agora) implements its proposal bond mechanism, only 1,000 ENS will be required to submit an executable proposal. In light of this, would you reconsider the amount of ENS you are requesting? Otherwise, would a delegation of ENS suffice?

5

Valid question.

We are of the view that independently held tokens are the only way to truly decentralize governance. For incentive alignment we believe that a token allocation is necessary as it means it is in our interests to champion the success of ENS. Appropriate vesting is intended to demonstrate our commitment over the long term.

1 Like
6

Hey Thomas,

Can you perhaps break down the $1m into salary ranges per year per role (anonymized), including what you would like to hire to expand the team? Similar for the infrastructure costs can you break down what that $200k is for into a bit more detail?

The token ask 100k ENS is ~$2m at current prices. Do you intend to sell the tokens as they vest to further cover expenses/salaries, use them for governance or distribute to team members to ensure long-term alignment with the project? Itā€™s a bit of a high amount, so would need some kind of commitment on how they end up being used. And/or a reduction in amount if the proposal creation threshold is the goal as this may change afaik.

I believe that funding Unruggable to maintain and further develop the gateways for reverse resolution would be in the interests of the ENS DAO and ENS community as a whole.

So at the moment am leaning positive here but would like a bit more info that I requested above.

Also the question of the length of this deal comes in question. For how many years do you seek this funding? How can the DAO pull out and stop it if they are not satisfied with the work?

3 Likes
7

For sure, my view on whether ENS should be distributed or delegated has shifted from time to time, but it seems proper to distribute ENS directly; otherwise, the DAO could potentially ā€˜Darth Vaderā€™ its delegation decision (h/t @nick.eth for the neologism).

However, your rationale for the 100k ENS distribution is based on the current threshold for submitting an executable proposal. If the DAO decides to implement the bond mechanism, the basis for your rationale will no longer apply.

In this case, I would recommend that delegates carefully consider the requested amount in ENS, as the primary purpose of the governance token should be participation in governance (i.e., submitting offchain and onchain proposals).

1 Like
8

Hi Lefteris,

We believe our funding proposal is reasonable and proportionate given the scale of ENS and the level of service we plan to offer through our provision of gateways.

Our salary request supports expanding our team to 6ā€“8 members, with all but mely.eth in high-level technical roles. Infrastructure costs will cover globally redundant systems, provisioned to scale appropriately with demand.

For transparency, we will publish quarterly reports on the ENS DAO forum and contribute to efforts in standardizing disclosure formats.

The USDC portion of funding will be transferred as a perpetual stream controlled by the ENS DAO, while the token allocation will be used for governance. The proposed amount ensures Unruggable holds appropriate governance weight as a core infrastructure provider.

9

In before all other stream recipients start sending funding requests of $1M+ while already on streams. This request is over the top and the amount requested is borderline unreasonable. $1M+ in funding and $2M+ in ENS tokens.

10

I am against this proposal. Not because of the large amount of money (it is) or the amount of ens tokens requested (itā€™s also large) or because I doubt the team work quality (I donā€™t) nor because they havenā€™t proved their worth through service providers (Iā€™ll let the DAO vote on that)

But because I would like to see all such requests coming through the Service Provider stream, and because Iā€™d like to see governance distribution as a unified policy for all the DAO treated equally.

If every team starts submitting their own requests then it will be confusing, they will be under different rules and it will create a race in which everyone will try to put forward their proposals before the others to make sure they get votes before the DAO tires of such proposals.

Iā€™d prefer to adapt the service provider selection rules to allow larger amounts (in the last year the highest ask was 1M and nobody requested that) than having all teams have their own arrangement and request direct to the DAO.

Will be voting against this if it goes live.

4 Likes
11

The Unruggable Gateway codebase is currently going through audit such that it can be utilized for reverse resolution of ENS names. The rollout is imminent and we currently do not have funding to operate gateways. Provision of these services is a neccesity for the successful rollout of ENSIP-19.

12

Unruggable shared a version of this proposal with me privately previously. Iā€™m sharing here part of my response to them:

On funding: From our understanding of the EVM Gateway, developing and operating the EVM Gateway stack should not require $1.5M in annual funding. Your projected infrastructure costs seem very reasonable, but with much of the development work of EVMGateway v2 already completed by Raffy with your current headcount and budget, it seems hard to justify the level of staffing and expenditure youā€™re proposing. Certainly operating fast and reliable gateways will involve some operations expertise, but the expectations in your document seem excessive. The ā€œperpetualā€ nature of the funding ask also places onerous burden on creating an evergreen oversight structure. Given the progress youā€™ve made already, we would have expected that, with this as Unruggableā€™s main focus, the existing streaming funding of $400k would be sufficient for the task.

Weā€™re still excited to work with you on v2 and the EVM Gateway, and appreciate the substantial work youā€™ve put in to ENS already, but we canā€™t support the proposal as it stands.

Since my comment the proposal has been adjusted somewhat, with the ask reduced from $1.5M to $1.2M, but with the addition of 100k ENS tokens. Projected infrastructure costs have increased since my comments above, though depending on the scope of operations - specifically the number of chains Unruggable intends to operate full nodes for in order to ensure minimum latency - may still be quite reasonable. The rest of my comments remain relevant, I believe.

Iā€™m not opposed to streaming providers seeking an increase in their streams in order to expand their offerings, but like @AvsA Iā€™m concerned about the precedent this would set. The streaming program was created to ensure everyone has a fair shot at funding on an equal footing, and so that the DAO can make an unbiased assessment of how to allocate limited funds.

Simultaneously, forcing streaming recipients to wait up to a year for any reconsideration is likely to put a handbrake on expansion and innovation. Iā€™m not sure what the best path forward here is, and Iā€™d welcome input on this.

Iā€™m also not opposed to streaming recipients seeking ENS token grants; while the governance pilot program is good, you canā€™t hire people on a promise of maybe tokens someday; organizations will need to have reasonable certainty in order to hire quality talent and compensate them appropriately.

3 Likes
13

One of the original stated goals for the Service Provider program written by @AvsA was to acknowledge and encourage teams that are building to improtive the ENS system and serve the funding gap between small grants and ENS labs.

Since the establishment of the program, the DAO will have funded 9 teams in the amount of 3.6M this year-- and I personally am happy to see great teams such as Unruggable and others receive deserved funding to further the goal of improving the ENS System, and a lot of great work has been done in the year since.

However, for a service provider to depart from the Service provider program to explicitly seek funding direct from the DAO goes directly against why the Service provider program was even established in the first place. The program was not to encourage evergreen funding ā€œin perpetuityā€ from the DAO from Providers- it was established, as mentioned above, to serve a funding gap need. If the issue is with additional funding, as @AvsA points out, there is room in the Program to service up to $1M per year for qualified Service Providers. (This is of course for the DAO to vote and decide on now that we have ~ year of track record). Asking for $1.2M is not so much of a departure from the limit here where it necessarily calls for a separate DAO funding steam to be created.

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, and to echo @nick.eth , sets a bad precedent that may introduce more governance chaos and is also unfair to other Service providers. There is not, as far as I am aware of, any intention from the DAO to discontinue the Service Provider stream-- so this remains an extremely viable option for provider grants going into the foreseeable future.

If there are reasons why Unruggable felt that the Service Provider stream program is not sufficient to address the teamā€™s needs, Iā€™m sure we are all ears on how to improve the program to ensure that high quality teams that are building to improve ENS can continue to do good work and feel supported from the DAO.

1 Like
14

I would support this

I think the argument, that this request is out of the perimeter of service providers is kinda valid, but itā€™s not like we have 1000 service providers to completely loose track of whatā€™s what

Unruggableā€™s been with ENS since forever, and there is no doubt that theyā€™ve been very useful community members

Development is expensive, this extra capital infusion will give them more ā€œair to breathā€

1 Like
15

Iā€™m actually more comfortable with having Service Providers reapply to the next iteration of the SP program as well, but it seems that Unruggable Labs may be an exceptional case.

Can we objectively confirm that their team are contributing to the development of critical infrastructure? Is this even worth calling into question?

It can definitely get weird.

One could imagine a scenario where several teams follow suit with varying results, potentially creating a perception of favoritism. That said, I do think Unruggable is making fair arguments to support their proposalā€”I just wonder if it might be better served as feedback for the SP program in 2025.

That said, I agree itā€™s better to follow a unified governance distribution policy, as weā€™re about to kick start the pilot.

Could we provide funding in tranches alongside a stream?

For example, if a Service Provider (SP) is guaranteed $1M in funding for 2025, could a percentage be distributed as an initial tranch to cover immediate or essential expenses at the start of their project, with the remainder funneled through a stream?

ā€”

Yeah, trueā€”ā€˜in perpetuityā€™ might be a bit over the top. That said, it does seem cumbersome for teams building critical infrastructure to repeatedly engage the DAO for funding, rather than focusing on shipping instead.

Is there a middle ground here? Could we perhaps discuss introducing another ā€˜tierā€™ to the Service Provider program that better addresses the needs of growing teams contributing to core ENS infrastructure?

16

The Unruggable team is one of the successful outcomes from the service provider stream, making high-value technical contributions and actively participating in governance, discussions, and calls. I have no doubts about the capabilities of providing more value and delivering.

Some questions and food for thoughts:

Service providers ā€œgraduatingā€

The success of the service provider stream is evolving ENS and supporting teams that have quality, alignment, and high impact. How these teams graduate from needing to dedicate some time each year to approve a budget to having a more stable stream directly from the DAO is unclear.

Having all under the service provider stream and rules is good for creating this field of equal opportunities (for example, ENS distribution) rather than different proposals and precedents. However, long-term and stable funding for proven teams is also necessary.

There are other service providers like eth.limo providing core infrastructure and could fall into the same situation. Approving this without discussing a broader approach for how this graduation happens might bring more discussion and hassle.

Without this definition, Iā€™d prefer to see this budget being approved under the next service provider term, which I think is very likely to happen given its outcomes.

L2s free-riding on ENS DAO funding this work

Enabling reverse resolution to all these L2s is something positive for ENS, but even more positive for these L2s, IMO. They should also be paying for this infrastructureā€™s development, support, and maintenance.
This is the ideal scenario, but this requires a lot of business development, itā€™s probably worth directing effort to shipping and make them see the value. It would help to have some commitment that if any funding from L2s for the scope under this proposal is received, this funding is redirected to the DAO. Since the DAO would be subsidizing this development.

Costs

Letā€™s say the team expands to 3 more devs, each one in a different timezone to have 24h coverage on the system. Now letā€™s use max developer salary from CryptoJobList ($150k). Current team (4) + 3 = 7. 7 * 150k = 1.05M. And there are the infrastructure costs. So itā€™s fair to say that for a high-quality team of that size, the USDC value is aligned. With ENS making part of the compensation package (25k/year, around 3k ENS per person anually), the USD value should be lower.

Iā€™m a technical person, but I donā€™t have as much context to clearly understand how big the team should be. But looking at the scenario where the EVMGateway v2 is already mature enough in a point that is being audited, doubling the team looks excessive. Adding one Senior DevOps to the team looks like a must.

ENS allocation

I think itā€™s great to have aligned actors having interest in vested ENS for capturing the economic upside of what they are helping to build and also to be incentivized to act in the long term. My only concerns are around the proportion proposed.

Service provider ENS distribution:
72k ENS
3.6m USD
2 years vesting
Ratio = 72k/3.6m = 0.02 ENS/USD

Governance pilot distribution:
30k ENS
1.3m USD
3 years vesting
Ratio = 30k/1.3m = 0.023 ENS/USD

Unruggable proposal:
One-time 100k ENS grant (4 years vesting)
Open-ended $1.2m stream / year
There is no ratio since we donā€™t know the total amount of USD. One alternative could be having a stream of ENS.

Reduce scope

An alternative is to initially reduce infrastructure and team costs by covering fewer L2s, maybe only those already investing in adopting ENS (Base and Linea). And then after expanding to other L2s as there is more interest in reverse resolution and gateways for other networks.

These are my 2 cents. Just giving ballpark numbers and thoughts to discuss. The Unruggable team certainly thought a lot about the proposal and why this team expansion and numbers are needed.

2 Likes
17

Iā€™d be supportive of putting through an interim proposal to fund Unruggableā€™s infrastructure costs for deploying the gateways until the next service provider program can begin. $200k is a yearā€™s infrastructure funding, and getting this to them would presumably remove any blockers, provide an ample buffer in case of any delays to the next service provider round, and could be factored into the next roundā€™s ask.

@clowes.eth @Premm.eth thoughts?

I think that we should at least have a second term of the service provider program before we talk about ā€œgraduatingā€ from it. How can we know if the scheme is viable for long-term funding if we donā€™t try it first?

Agreed - and Iā€™ve no objection to Unruggable or others accepting funding from L2s to provide support (or improved support) for that L2. I agree that it makes sense for there to be provisions against ā€˜double dippingā€™ on funding for any one chain.

18

We are grateful for the existence of the Service Provider program. It is what has allowed us to found Unruggable and on a personal level it has allowed me to leave my previous role and commit to ENS full time.

That said, we believe that funding for the provision of gateway infrastructure for the rollout of ENSIP-19 requires a different approach. We view Unruggable ā€œgraduatingā€ from the ENS Service Provider program as a positive outcome that actually underscores the programā€™s success. It demonstrates that the program directly incubated and onboarded a core infrastructure provider for ENS.

We believe it should not be necessary to complete two full years in the Service Provider program to request direct funding for core infrastructure. Stopgap funding does not provide the stability needed to strengthen our team to effectively carry out the critical work required to develop the gateway infrastructure for ENSIP-19 reverse resolution and to prepare for forward resolution of data from Namechain.

We also believe that our many years of contributions to the ENS ecosystem, the most recent of which are outlined in the appendix of our proposal, are testament to our commitment to ENS and demonstrate why Unruggable should receive long-term funding.

Gateways are at the heart of the v2 architecture, and maintaining them requires continuous funding. This is particularly urgent as ENSIP-19, enabling cross-chain primary names, is set to roll out as soon as our audit is completed. We are seeking ongoing funding to ensure this critical infrastructure is supported.

This proposal also requests a token allocation of 100,000 ENS tokens to support participation in ENS governance and align incentives within our team. To ensure a long-term commitment to ENS, we propose the tokens are vested over four years, with 25,000 tokens allocated annually.

The maths actually aligns exactly in this regard in that 25,000 / 1,200,000 gives the same ratio of 0.02.

Our proposal has been submitted based on its merit, and based on its necessity in the context of the v2 roadmap. From our perspective, a small amount of governance overhead to appropriately fund core infrastructure provided by a team with a proven track record is reasonable. We do not see this as unfair to other Service Providers but rather as necessary for the continued success of ENS.

We agree that L2s should be funding the provision of these services, and we are happy to decrease our reliance on DAO funding if they do so. Direct funding from the ENS DAO also serves to establish our role as core infrastructure providers, making it clear to L2 teams that we are the entity with whom they should collaborate on this work.

We believe the Service Provider program is working as intended and support its continuation. However, we continue to stand behind our direct funding request to the ENS DAO, using the established process outlines in DAO governance documentation, including submitting a temperature check to determine if there is sufficient support for our proposal.

It is necessary that we transition away from the Service Provider program as a means of funding core infrastructure. Alternative proposals leave one or more critical issues unaddressed:

  1. Infrastructure provision cannot be provisional on a complex and arduous yearly process.
  2. Reliable funding is necessary to build a stable team and attract top talent.
  3. Our request for 100,000 ENS tokens (vested over four years, 25,000 per year) to ensure governance proportional to our responsibilities and long-term alignment.
1 Like
19

For transparency, since Namespace is mentioned here, our implementation for L2 subnames currently doesnā€™t use Unruggable Gateways. However, we did collaborate and support the Unruggable team on this and since these gateways are as close to trustless resolution as we can get, itā€™s on the roadmap for us to implement them in the future!

ā€“

I think the question is whoā€™s running the gateways. If the Unruggable team is running them, and incurring the cost for that and needs $200k, I would sign off on this right away. This means that the Unruggable team has built something that is a core infra piece used by the protocol and broader ecosystem and requires more funding to actually be operational. So I understand $200k ask.

I would also like to have answers for the 3 points below which I think will simultaneously push this proposal forward.

  1. More detailed cost-structure breakdown for $1.2M
  2. Milestones and deliverables
  3. Technical roadmap (I thought Gateways were finished and being audited?)

Also, something that could move this forward is if we already had teams, products, companies that have either integrated or in some form committed to integrating these gateways into their products (if applicable).

ā€“

Right now itā€™s not clear how to handle exceptions like this, and teams like Unruggable and maybe eth.limo. This is the reason why I believe we should work and iterate on the current Service Provider Program and make it fit everyoneā€™s needs. Iā€™m not against having a (graduated) service provider program that allows for more funding options. Having something like this would give a clear path for those who want to stay committed to building on ENS for a long time. This I think should be a separate discussion which I think @AvsA is most qualified to initiate and Iā€™m sure we are all happy to contribute.

ā€“

And one more thing, 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. And their work reflects that.

1 Like
20

Thatā€™s not what Iā€™m saying; Iā€™m saying that the service provider program should be at least two years old before we conclude that ā€œgraduationā€ is a required mechanic, given that most of the reasons offered for any kind of ā€œgraduationā€ relate to concerns about the stability of funding in the service provider program - something that hasnā€™t been established to be an actual problem yet, since weā€™ve only had one season so far.

On the contrary, many complex systems are built based on contracts that can be cancelled or renewed. 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. In any case it is a false dichotomy to suggest that the only options are a yearly-renewed stream or an indefinite approval.

At this point I still believe the best option is for the DAO to approve interim funding to cover infrastructure expenses, while renewing the streaming program for another year as early as possible - in which context I would strongly support a grant request from Unruggable.

2 Likes