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
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.
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.
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
Examples:
https://
punk.eth
https://
.eth
https://
.eth
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.
Chauffeur
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.
Hotcaching
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:
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)
Website
Twitter
Discord
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 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.
[Website][Twitter][Telegram][Discord]
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.
Journey So far:
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.
At 1W3, users have the ability to create a diverse range of content. Some examples include:
link in bio ( ENS linktree)
Blogs
Personal Portfolio
Business websites
Resume
Sell domain landing page
More…
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
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.
[Website][Twitter][Telegram][Discord]
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.
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.
ENS subdomain-based organization management tool
Key features:
Allow domain owner to create subdomain mint rules
Allow other people satisfying the rules to mint subnames
ENS namewrapper (ERC-1155) & subname empowered membership protocol w/on-chain expiry.
Key features:
Bulk Airdrop membership
Extend membership
An API (& SDK in the future) for DApp to build subname-gated interaction
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.
Merge M3MBER features into Org3
More Admin control features on the platform
Mainnet deployment following ENS official namewrapper update on mainnet
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.
NFTResolver Contract: 0x56942dd93a6778f4331994a1e5b2f59613de1387
Included Resolver Data:
Examples:
nft-owner.eth
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.
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/
Redirect your ENS domain or subname to any website of your choice.
Examples
domain: nftychat.eth (nftychat.eth.limo)
subdomain: 28.ensgrants.eth (28.ensgrants.eth.limo)
Generate and showcase your Web3 profile by seamlessly integrating videos and podcasts from popular social platforms such Youtube, Twitch, Tiktok, Apple podcast and Spotify.
Example
Link: gitcoingrants.eth (gitcoingrants.eth.limo)
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
Roadmap
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.
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.
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.”
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.
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.
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 (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.
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
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.
Create new class(es) to handle CCIP reading
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(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 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
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.
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.
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.
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.
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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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.
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
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.
Alternate implementation of the official TypeScript gateway, implemented in Rust language.
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.
At the moment, Namespace has two primary focus points:
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:
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.
List of deliverables shipped during last 9-10 months
General:
Namespace Manager:
Registration page:
ENS name page
The following contracts are used to enable the Namespace workflow:
Contracts are executed as illustrated below.
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.
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.
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 
In the end, we hope this helps to contribute to a bigger ENS community and wider ENS adoption !
The NameHash Python Implementation of ENS Normalize is now available here:
You can also try it in a Google Colab Notebook.
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 !
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:
The Python library we’re open sourcing also includes a few new features that go beyond a minimal implementation of the standard:
This library includes an exhaustive testing and validation effort to ensure compatibility with the standard:
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.
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.
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:
Full details on the optimized modeling of normalization errors can be in the GitHub repo.
This error hierarchy enabled our implementation of ens_cure:
