Term 3 Grants - Summary

This thread is an ongoing summary of grants by Ecosystem Working Group for the third term.

This is not the place to request grants. To request a grant please reach out to @slobo.eth on the forum or on twitter.

Discussion of project occur on the weekly ecosystem calls.

Most grants are giving retroactively for proof of work.

Receiving a grant does no preclude a project from participating in the monthly small grants.

To review prior term grants checkout the following thread: Term 2 - Grant Summary


What is ETH.LIMO?

Simply put eth.limo is an ENS gateway with a strong focus on user privacy and security that enables users to access Ethereum-native dApps and content.

Project Updates

User Growth:

Last year we saw a massive increase in dWebsite growth and adoption with ENS dWebsites growing 116% between 2021 and 2022. Currently eth.limo serves over 17k unique ENS domains and receives on average 1-1.5m requests per day. During the bull market there were days with 4.5m+ requests.

These dWebsites can be blogs, resumes, dApps and more.

One of the more unique cases was Devcon 6’s treasure hunt where the team deployed clues to Swarm and IPFS registering the hashes in ENS with participants being recommended to use eth.limo.

Larger Project Adoption:

We’re also starting to see larger projects utilizing dWebsites.

One example is kwenta.eth which is a futures exchange with $372m volume to date and one of the most accessed dWebsites with an average of 800k+ requests per day.

Synthetix also recently announced they’re phasing out the Synthetix staking dapp and migrating to staking.synthetix.eth.

These are just a handful of examples as there are many more projects exclusively using .eth dWebsites. Along with this increased growth comes increased support. The eth.limo team is in contact with many projects offering technical assistance and guidance.

Support for Emoji and Unicode Domains


Storage Protocol Support

The ENS community had been requesting this for a long time and we’re happy to announce the eth.limo gateway now supports resolving these domains!

Support for Swarm and Arweave Contenthashes

The eth.limo gateway now supports every ENS compatible storage layer! IPFS, IPNS, Skynet, Arweave and Swarm.


We have released a local ENS gateway that supports all of the primary features of eth.limo. Users can additionally benefit from OS wide ENS resolution, not just in the browser. Chauffeur is designed for Linux and allows users to access ENS dWebsites in a fully decentralized manner. More information can be found here: GitHub - ethlimo/chauffeur: Local infrastructure stack for resolving ENS domains

Base32 and Base36 Encoding for IPFS/IPNS

We have updated both the eth.limo gateway and our DNS over HTTPS service to explicitly use Base32 encoding for IPFS CIDs and Base36 for IPNS peer IDs.

HTTP Object Caching

Improving content retrieval times is always a priority for the eth.limo team. After several weeks of careful testing we have fully implemented static content object caching, globally for all eth.limo resolved names. This means that we will cache content retrieved from IPFS and save it for later retrieval. The result being much faster page load times for all static content.

Future Roadmap and Initiatives


Caching is a big component of the eth.limo architecture and we are always looking for ways to improve it. In its current form, our caching layer will store ENS domain & contenthash pair mappings with a 15m TTL. This is obviously less than desirable as newly deployed content will not be visible to users immediately. In order to alleviate this limitation, we have been working on a “hotcache” solution that will dynamically update our ENS mapping cache in real-time as records are updated on-chain. Initial support will be limited to names using the ENS public resolver. Record updates will be synchronised as they happen, making updated content available in a timely fashion.

Reverse Lookups

Ever wondered if a particular IPFS CID is associated with an ENS name? Immediately following deployment of the Hotcache, we will begin working on a reverse lookup API for ENS domains. This means that you can search for ENS names based on the IPFS CID or contenthash.

Research on HTTP Header Standards for ENS dWebsites

HTTP headers are tricky to get right, even more so in decentralised environments. Certain browser features (like SharedArrayBuffer) can only be used in a “Same-Origin” context, which requires the use of certain server side headers to be returned to the client. With this in mind, we are investigating the best way for users to define their own header and value pairs at the ENS record level. This would be a new standard for ENS HTTP gateways and permit users to fully leverage all available browser features irrespective of how the content is accessed (i.e. gateway or web3 native browsers).

dAppNode Package

We plan to release a dAppNode package that will allow users to run a local instance of the eth.limo service at home. Similar to Chauffeur, a dAppNode deployment has the added benefit of serving all clients on a local network.

URL Fallback Support

We want users to have flexibility with how eth.limo chooses to resolve content. A feature request that we often see is performing a redirect to the value of the com.url record. In the future, eth.limo resolution will eventually look like this:

  • Does contenthash record exist?
    • Yes
      • Serve content
    • No
      • Does the com.url record exist?
        • Yes
          • Redirect
        • No
          • Nimi fallback

Ecosystem Partnerships

We’ve been diligently meeting and collaborating with other ecosystem projects on delivering enhancements for new user onboarding. We believe that tighter integrations and collaboration between ENS ecosystem projects is vital to the success of the protocol and strengthens the reputation of the ENS community. More details will be announced very soon.

Previous Updates
General Documentation
Gateway Basics
DoH Resolver
Using eth.limo with IPFS (Kubo)

Steward Commentary

Without a doubt eth.limo is foundational infrastructure that adds immense value to the ENS ecosystem. Dozens of builders have built on top of eth.limo, creating a virtuous cycle of added utility that could not happen without the tireless work of the eth.limo team.

