[EP 5.22] ENSv2 Development Funding Request

DAO-Wide Active Proposal
1
Status Executed
Publishing Date October 31, 2024
Voting Link Link to Tally
Author katherine.eth

[TEMP CHECK] [EP 5.22] ENSv2 Development Funding Request

Abstract

With over 3 million .eth names and 20 million more ENS names registered by the likes of Coinbase, Uniswap, and Linea – ENS has become the standard for web3 identity. As Ethereum’s roadmap evolves towards being rollup-centric, it’s essential for ENS to adapt in parallel, ensuring it meets the needs of both the Ethereum ecosystem and its users. To continue scaling and evolving ENS, ENS Labs is requesting an increase in its annual budget from $4.2M USDC to $9.7M USDC, and a one-time grant for future security audits of ENSv2.

This funding will allow us to develop, maintain and audit ENSv2: a major upgrade that will enhance decentralization, flexibility, and scalability by leveraging Layer 2 solutions and redesigning the ENS protocol from the ground up. We are eager to lead ENS into this next phase and invite the community to support this ambitious vision.

This proposal is an addendum to the previously approved budget stream in EP2.1.

Justification

Since its launch in 2017, ENS has been massively successful as a self-sovereign naming system for distributed systems, primarily linking Ethereum addresses to human-readable names and the broader DNS. Over the years, ENS has evolved through protocol upgrades, improvements, and integrations with other protocols and applications. As a result, it has emerged as the standard in web3 identity.

Today, ENS has enabled over 3 million registered .eth names, and over another 20 million ENS names from teams such as Coinbase, Uniswap, and Linea. There are over 750 apps in the crypto ecosystem that have integrated with ENS, including crypto wallets, decentralized social protocols, DeFi protocols, browsers, and much more. All top-level domains that support DNSSEC can be imported into ENS, meaning ENS is interoperable with existing internet infrastructure. True to its mission to bridge the web2 and web3 gap, ENS has also secured significant partnerships with GoDaddy, Bitwise, PayPal/Venmo, the International Rescue Committee (IRC) and other impactful partners in recent years (with more coming!).

Scaling and improving the ENS protocol has been the core focus of ENS Labs’ efforts over the past 7 years. These efforts include multi-chain support, CCIP Read (ERC-3668), which allowed for offchain lookups of data (including Layer 2s), and include the Name Wrapper, which greatly expanded subdomain capabilities for users.

Over the past 10 years, Ethereum has undergone significant growth and embraced a rollup-centric roadmap. A major development in the Ethereum ecosystem is the rise of Layer 2 (L2) solutions, increasing expectations that user activity will migrate from mainnet Ethereum (L1) to secondary networks. When ENS launched, the Ethereum infrastructure landscape was simpler, albeit less mature. As one of the first protocols built on Ethereum, ENS has had to evolve its approach in tandem with Ethereum’s growth.

To summarize the ENS Labs Development Proposal that was put forth to the forum in May of 2024, the current ENS system faces several challenges:

  • High Gas Fees: Registering and renewing .eth names can be prohibitively expensive due to high gas costs.
  • Scalability Limitations: The increasing adoption of Ethereum and ENS has strained the network’s capacity, leading to Ethereum adopting a rollup-centric roadmap.
  • Limited Flexibility: While the Name Wrapper introduced many improvements in the ownership model, it came at the cost of additional overhead and friction. This functionality could be incorporated directly into ENSv2.

ENSv2 as a Solution

To address these challenges and keep pace with Ethereum’s evolution, ENSv2 proposes:

  • Extension to L2: Users will benefit from the reduced transaction fees that comes from hosting their names on an L2, while still being able to choose to retain the security and availability guarantees of hosting their name on L1 if desired.
  • Architectural Redesign: Implementing a new hierarchical registry system for greater flexibility and utility.
  • Enhanced Decentralization: Preserving user sovereignty and strengthening decentralization principles.

Over the course of the past several months, ENS Labs has been conducting research and diligence into the best technical direction that will suit the needs of ENSv2. We are committed to bringing forth a proposal outlining concrete details for ENSv2, and are excited to start development in earnest, as this will be our largest and most impactful upgrade yet!

We are passionate about the next era of ENS, and this proposal will allow the team at ENS labs the resources they require to ship and maintain ENSv2. We look forward to any questions or feedback from the community, and hope you can all share this new vision with us.

Development Plan

The below development plan summary outlines four phases of progress with estimated timelines and key activities for the development of ENSv2.

  1. Phase 1: Research and Design
  2. Phase 2: Development
  3. Phase 3: Testing and Auditing
  4. Phase 4: Deployment and Migration

