Illuminating the ENS Registry
Summary:
This proposal will involve funding and integrating an indexer for the ENS registry. The integration will provide a substantially more intuitive and efficient search experience for users. Alongside with the integration into the ENS app frontend, we will also provide an open, public API - allowing anyone in the community to query custom data requests about ENS registry state in milliseconds, or build applications on top of our high performance database.
Before going into technical details, we strongly encourage giving our demo a try! We’ve created a demo for our proposed integration of our backend with the current ENS registry frontend, the implementation of which serves to illustrate how the search UX could be substantially improved by our indexer, without hindering the feel and identity of the app.
Try out the demo here:
The initial features we will implement:
- Filtering by availability type
- Multiple suggested results per search
- Relevant data tags for all results (status, past registry price, date)
- Filtering by domain content (letters, numbers)
- Natural language powered suggestions
We propose to implement these features into the ENS app without requiring any (or very minimal) work from ENS engineering talent, as well as maintaining and running the indexer going forward to support the open API. We’ve already laid the groundwork for this implementation as can be seen from the demo, and our infrastructure is ready to handle traffic at scale.
To achieve this implementation, we are asking for $50,000/month on a monthly streaming basis. We are confident in the utility of what we’ve built, which is why we propose the stream being cancellable at any moment by the DAO should its value not be realized. A full cost breakdown is provided below, the majority of which is hosting services, but also includes development, maintenance, bug fixing, and ongoing efficiency improvements.
Based on statistics gathered in December 2023, ENS earns $1.36 million in monthly protocol revenue. Thus, the proposed integration would only need to yield a 3.6% increase in registration volume to pay for itself. Any additional increase would make this integration a net-positive for the protocol.
Details:
Why does ENS need an indexer? Because it is run by a distributed computer instead of a centralized server, thus it is much harder to know what the current state of it is, as well as its history. Our indexer collects data from every new Ethereum block and feeds it into our special purpose database. We have backfilled data to go as far back as the initial ENS (legacy) contracts went live.
In general, we and many others believe that having an indexer for ENS as a public good and an open API would be of great benefit to the protocol. There is a lot that can’t be queried by logs and this is where indexing comes in handy. For example turning namehashes into a name, or querying and aggregating lots of data about activity at once. The extensibility of what we built is quite large, and we have realized that by gatekeeping it as a paid service on a third party front-end, we have been significantly limiting its potential and reach.
Since then, we’ve extended the search capabilities on top of our indexer (the DB that queries the state) to become as intelligent as possible. Most recently, this included building a custom Natural Language model which could recommend “similar” domains to what a user was searching, as well as build a semantic preference profile. We also trained it on all the past ENS data to be able to build a hierarchy of relevance with suggested results. Domains that were previously registered or registered off premium are deemed more “notable”, since they have past transaction history.
All of this we built in the hopes of making the ENS registry discoverable. Our goal: help newcomers find a single domain they love, a handle that excites them to dive into web3 as a user, or a domain that allows them to direct their website via Ethereum.
The grant would allow us to continue maintaining and improving our Indexer as a public good, but ultimately, we would just love to see what we’ve built be integrated with the frontend in some shape or form to be made available to more users! We are wholeheartedly confident in the UX improvement our indexer can bring, and would be happy to let that speak for itself.
Thus, we are willing to structure our grant as a stream and be cancellable by the DAO at any moment if there is no noticeable improvement in app usage, or if the economics of the services and their cost no longer make sense for the protocol.
Costs:
Unfortunately, just keeping the indexer running smoothly alone is quite a cost-intensive operation, due to the sheer amount of data and the desire to serve it rapidly to users all over the globe.
The following is a breakdown of our costs for this proposal. To run our backend, we use a variety of services to aggregate, format, sort and serve data back to users. Our largest cost comes from AWS, where we host most of the data. In the image below you can see a detailed breakdown of a single AWS region deployment and its associated costs:
With this proposal we plan to spin up instances in multiple regions: US East, EU Zurich, and AUS Melbourne. Doing this will greatly reduce latency and response times for requests, improving the user experience for those outside of the US. Some services will need to grow as usage and chain size increases, while others will remain static. Across all three regions, our annual server costs will run up to approximately $220,000.
Additionally, there are other costs associated with this proposal that we have to cover. As a part of this proposal, we will assign multiple developers from the Kodex team to work on implementation of the features from the demo, maintenance, and bug fixing. These members from our team will need to provide consistent oversight and checking to ensure that the technology is functioning flawlessly around the clock. They will also be available to help community members interact with or build on top of the API. Since these developers come from the Kodex team and are not being hired solely for the purpose of this proposal, the following figures are not the full annual salaries of our developers, but rather reflect their time and work commitment solely towards the proposal.
Our engineers are already deeply familiar and well seasoned with the ENS stack, from the front-end of the app to the intricate architecture of all the contracts and the protocol.
The annual development costs associated with this proposal:
- Back end and Database developers(x2): $140,000/yr
- Responsible for: designing, implementing, and improving our database structure, creating APIs, aggregating data from a variety of sources, improving the speed of queries, creating sorting and filtering logic
- Front end and UI developer: $60,000/yr
- Responsible for: creating UI elements that are required for the upgrade, serving results generated from our search engine, ensuring the app feels responsive, implementing the various sorting functionalities created by the back end team
- Systems administrator: $50,000/yr
- Responsible for: managing security of our database, ensuring our tech stack is up to date and running smoothly, improving cost efficiency of servers and services we use
- Project manager: $40,000/yr
- Responsible for: managing day to day tasks of developers, keeping the project on track, ensuring the vision of the proposal is brought to life, handling payments to developers and 3rd party service providers
.
Built into the proposal cost is a service charge of $90,000 for designing, implementing, and maintaining this upgrade.
Cost summary:
-
Server deployment across 3 regions: $220,000
-
Development costs: $290,000
-
Design and maintenance of service: $90,000
Total cost of this proposal: $600,000/year ($50,000/month)
If approved, Kodex Labs agrees to a 3rd party code audit at the discretion of the ENS DAO. Kodex Labs is committed to data privacy and agrees to never store, publish, or sell user data to any third party, ever.