It is easy to forget that behind the technology there are real people working every day to make sure the service runs smoothly and consistently. The eth.limo team is on-call. All. The. Time. 365/24/7. To date the majority of the work has been done by just two people.

Furthermore, the cost of their infrastructure is not cheap. They run their own nodes. They handle sporadic DDoS attacks, which spike costs due to autoscaling. eth.limo does this free of charge, unfortunately web2 infrastructure providers like to be paid.

Roughly $100k/year is needed to keep eth.limo running. The cost to run web3 infrastructure is generally more than web2. In part this is because the web3 / decentralized works differently. For example, if a user is storing a large video on IPFS, eth.limo has to serve that through the gateway instead of offloading that to Akamai or Cloudflare. There are dozens of other ways that running decentralized infrastructure is more expensive than traditional tech, this is expected.

The DAO approved EP3.1.1 funding request had 85,000 USDC & 10 ETH allocated to eth.limo. Though this is a material amount of funding. This is insufficient given the value eth.limo provides, combined with their costs.

Over the next few months a proposal will be put forth directly to the DAO to fund eth.limo in a more substantial manner. Stay tuned.

The stewards appreciate the eth.limo team and all the work they have done. Thank you for your dedication.


1W3 - Build Web3Sites for your ENS domain on the Decentralised Web

What we are building?

1W3 is a No-code Web3site builder which helps users to create beautiful Web3Sites for their ENS domain on the Decentralised Web.1W3 lets anyone build professional-grade web3sites, seamlessly link them to ENS domains, and easily upload them to decentralized storage platforms such as IPFS or Arweave, guaranteeing the safety, security, and accessibility of their content from anywhere in the world.


Why it matters to ENS?

Creating a decentralized website for an ENS domain can be a complex process, requiring extensive research and technical understanding of concepts such as IPFS, CID, and ENS Content Hash. This can be especially challenging for non-technical users. Because of the above challenges very fewer users build websites for their ENS domains.
To address this challenge, we have developed a product that simplifies the design, build, and publishing process for web3sites on ENS domains.

Dune analytics link

Journey So far:

Our Moto: Users should own the content built using 1W3

At 1W3, we believe in empowering users to own the content they create. To achieve this goal, we have partnered with storage companies to create a mechanism that ensures content ownership is transferred to the user’s wallet address when they publish a web3site to IPFS. This means that users will have complete control over their content and can access it from the storage provider’s platform. With 1W3, you can create and publish content with confidence, knowing that you truly own what you create.

What users can create using 1W3

At 1W3, users have the ability to create a diverse range of content. Some examples include:

link in bio ( ENS linktree)
Personal Portfolio
Business websites
Sell domain landing page

1W3 provides the flexibility and tools necessary for users to create unique and compelling content that meets their specific needs. Whether you’re an individual looking to showcase your skills and experiences, or a business seeking to establish an online presence, we have the resources to help you achieve your goals. With our user-friendly interface and robust features, the possibilities are endless.

Links: A linktree alternative for the decentrallised web.

“Links” is a cutting-edge feature developed for the decentralized web presence. It offers an alternative to centralized services like Linktree, while empowering users with complete control over their personal pages.

With Links, you can create a personal page that showcases everything you are and everything you create. This includes your social media profiles, NFTs, videos, podcasts, newsletters, photos, and even your calendar. Unlike other platforms, all of your content is integrated into your personal page, which lives on the blockchain. This ensures that your content remains secure and accessible to you, no matter what.

Whether you’re a content creator, entrepreneur, or simply looking to establish an online presence, Links offers the tools and features you need to succeed. With a user-friendly interface and the ability to customize your page to your unique style, Links is the perfect choice for anyone looking to take control of their online presence.

Link: hidayath.eth.limo

Support for Emoji and Unicode Domains
hodlwizard.eth built this web3site using 1W3 for the below Emoji ENS domain
Examples: tesla🤖.eth.limo

Decentralised blogs