**[1] ENS is a live service, so not only is ENS v2 launching a new chain, but also conducting a live migration of existing names. Please note that all dates are estimates and subject to change based on project progress and unforeseen challenges.

Phase 1: Research and Design [In Progress, Estimated completion: EOY 2024]

In Phase 1, we maintain hyperfocus on the research and design of the major technical changes in ENSv2 and ensuring they are complementary to the long term goals of the protocol. The first part of Phase 1 is creation of the Proof of Concept for the updated version of the ENS protocol, as outlined in the technical design document. The second phase is the research around the different L2 solutions available on the market, evaluating which technology stack, team, and ecosystem best suits the needs of the ENS protocol. Then finally, we will work with the selected technical partner to create a long term plan to ensure the success of the selected solution.

  • Finalize ENSv2 Technical Specifications:
    • Solidify the architecture of the protocol and create Proof of Concept contracts.
  • L2 Strategy:
    • Finalize the research and business requirements ENS has for an L2 stack.
    • Determine the technical direction for L2 selection.
    • Represent the interests of the ENS protocol, as well as the DAO when interacting with L2 stack providers.

Phase 2: Development [Estimated: Throughout 2025]

Phase 2 is dedicated to developing the solution identified in Phase 1 while allowing the team time to test and iterate. It’s crucial to refine the initial design to ensure backward compatibility while delivering the future functionality we envision. The complexities around backwards compatibility, a new suite of ENS contracts, and their fit in the L2 context represent the majority of the complexity in this stage.

  • Building Core Components:
    • Contracts:
      • Develop Hierarchical Registry
      • Implement new Universal Resolver
      • Develop contracts for cross-layer communication and bridging
      • Implement contracts for migration from v1 to v2
      • Create other essential contracts
  • L2 Integration:
    • Develop and deploy onto the selected L2 solution
  • Ongoing Testing:
    • Conduct continuous testing and iteration throughout the development process

Phase 3: Testing and Auditing [Estimated: Q4 2025-Q1 2026]

In Phase 3, we will focus on testing from both functional and security perspectives. To accomplish this, testnet contracts will be available to users, developers, and external auditors. Additionally, we plan to research community competition platforms to identify vulnerabilities in ENSv2.

  • Rigorous Internal Testing:
    • Deploy and test ENSv2 contracts on testnet
    • Conduct extensive internal testing
  • Security Audits:
    • Engage multiple external parties (firms and community platforms) for thorough security audits
    • Address and resolve any identified issues

**Phases 2 and 3 may overlap, with internal development (Phase 2) continuing as external testing and auditing (Phase 3) begin.

Phase 4: Deployment and Migration [Estimated: Q1 2026]

In Phase 4, we’ll deploy the fully audited ENSv2 contracts. While there will be a specific date for activating ENSv2, users can opt-in at any time or choose for their names to remain on mainnet Ethereum.

  • Mainnet and L2 Deployment:
    • Deploy ENSv2 to production
  • Monitoring and Support:
    • Continuously monitor the system post-deployment for any issues
    • Provide ongoing support and quick response to any emerging concerns
  • User Migration:
    • Enable user support so they can transition at their convenience
    • Provide tools and guidance to assist users in migrating their names to ENSv2

Budget and Funding Request

Total estimated costs for ENSv2 Development based on the projected costs detailed below:

  • $5.5 million USDC increase in annual stream;
  • plus a one-time reimbursement associated with Security Auditing, requested at a later date.

This would bring the annual operating budget for ENS Labs from approximately 4,197,500 USDC to 9,697,500 USDC to develop, deploy and maintain ENSv2. This budget is used in the following ways:

Development Resources

  • Team Expansion: ENS Labs is currently made up of 20 full-time contributors. Hiring additional developers and engineers specialized in L2 solutions and smart contract development dedicated to the ENSv2 initiative is necessary in order to execute ENSv2, and that will be the majority of the additional headcount being requested. Over the next 12-24 months, we are targeting an additional ~10-15 full-time contributors to the ENS Labs team.
    • Estimated Annual Cost: $2-3M

Infrastructure and Deployment

  • Layer 2 Infrastructure: Configuration and maintenance of necessary infrastructure with third party companies for development and testing (Orcales, Block Explorers, RaaS Providers, Network Security, and other service providers).
    • Estimated Annual Cost: $2.5M-3M

Security Audits

  • Audits: Engaging at least 2-3 reputable firms for thorough code audits.
    • Estimated One-time Cost: $500K-$1M, to be requested at a future date.

Asks and Next Steps

Feedback from this temp check will inform the executable proposal to the ENS DAO, which will vote on the increase of ENS Labs’ annual budget stream commencing from January 1st, 2025. This will be accomplished by approving a new dedicated token streaming contract to spend USDC on behalf of the DAO, and simultaneously revoking the current one at 0xB1377e4f32e6746444970823D5506F98f5A04201.

ENSv2 represents a significant advancement for the Ethereum Name Service, and with the support of the ENS DAO, we can realize this vision together. The ENS Labs team is incredibly excited to usher in a new age of UX improvements and flexibility for the future of onchain identity, and we welcome any questions or feedback on this proposal that you may have.

17 Likes
3

Expanding to L2 is required to scale ENS.

ENS Labs has demonstrated that resources allocated to them produce results.

  • Premier integrations
  • 20 million offchain
  • 2 million onchain

At this point top tier projects are asking how to work with ENS instead of why. It is self-evident.

ENS has a treasury of $100m+ and annualized revenue of $30m. With that context, the $5m/year incremental ask is relatively modest.

Launching an L2 is expensive. As more projects enter the space, service providers supporting L2s are able to charge a premium. Due to confidentiality in many agreements, the exact costs are often undisclosed. However, one reference points to a reported cost of $5-10 million.

ENS is different from other projects. Most projects can exist in isolation on the L2 they create. ENS works best when it works everywhere, including with legacy systems. That complexity is easy to mention but should not be underestimated.

This is a massive undertaking but I have full confidence in ENS Labs to deliver.

I support this ask.

9 Likes
4

This is well said. ENS is not a forgone conclusion as the global identity standard and it must adapt to stay relevant. Expanding to an L2 is a promising adaptation path.

ENS Labs is the best team to execute on this mission. I believe they have the premier talent to lead the change and the knowledge to know what areas to hire for.

Because ENS is already live, it faces a tough challenge of ‘changing the engine on a moving plane’. Migration of existing names makes launching a new chain more difficult, requiring more resources. The ask presented appears well researched and reasonable.

I fully support this increase in funding.

6 Likes
5

I of course support the ENSv2 goals, and increased funding to achieve them is warranted.

I think quarterly financial statements and progress reports should be a requirement for ENS Labs to receive this. Everyone needs accountability, and providing accountability for the funding we provide is one of the primary purposes of the DAO.

I’d also like to note that by requesting more money, Labs is signing up to produce a proportionate increase in output, measured also in speed and quality.

7 Likes
6

Thanks for putting this together @katherine.eth, very well-written proposal.

There has never been a shred of doubt when it comes to technical execution from ENS Labs and I know they’ll deliver this time too.

As someone who has been building tools and apps that extend ENS functionality to other L2s, I can attest to the importance of embracing the L2-centric roadmap.

I’m fully aligned with this mission and will vote in favour of this proposal.

2 Likes
7

In support of this and the phases laid out.

As @katherine.eth noted, “[1] ENS is a live service, so not only is ENS v2 launching a new chain, but also conducting a live migration of existing names. Please note that all dates are estimates and subject to change based on project progress and unforeseen challenges.” - this coupled with the commitment to security of ENS development, the timelines and requested funding is aligned to a robust output.

Agree with the comments around updates on progress for full transparency and real time pulse checks on phases and their rollout.

2 Likes
8

Supporting this!

Will it be a good idea that if approved, ENS Labs presents periodically updates (regarding budget) either at MetaGov or Ecosystem calls? Since we are requesting this from almost everyone who request money from the DAO, I think it would be a good example to follow also from Labs team. Or maybe just a simple forum post.

3 Likes
9

Definitely aligned on doing more consistent progress reports on both technical milestones + operations from Labs going forward, @vegayp @brantlymillegan – in the forum or on WG calls (or probably both!). Thanks for the feedback, and it’s certainly a good idea. Assuming we end up passing the EP for this, we will aim for v1 of the progress report to be posted by the end of Q1 2025. :saluting_face:

2 Likes
10

Great! So to be clear: I support the funding, as long as a requirement for quarterly financial updates and progress reports is put into the proposal.

1 Like
11

I think that for 9M+ this is very very reasonable.

Also:

I am in full support of this proposal, and want to ensure we, as a DAO, are working hand in hand to ensure ENS Labs (and other service providers) is profitable and can scale.

If the ask even has to increase to ensure the continued coordination with the DAO is smooth, and well executed, I would completely understand.