Build and manage blogs on the blockchain. It provide users with complete control over their content and design. Platforms like ENS News (https://ensnews.eth.limo/) can leverage this feature to build and manage their blog on the decentralised web.

Personal Decetralised Portfolio:

A simple drag-and-drop interface, allows users to easily add and customize different components such as text, images, and videos. Users can choose from a variety of templates to create a personalized portfolio website that best represents them.

Business Web3Sites:

Wide range of pre-designed website layouts that businesses can choose from to create their own web3site. The templates typically include a range of customizable modules like features, pricing, about, contact clients etc.

Some of the templates live on the platform

How grants will help us?

Grants can be a game-changer for our project by providing us with the necessary funding to achieve our goals. With grants, we can accelerate the development of advanced features and expand the storage capacity of IPFS and Arweave to host data for web3 sites. We can also create new web3 templates that offer enhanced elements tailored to the specific needs of individuals and businesses.

In the short term, our primary focus is to launch sophisticated Link in bio templates similar to Linktree, which will allow community members to showcase their links on their ENS domains. This will provide an easy and efficient way for individuals to share their online presence while maintaining control over their digital identity. With the help of grants, we can turn this vision into a reality and create a more accessible and user-friendly web3 ecosystem that meets the needs of our growing community.


Steward Commentary

ENS Ecosystem stewards are awarding 10,000 USDC to 1W3 in retroactive grant funding. We see 1W3’s no-code solutions for building Web3 sites as valuable to spreading adoption of both Web3 and ENS. Web2 products of a similar design have an outsized impact on today’s internet, with offerings from platforms like Squarespace and WordPress making up a large majority of websites. We’re excited to support them for their contribution and are confident in their ability to build.


Org3 - ENS Subdomain Based Organization Management Tool


Mission & Vision

We are building an ENS subdomain-based organization management tool, as we believe the ENS subdomain is a safer, cheaper, more intuitive, and more interoperable solution when it comes to DAO and web3 organization management.

We are planning to integrate use cases including payroll, communication (email/instant messaging), access control, file sharing, and more.


1. Original org3 was created at ETHSF in November: still accessible at https://org3.app

2. Org3 internally live in February: https://beta-org3.vercel.app/

ENS subdomain-based organization management tool

Key features:

3. M3MBER, Finalists at ETHDenver in March: https://m3mber.vercel.app/

ENS namewrapper (ERC-1155) & subname empowered membership protocol w/on-chain expiry.

Key features:

  1. Admin can give out (including batch airdrop) membership with customized mint & extend membership rules, implemented thru ENS subnames & namewrapper.
  2. Users can get subname membership, extend, transfer & resell them too.
  3. Example Features:


Internally Live at: https://beta-org3.vercel.app/. While everyone can access this link, we are still testing it and actively rolling out new features - official one will be available after namewrapper goes live on Mainnet.

Upcoming Plan

  1. Merge M3MBER features into Org3

  2. More Admin control features on the platform

  3. Mainnet deployment following ENS official namewrapper update on mainnet


Dec 2022

  • Gather feedback on features needs and set up features priorities in Q1 2023. At least gather feedback from 10 ppl in DAO governance.
  • Better UI/UX and frontend, for instance: Batch edit/create for domain owner; Hide unassigned subname

Q1 2023

  • Internally go live and improve features based on what people need
  • Better UI/UX design and frontend implementation to satiate larger database
  • Backend/feature update for ENS namewrapper
  • Integration with ideally 5+ platform/protocol

Q2 2023

  • Deploy a version on mainnet ready for public to use along with namewrapper
  • DAO Tool Integrations
  • Doc for 3rd party dapp development


Steward Commentary

ENS Ecosystem stewards are awarding Org3 with 10,000 USDC in grant funding. Subdomains are a vital aspect of ENS and can support greater adoption of the protocol. We believe Org3’s subdomain management platform is shaping up to be an important set of tools. The Org3 team has continued to show marked improvements on their product offerings week-over-week, and it has been great to see their work moving forward. We thank Org3 for their continued progress on the platform, and we are excited for the further evolution of the product.




Proof of Concept (Version 1)

NFTResolver Contract: 0x56942dd93a6778f4331994a1e5b2f59613de1387

Included Resolver Data:


  1. 1.azuki.nft-owner.eth (Standard 721)
  2. punk318.nft-owner.eth (Punk)
  3. doodle-2965.nft-owner.eth (Wrapped Doodle)
  4. 239.chonks.eth (Custom Domain)

Primary Objectives

  1. Determine best registration strategy
  2. Redeploy as two contracts: NFT Registry + Resolver
  3. Create simple minting website:
    • Enter NFT Contract eg. 0xe43d…ebad
    • Verify it is an ERC-721
    • Enter desired label(s) eg. “moo”
    • Verify it is unclaimed and have “right” to claim it
    • <Mint Button>

Additional Goals

  • Outreach to NFT projects and/or preregister popular projects
  • Acquire a better default base name than nft-owner.eth
  • Explore other use-cases of Wildcard w/o OffchainLookup


What is ENSRedirect?

ENSRedirect is a tool to help ENS domain holders make the most out of their .eth names. Users can generate and showcase their Web3 profile by seamlessly integrating videos and podcasts from their favorite social platforms, or by easily redirecting their domain to any website of their choice,all at no cost.We leverage IPFS for decentralized storage for robust and reliable access of users’ content.


  1. The idea behind ENS-Redirect was to make it easier for users to utilize their ENS names. Our aim was to simplify the process of leveraging ENS domains, allowing users to effortlessly redirect to their social/professional profiles or showcase their work.
  2. Through our latest feature, content creators can host their content on their ENS domains by generating their personalized profiles. By embedding videos directly onto the profile, content creators can seamlessly connect with their audience across multiple social media platforms, all on a single page within their ENS domain.

Project scope

  1. ENSRedirect tool to make .eth domain holders make the most out of their ENS domains and subdomains, created in November, 2022. Check it out: https://ensredirect.xyz/

  2. Redirect your ENS domain or subname to any website of your choice.
    domain: nftychat.eth (nftychat.eth.limo)
    subdomain: 28.ensgrants.eth (28.ensgrants.eth.limo)

  3. Generate and showcase your Web3 profile by seamlessly integrating videos and podcasts from popular social platforms such Youtube, Twitch, Tiktok, Apple podcast and Spotify.
    Link: gitcoingrants.eth (gitcoingrants.eth.limo)

  1. Deployed a bot on AT Protocol (Bluesky) that monitors and tracks newly updated web3 profiles and DNS redirects made through ENSRedirect.
    Link: Bluesky

Relevant Links

Demo video: https://demo.ensredirect.eth.limo/

Github: GitHub - ENS-Redirect/ensredirect-v2-react

Bot on Bluesky: Bluesky

Github Code: https://github.com/ENS-Redirect/bluesky-bott


  • We will continually develop our platform to support and enhance the experiences of content creators across various platforms such as YouTube, Twitch, Spotify, Apple Podcasts, and more.
  • UI/UX Improvements.
  • Integration of IPNS support to address the challenge of high gas costs for users.
  • Support redirects and profile generation for L2 names.
  • Gasless Updates of ENS Records via Offchain Resolver.

Unruggable Names

Demo Site: https://unruggablenames.com

We are building a smart contract-based system that extends the capabilities of the Ethereum Name Service (ENS) NameWrapper contract to enable unruggable rentals of .eth subnames. Our system ensures guaranteed renewable subnames, eliminating the need for subname renters to trust parent name owners, binding subname renters and parent name owners to predefined renewal policies. It also simplifies the renting of subnames including seamless registration and renewals.

How does it work?

Traditionally, renting subnames introduces a problem: if the parent name owner can change the renewal price at any time, they can potentially rug the subname renter by setting an unreasonably high price, such as $1,000,000. To address this issue, we contractually bind the parent name owner and the subname renter using a specially designed smart contract called a Renewal Controller. Each subname wrapped by the SubnameWrapper has a Renewal Controller assigned to it, which both the subname renter and the parent name owner trust to manage the rentals.

How do renewal controllers make subname rentals unruggable?

To prevent the parent name owner from altering the renewal price, a Renewal Controller is assigned to each subname in the SubnameWrapper. Once set, the renewal controller for a subname cannot be changed by the parent name owner or anyone else. This intentional design ensures that subname renters can always renew their names, regardless of the parent name owner’s intentions. This feature is what makes the rental process “unruggable.”

Why can’t we set the renewal price of a subname to a fixed dollar amount forever?

Setting a fixed dollar amount for renewal indefinitely is not feasible due to two reasons. Firstly, the value of a dollar could possibly increase or decrease significantly over time. Subname owners may use their names for many years, even decades, and predicting the long-term value of any fiat currency, cryptocurrency, or token is impossible. Additionally, relying on oracles or stable coins to set on-chain prices carries risks, as these technologies could change over time.

If we need to trust the Renewal Controller, how is the rental unruggable?

Renting subnames inherently involves trust, and a fully trustless rental agreement is not possible. In the case of ENS second-level names (e.g., example.eth), renewal is necessary to prevent expiration. The price, such as $5/year for example.eth, is set by the ENS DAO, which aims to protect name owners from arbitrary price increases.

What’s the end-game solution?

We believe that the market will ultimately determine what constitutes a trusted Renewal Controller. Our SubnameWrapper is an open and permissionless smart contract, allowing anyone to create their own registrars or Renewal Controllers. Unruggable Names, our DApp, utilizes our own trusted registrar and a curated set of Renewal Controllers. We are currently in the process of setting up a Renewal Controller that will be governed by a multi-signature wallet. Our goal is to establish a long-term stable renewal price that can be used by anyone to rent subnames.

We invite you to join us in building a vibrant ecosystem of communities renting subnames. Check out our live demo site at https://unruggablenames.com. We welcome your feedback on our demo of Unruggable Names which is currently deployed to Goerli testnet. Your feedback is valuable to us as we continue to refine and improve our system.


Nethereum integration of the ENS ENSIP 10 and EIP 3668 (CCIP Read)

What we are building?

Nethereum integration of the ENS ENSIP 10 (wildcard resolution support) and EIP 3668 (CCIP Read), this will enable Nethereum users to resolve offline ENS names on a shared parent domain, on top of the existing Nethereum ENS implementation.


New Contract Interfaces

Create new contract services in Nethereum.Contracts.Standards.ENS to support the interface ExtendedResolver including SupportsInterface
as per ENSIP 10 and the OffChainResolver reference implementation offchain-resolver/packages/contracts/contracts at main · ensdomains/offchain-resolver · GitHub

ENS Resolver changes

Upgrade existing Nethereum ENS Service Nethereum/src/Nethereum.Contracts/Standards/ENS/ENSService.cs at master · Nethereum/Nethereum · GitHub to support Offline Response Handling using the OffchainLookup error using the CCIP read and verification of callbacks. This will Resolve offline Address, Abi, Text methods, etc as per the original implementation.

CCIP Read Component

Create new class(es) to handle CCIP reading

DNS Encoding support

Include support for DNS encoding as per ethers.js ethers.js/src.ts/hash/namehash.ts at main · ethers-io/ethers.js · GitHub

Playground Example (Documentation)

Playground example(s) using 1.offchainexample.eth as per ENS Layer2 and offchain data support - ENS Documentation, these examples will be similar to the existing ENS examples http://playground.nethereum.com/csharp/id/1055

Integration Testing

Integration testing will be done using the existing domain 1.offchainexample.eth, custom local validation using the CCIP-read gateway offchain-resolver/packages/gateway at main · ensdomains/offchain-resolver · GitHub


The Nethereum integration of the ENS ENSIP 10 and EIP 3668 (CCIP Read) it is included now in the 4.14.0 release Release 4.14.0 ☀️☀️🍞🍞 · Nethereum/Nethereum · GitHub


Optimism CCIP Resolver (by dm3)


Using ENS to set records or other resolvers requires users to pay mainnet transaction fees hence ENS is deployed solely on Layer 1. We want to extend the capabilities of ENS by moving the resolver contracts to optimism to leverage the low transaction costs of the network.

This makes ENS more accessible and enables more use cases currently not feasible on L1.
This is used in solutions like dm3.network to store dm3 communication profiles as ENS text records more effectively.

Existing solutions

ERC-3668 defines how data can be retrieved from data sources other than the Ethereum mainnet.

A Resolver contract that implements the CCIP (Cross Chain Interoperability Protocol) standard, returns an URL to the client, that can be used to fetch the requested data.

A Gateway then queries the underlying data source and returns it to the client including a Merkle-Proof.

The integrity of the result is then proved using the Resolver contract to ensure the Gateway has not returned valid data.

There are already solutions built using conventional databases like Redis, Postgres, or others as data sources to store the data off-chain. While those solutions connect centralized web2 services to ENS, they offer a cheap and easy way to manage the data and might be sufficient for some use cases. But they require their users to trust the operators of the according system and other web3 ideals like censorship resistance and decentralization without any single point of failure are not fully possible.

Optimism Bedrock CCIP resolver

A different approach is to leverage decentralized Ethereum scaling technology to offer a trustless and decentralized way to store ENS records and link them back to their owners on L1. A key feature here is that rollups are committing a proof of their storage on Ethereum and thereby inheriting the underlying security of Ethereum. With this, proof of the integrity of the data can be provided.

This can be used to prove that arbitrary data is stored at the Optimism Rollup without having access to the Optimism Network in the first place.

This property is used by us to store ENS records in a decentralized trustless manner on L2 with a trustless proof on L1.

Why is this important to ENS?

Using ENS requires high transaction costs since the nature of the L1 fee market. Expanding to Rollups lowers the transaction fees significantly and allows using ENS for applications that are currently not thinkable. However, it’s crucial to stay compliant with the core values of Ethereum and not sacrifice decentralization and trustlessness or lower transaction fees. It also makes the strong growth of Layer2 solutions such as Optimism available as a standard for ENS data storage and combines both approaches in a way that can be easily and securely applied without significant additional effort and without giving up important web3 values.

To ensure that we’re scaling ENS the same way Ethereum is being scaled using Rollup technology.

How its build

Our Resolver Framework contains multiple components. In the section below an overview is given with a description of what their purpose is and how they are built.

Smart Contract L1


This contract is the entry point to the Resolver deployed on Ethereum L1. It implements the ERC-3668 standard. It returns the URL to the gateway and offers a way to prove that the returned data is valid. To prove the data, a delegate call is made to the BedrockCcipVerifier to prove the correctness of the data.

An ENS domain owner can set a different Verifier Contract. This is useful if they might use a different resolver contract on L2.

Bedrock CCIP Response Verifier

This contract proves that the requested data is part of a particular L2 contract. This contract might be the L2PublicResolver deployed on Optimism.

This contract is an implementation of the CcipResponseVerifier Interface for Optimism bedrock. Any other way of implementing CCIP response proofs can be deployed and registered by any ENS completely permissionless.

Bedrock Proof Verifier

This contract handles the internals of dealing with Optimism Bedrock Merkle proofs. It takes a Bedrock Storage proof as an argument and proves that the data is part of the optimism storage root.

Smart Contract L2

L2 Public Resolver

The L2 public resolver aims to implement the existing Public Resolver. One key difference is how we deal with authorization.

The L1 Resolver contract can ask the Registry contract whether a user has permission to alter a record or not. This can’t be done on L2 since there is no registry contract in the first place.

Therefore we established a “context” which is a separate layer intended to capture who has created the corresponding record.

This allows setting records on L2 without the need for authorization.

You can find an example of the TextResolver here Optimism-Resolver/contracts/l2/profiles/text/TextResolver.sol at bedrock · corpus-io/Optimism-Resolver · GitHub

Gateway Service

CCIP Gateway

The CCIP Gateway handles the request and computes a Merkle-Proof of the requested data. It supports every ENS Resolver Profile in the Layer2Public Resolver.

It contains the ProofService which can compute proofs of an arbitrary Storage Slot in Optimims Bedrock and the ENSService whose purpose is to calculate the slot position of the Proof Service.
While this is in the current implementation not decentralized, it is still fully trustless. If the proof is valid, the verification is true (and can’t be manipulated).

What is already build

  • Every component mentioned above
  • Metadata support and events to allow better indexing.

What we want to build in the future

  • Audit of the Smart Contracts
  • Productive Deployment
  • Wildcard subdomains (We have an idea how this might be solved but yet have to make a specification for that…)
  • Define and implement a decentralized approach for the gateways




Universal Offchain Records : Simplifying ENS Records Management Across EVM Chains

The OptiNames team has been diligently working on Offchain ENS records management. Our solution involves a single resolver contract deployed on mainnet/goerli, along with CCIP gateway and records contracts deployed on different EVM chains. Currently, our supported chains include Optimism, Arbitrum, and ZkSync Era, with more chains to be added soon.

Understanding EVM offchain Resolver:

Offchain Resolver (Goerli) - https://goerli.etherscan.io/address/0x8ca0e8c49ca6632dfb8c5bd5bfa2bb316659cd12#code

The Resolver acts as a bridge between ENS records and EVM networks, providing a streamlined approach to accessing records across multiple EVM chains. It utilizes the CCIP read standard for querying off-chain data. This innovative solution ensures users can effortlessly retrieve the most recent and valid record sets from different chains.

Setting Records on Different Chains:

Through contracts deployed on each chain, users can establish address records, content hash records, and text records. For example, users can set an address record on ZkSync Era, assign an avatar on Arbitrum, and add a Twitter text record on Optimism.

Resolving Records with EVM offchain Resolver:

When resolving ENS records, the EVM Resolver comes into play. When a user queries a specific ENS name, the resolver directs the ENS client to the offchain gateway. The gateway scans the available chains, retrieves the most recent and valid record set, and returns it to the user. This ensures that the resolved record reflects the latest information provided by the domain controller/manager for that particular ENS name.

Overriding Previous Records:

In cases where users update their ENS records on a specific chain, the gateway ensures that the most recent record takes precedence over any previously set record for that name. For instance, if a user sets a new avatar on Arbitrum, it will automatically override any previous avatar record set on another chain. This mechanism guarantees consistency and accuracy across different networks.

Practical Example: “ecc.eth” (goerli):

Let’s take a practical example to demonstrate the power of the EVM Resolver. Consider the ENS name “ecc.eth” on the Goerli testnet. This name has different records set on various chains. The manager has set the address record on ZkSync Era, the avatar record on Arbitrum, and the Twitter text record on Optimism. By leveraging the EVM Resolver, users can effortlessly retrieve the most up-to-date records for “ecc.eth” across these diverse chains.

Optimism transaction: https://optimistic.etherscan.io/tx/0x2c07885c839406b1a314b641d69741a56b0a0ca18899ad48c635b7b6a41c5013

Arbitrum transaction: https://arbiscan.io/tx/0x8fd4c05c6789ffb446b1494b117bcac246e620e008a4913de22b0dc65df5399a

ZkSync Era transaction: zkSync Era Block Explorer

Advantages for the ENS and Ethereum Communities:

  1. Enhanced Scalability: EVM Resolver brings the benefits of using cheaper networks to ENS, ensuring faster records setting and reduced congestion on the Ethereum mainnet.
  2. Cost Efficiency: By utilizing our offchain resolver and conducting transactions on alternate chains, users can significantly reduce transaction costs associated with ENS records management.
  3. Flexibility and Interoperability: Our resolver empowers users to choose the network that best suits their needs, providing flexibility and options for optimizing their ENS experience.

Next steps:

  1. Transition to using L2 state proofs.
  2. Mainnet Deployment of ENS_EVM_Resolver.
  3. Launch of Application for Adding and Editing ENS Records on Multiple Chains.
  4. Expansion of Chain Support: Base, Polygon zkEVM, Linea, Mantle, Taiko, and more.
  5. Integration with AvatarSync & ENS-Redirect.

Ongoing Project: ECC Name Service (Optimism)

ECC Names has emerged as the frontrunner in the registration of ENS subdomains offchain. Currently, ECC Names ranks among the top three subname communities, with an impressive count of over 20,937 registered names. Only Decentraland names and Coinbase IDs have surpassed this remarkable milestone.

As part of our ongoing project, we are actively working on integrating support for Optimism record setting for .ecc.eth subdomains. This means that the entire process, from registration to setting records, will now take place offchain on Optimism, making ECC NS the first of its kind to offer this comprehensive solution.

By expanding our capabilities to include offchain record setting, we are completing the cycle of managing ENS subdomains on Optimism. This significant milestone solidifies ECC Names’ position as a trailblazer in the domain registration space, with a strong commitment to leveraging the benefits of alternate & cheaper chains for seamless and efficient subdomain management.

Stay tuned for more updates as we continue to innovate and revolutionize the ENS landscape with OptiNames, setting new standards for user experience and technological advancement.


ENS offchain resolver gateway in Rust

Alternate implementation of the official TypeScript gateway, implemented in Rust language.

What is already built


  • more optional datastore solutions like SQL databases, KV databases, etc, using Rust conditional compilation to only compile wanted datastores
  • a gateway Rust library so that custom gateways can be easily created rather than duplicating the provided code
  • Webapp + API + CLI to allow records edits when using a DB storage
  • Later: L2 data instead of an offchain DB.

Advantages for the ENS community:

  • more appeal for Rust developers
  • potentially faster gateways, thanks to Rust performance

Hi @stevegachau.eth
I just wanted to flag the usage of the terminology. We have so far referred to L2 resolver as “Trust minimised resolver that can be verifiable using proof from rollup chain” (more on “L2 resolver” section of ENS Layer2 and offchain data support - ENS Documentation).

What you have implemented so far is off-chain resolver on multiple rolllup chains so the security assumption is same as what offchain resolver provides (eg: the current cbi.id and lens.xyz provide). The security is solely based on l1 name owner signing a signature on the gateway service. The owner of the l1 name can change the subdomain record on l2 without updating l1 resolver (nor even l2 record) by simply swapping your backend gateway server code (we often call this as “Trusted resolver”).

If I understand correctly your grant was given based on providing the user friendly UI and drove the adoption of the subdomain registration under ecc.eth so it doesn’t change the legitimacy of your grant receiving but I wanted to flag that as many people (including Vitalik himself) assumed your solution is using some sort of l2 state verification using a proof instead of just using a signature verification.

ENS lab is working closely with dm3 team to build and deploy the real L2 resolver. Of course you are more than welcome to transition your implementation to the real l2 resolver (or we can rename to "Trustless Resolver” if needed) in future.


@matoken.eth I have made the necessary adjustments to ensure clarity and avoid any confusion between our off-chain resolver and a trust-minimized resolver that utilizes L2 state proofs. Also looking into transitioning to L2 state proofs.



Namespace is a platform that enables searching and registration of ENS names and more importantly, available subnames from existing second-level names, allowing people to easily secure their web3 ID. Additionally, the core value proposition lies in providing ENS name owners with an advanced toolset to manage and issue the subnames from their ENS names. Owners have the ability to customize issuing these subnames by either selling them or giving them for free, leveraging the inherent value of subnames as NFTs.

Project Scope

At the moment, Namespace has two primary focus points:

  1. Namespace Manager – a place where ENS name owners will be able to use their names for variety of purposes (use cases).
  2. Search and Registration – front end allowing anyone to easily secure any .eth name or a subname from all listed second-level names.

Namespace Manager

Currently, Manager supports the “Selling Unruggable Subnames” use case that comes with preselected fuses that get burned when listing the name along with a set of features and functionalities Name owners get to customize to their needs.

Some features include:

  1. Minting price: Customizing minting price for base price, 2, 3, 4, and 5-letter subnames. Additionally, if left at 0, subnames will cost 0$ to mint.
  2. Reserving subnames: Reserving specific subnames for yourself that you can use any other way that you want depending on the name that you are listing
  3. Time-bound selling: the ability to sell certain subnames for a limited period of time in the future.
  4. Whitelisting:
    Option a) Only the whitelisted wallets can mint a subname
    Option b) Only the whitelisted wallets can mint a subname for free

Search and Registration

Currently, Search and Registration offers the ability to register any available second level .eth name. But more importantly, it displays subname options for the latest 5 listed names with the mint price that had been set by their owners if the searched second-level name is not available.

What we shipped

List of deliverables shipped during last 9-10 months

  • General:

    • Sign-in-with-Etherum implemented
    • Thorin design revamp - the entire platform
  • Namespace Manager:

    • ENS wallet design profile
    • Namespace user profile
      • Dashboard and key metrics display
      • Profile set up
    • Display of ENS names and subnames
    • Display Wrapped and unwrapped names
      • Basic info about names and subnames
    • Namespace Manager supports “selling uruggable subnames” use case
    • Listing names to be available to mint subnames from
      • Bulk listing
    • Subname mint price customization
      • Base price, 2, 3, 4, and 5-letter subname price setup
    • Reserving subnames
      • Excluding certain subnames from being mintable and reserving them for the owner to keep or resell at higher price or gift to someone etc.
    • Time-bound minting
      • ENS subname minting available during certain period of time
    • Whitelisting (two options for now):
        1. Only whitelisted wallets can mint
        1. Whitelisted wallets can mint for free
    • Updates and edits on the already listed names
  • Registration page:

    • Discover free or registered names
    • Register ENS names
    • Search all Listed names
    • Search for available subnames from listed names
    • Register ENS Subnames
    • Set as primary name during registration
  • ENS name page

    • Ability to mint subnames from official Name page
    • Basic profile
    • Text record setup
      • Subname holder benefits text record added