ENS Labs is audaciously generous with the DAO and puts A LOT of effort to coordinate with us. We do not acknowledge that enough!

Comparing how our L2 deployment is being done and how much of the value that ENS Labs creates goes to the DAO vs the way Uniswap’s team and DAO work together and launched their L2 together really makes it clear how lucky we are to have such an amazing DAO <> Labs relationship.

We of course have a job to do! We are here to keep Labs accountable, give feedback and advise, we shouldn’t get lazy and write blank checks…

But honestly, we do have real competitors, and it is the right moment to literally double down and resolve L2 resolution!

5 Likes
12

This proposal and ENSv2 development unlocks significant opportunities for ENS adoption; allowing ENS to not be limited by mainnet fees and create a wider ENS ecosystem makes it a fully worthwhile proposal.

The serious increase in budget isn’t to be understated and ensuring ENS labs is purposeful about reporting (both financial and technical) as discussed above is very important, +1 to all comments from @brantlymillegan @vegayp @katherine.eth

Overall this is a large step for the DAO as we look towards ENSv2 and growth of ENS labs, something that FireEyes supports and is excited to support!

3 Likes
13

Thank you for the detailed report Katherine. This seems to effectively double the operating budget and is quite a big ask.

But the goal is also quite big and ambitious and something I fully support. Having just extended a name in L1 too … damn those fees.

Of-course just throwing money at a problem does not actually solve it. For that, as others said what I would like to see is quarterly reports and transparency so that the DAO can see how the funds are used and request for adjustments if needed.

Other than that also in support.

4 Likes
14

Although not a perfect comparison, I thought it might be useful for the DAO to have some comparative context on this budget as a rough yardstick. Objectively the budget of $9.7M for a new protocol version of this scale is reasonable, comparative to other large new protocol version deployments.

For example, Lido budget for v2 development was ~ $24.7M and Aave Labs development of Aave v4 was ~$12M.

For further context, maintenance type budgets are obviously much lower than new protocol versions. E.g. BGD Labs budget for continual development and security of Aave Protocol over 6 months was ~ $3M and Nomev Labs maintenance work on CoW Protocol was ~ $3.85M. On the lower end, we have RocketPool development maintenance at ~ $500k+.

3 Likes
15

I want to add to this.

  1. …The entire budget doesn’t have to be spent either.
  2. …Why would this not be included in the same request as the normal budget request?
16

(post deleted by author) double post

3 Likes
17

I support the goal of advancing ENSv2, thanks for putting this together, Katherine. I’m excited to see what this can unlock, the opportunities and upsides are huge!

I’m also strongly in favor of a quarterly report being specified in the proposal. This will give more visibility to the community that is building around and alongside ENS.

I mentioned this in the last ecosystem call, and it is also worth mentioning here. In the service provider nomination, we had Etherscan asking publically for $1m/year, which brings me concerns about what proposals and values will be negotiated. I understand that not all negotiations can be public for various reasons. But I wonder what part of the stack is needed to run an L2 can we do a public RFP that can bring more competitive prices and quality.

Any part of the stack will benefit from having ENS as a customer, being such an important piece of the Ethereum ecosystem.

During yesterday’s metagov call, Katherine mentioned that this would go directly to an executable proposal without having a snapshot social vote.

For such an important proposal and with suggestions like the quarterly report not being explicitly added to the proposal, I’d like to make sure we follow the usual process defined in the governance documentation.

1 Like
18

I’m not sure the proposal is the right place to put that - the DAO can’t vote to require someone else to do something. I’m happy to publish such a commitment on behalf of Labs’ independently, though.

Social votes haven’t been required prior to executable votes since the very early days of the DAO; we ditched them based on the observation that with most proposals passing, requiring delegates to vote twice on everything wastes a lot of valuable delegate time, in order to save a relatively small quantity of gas money.

4 Likes
19

That would be great, since there are a good number of delegates who are suggesting it. Do you think we can have this before the EP gets submitted or before the voting ends?

That makes total sense, even more when there is a clear approval signal in the forum. I was just trying to stick to the rules that are currently written. I suggest we update the governance documentation to mention this option explicitly.

I appreciate the efforts and looking forward to seeing ENS evolve.

20

@alextnetto.eth - You’re correct that those governance docs describe the process of all executables first going through the social vote process.

Yes, 100% we should update those. As @nick.eth described, over time the DAO has adopted a different criteria without ever formally changing the docs. Thanks for bringing it up.

I’ll begin a draft for a revision of that section and share it on the forum for feedback.

3 Likes
21

Which docs are you referring to? These ones don’t specify a social vote first.

1 Like