Contracts overview

The following contracts are used to enable the Namespace workflow:

  • NameRegistry
    • Contains ENS name listings, for which subnames will be minted
  • WhitelistRegistry
    • Contains the whitelisting configuration for listed ENS names
  • ReservedRegistry
    • Contains the reserved name configuration for listed ENS names
  • NameMintingRegistrar
    • Provides the functionality to add, update and remove listings stored in the registries
  • RegistrarProxy
    • Contains approvals given to the NameMintingRegistrar to access the registries
  • NameMintingController
    • Provides the functionality to mint subnames
  • NameWrapperDelegate
    • Gets approved to execute and delegate calls to NameWrapper

Contract Execution Workflow

Contracts are executed as illustrated below.

  1. Upon signing in, the first step is for the ENS name owner to access their account by navigating to Namespace Account and give NameWrapperDelegate the approval in NameWrapper. This way NameWrapperDelegate can set the fuses and mint the subname record.
  2. The next step is to call RegistrarProxy which sets the approval to allow the NameMintingRegistrar to access the ENS name owner’s listings in the registries. The initial call of the RegistrarProxy will also execute the initial name listing.
  3. Subsequent listing transactions such as adding, updating, and removing listings can be done by directly calling NameMintingRegistrar, which now has the approval to access the owner’s listings in the registries.
  4. Finally, once the names are listed anyone can hop on the registration page at Search & Registration. Upon searching for available subnames, the minting process is executed by calling NameMintingController. NameMintingController makes the delegated setSubnodeRecord() call to mint the subname, and the updateMintedListing() call on NameMintingRegistrar, which updates the registries upon the successful subname mint.

Future plans

  • Introducing more features to enrich the user experience with more tools.
  • Implementing renting after the SubnameWrapper contract is published developer by Premm.
  • Enabling all of our tools and features for DNS names by utilizing CCIP
  • Create a use case specifically for communities and provide custom tools for them

Author’s note: this post is very similar to the earlier Announcement Post. Reposting it here to support an earlier request from the ENS Ecosystem WG.

Python ENS Normalize

What We Built

NameHash has built and open sourced a Python implementation of ENS Normalize.

This work is based on the new ENSIP-15 Normalize Standard and became the second implementation of this new standard, following the first reference implementation in Javascript.

What this impacts

This library enables Python developers to normalize ENS names!

With many Ethereum tools and libraries written in Python, the Python implementation of the ENS Normalize library makes it easier to integrate ENS into new and existing Python applications.

This means ENS just became even more accessible for developers around the world to incorporate into their applications :rocket:

In the end, we hope this helps to contribute to a bigger ENS community and wider ENS adoption !

Give it a try

The NameHash Python Implementation of ENS Normalize is now available here:

You can also try it in a Google Colab Notebook.

Why We Built It

NameHash is building a platform with fun new ways to discover and register ENS names. Some of these features required a Python implementation of the new ENS Normalize. None existed yet. So our team put a special effort into creating one. We’ve open sourced our results to help empower builders from all parts of the ENS and Web3 community. We’re excited to see what others will create with it !

NameHash contributions to the new ENS Normalize Standard

The journey to build a new ENS Normalization Standard has been a long one ! There’s been a large effort, led by raffy.eth, and involving many contributors, to advance this new standard. Our team has been closely following each step in this effort. For more than a year, each time there’s been updates to raffy.eth’s Javascript implementation, our team would implement parallel updates to this Python implementation.

In general we’ve been followers behind raffy.eth here. But we’ve also made an effort to positively influence the standard in a few ways. This includes:

  1. Advocated for inclusion of all characters regularly used in languages such as Polish which we think is valuable for future ENS adoption.
  2. Identified various bugs and provided suggested solutions.
  3. Proposed the need for ens_normalize_fragment which is important for substring searches of normalized names.

The Python library we’re open sourcing also includes a few new features that go beyond a minimal implementation of the standard:

  1. A carefully crafted glossary for some of the technical ideas related to ENS names.
  2. Optimized modeling of normalization errors, including detailed error information.
  3. Implemented “ens_cure” - an algorithm that can “cure” many normalization errors that would fail ens_normalize.
  4. Python documentation with real-world examples.
  5. A developer guide for improving and updating the Python library.

This library includes an exhaustive testing and validation effort to ensure compatibility with the standard:

  • Passes 100% of the official validation tests (validated automatically with pytest).
  • Passes an additional suite of further tests for compatibility with the official Javascript reference implementation.
  • Provides 100% code testing coverage.
  • Passes all of these tests across Linux, MacOS, and Windows.

The Python ENS Normalize library demonstrated there can be multiple mature implementations of the new ENS Normalization standard. We hope this library and the careful testing that went into its creation increased confidence for the ENS DAO when it approved the new ENSIP-15 ENS Normalize.

New Feature: ens_cure

This algorithm can “cure” many normalization errors that would fail ens_normalize. ens_cure is NOT a part of the ENS Normalization Standard, but might be a useful utility for some situations. For example, if a user input fails ens_normalize, a user could be prompted with a more helpful error message such as: “Did you mean curedname.eth?”. Here’s a Venn diagram (not to scale) that summarizes how ens_cure expands the set of input values that can be normalized.

New Feature: Optimized modeling of normalization errors

Users just looking to normalize names in Python are free to ignore these new features and simply catch Python Exception objects with user-friendly messages.

As a quick summary: we’ve created a “hierarchy” for handling normalizations, cures, and errors:

  • A “normalizable sequence” which represents a change that must be made to the input name to confirm with the normalization standard, e.g. uppercase to lowercase conversion.
  • A “curable sequence” which represents an issue with the input name that is not normalizable through ens_normalize, but that might be resolved through a specific change suggestion in the input name, e.g. removing a space.
  • A “disallowed sequence” which represents an issue that cannot be cured through ens_cure automatically because it is challenging to describe the specific substring transformation that might be needed.

Full details on the optimized modeling of normalization errors can be in the GitHub repo.

This error hierarchy enabled our implementation of ens_cure:

  • ens_normalize automatically applies “normalizations”.
  • ens_cure automatically applies “normalizations” and “cures”.
  • “disallowed sequences” continue to be thrown from both ens_normalize and ens_cure.

Additional Resources Related to Python ENS Normalize

Other Popular Python libraries for web3

  • Web3.py: A Python library for interacting with the Ethereum blockchain, which provides functionality for sending transactions, querying data, and interacting with smart contracts.
  • Brownie: A Python-based development framework for building smart contracts and dApps on the Ethereum blockchain. It includes a built-in testing framework, an interactive console, and other tools for developing and deploying smart contracts.
  • eth-utils: A Python library that provides utility functions for working with Ethereum data types, such as addresses, hashes, and private keys.
  • eth-abi: A Python library that provides functions for encoding and decoding Ethereum contract ABI (Application Binary Interface) data.
  • py-solc-x: A Python library for compiling Solidity smart contracts into bytecode for deployment on the Ethereum blockchain.