We now have a public roadmap that will keep track of completed, in progress and upcoming items. Check the ENS Labs roadmap.

Ledger and Argent wallet support

Exactly what it says on the tin!

Smaller Improvements

• The ENS Manager App will now display the grace period in the “more” tab:

• Users can now add their Telegram handle to their profile:

• Improvements to the way the manager app handles canceled and replaced transactions, particularly while the app is closed

• Other updates:

  • Updated ENS Labs team page with new members

  • Deployed new Universal resolver

  • Deployed ENS contracts to Sepolia testnet

New ENS blog sneak peek

While mirror is a great platform, and we will most likely continue to publish here, we felt the need to host our own blog in order to organise all of our content into one place. Additionally this will allow us to have more control over the look and feel. As well as adding in new features such as making it very easy to search through ENS content, this new site will include additional content such as podcasts and town hall meetings. Take a sneak peek here.

ENSjs Updates

ENSjs is functionally complete. We are now mostly working on making the library stable, and ensuring it works well in different environments. Keep track of progress here.

Other Updates Coming Soon

• A deep dive on Etherscan implementing C# ENSIP-15 library which helps handle ENS names with Zero Width Joiners and Unicode.

• A technical rundown and progress update of ENS on L2s

Bug fixes

• Transaction modals will close if the account or chain is changed

• Users with ‘$’ in their name can now edit their avatar

• Parent owner can now delete a subname when the parent is wrapped and the child is unwrapped

• Fixed issue where setting resolver to 0x00 would show wildcard label for a few seconds after updating

• Fixed issue where emoji names temporarily showed graph sync error message

• Fixed issue where emoji names were illegible on registration success screen

• Fixed issue where Chinese characters were displaying incorrectly on transaction progress bar

Comprehensive overhaul of primary name flow

We're excited to introduce our revamped primary name setting flow. Accessible from the settings page, the Manager App will now display a broader range of names. Unlike the previous version, which only listed names with an ETH record matching your wallet address — the updated flow now includes all potentially valid names, regardless of their ETH record or resolver status. This means you can now manage or own a name without an ETH record or a resolver. The system now efficiently identifies the most gas-effective method to set your primary name, eliminating the need for multiple app flows.

You can read more about it in our UX Lead Domico.eth's Twitter thread.

Key benefits for users include:

• Expanded list of potentially valid names: No longer limited to names with an ETH record matching your wallet address.

• Streamlined process: Setting a primary name now requires a single flow, regardless of the name's ETH record or resolver status.

• Optimized transactions: The app maps out all necessary steps, checks the name, resolver, and registry, and skips any unnecessary steps, reducing gas costs.

• Ability to unset primary name: Users can now remove their primary name directly within the app, with clear explanations of the implications.

• Community-driven improvements: These enhancements were made in response to valuable user feedback, continuing to demonstrate our commitment to creating impactful solutions based on user needs.

Additional manager app improvements

• Add primary name tag to profile, to make it clearer to the user when they are looking at their primary name.

• App will now show if resolver is coming from a wildcard lookup

• Suppressed the 'latest resolver' warning for unwrapped names

• Use multicall during registration more intelligently, improving gas efficiency

• Update app to support WalletConnect v2

Bug Fixes

• Manager app now works in mobile (iOS) Metamask, Trust Wallet and Coinbase in-app browsers

• Added registration fee buffer to protect against ETH price fluctuations

• Set gas fee to 0 during gas estimation for transactions, this allows us to get more detailed error messages

• Fixed issue where users on Firefox would be directed to the chrome store to download Metamask (upstream fix)

• Made external nav links open in a new tab/window

• Edit records modal now displays correctly on iPhone 8 (and other similarly sized screens)

• Fixed support for Safe transactions

• Allow abi records to be deleted from the advanced editor

• Changing network no longer disconnects the app

• Fixed some issues with the premium price chart inputs

• Small iPhone and iPad layout tweaks

• Stopped showing 'Edit Profile' button when the resolver is set to 0x00 and the ability to change the resolver has been burned

Ongoing

Work on ensjs version 3 is also ongoing. It has been refactored to use viem which has allowed us to simplify the codebase. You can checkout the progress here

Version 3 Release

Visit the app here.

Why is the current version of the app known as v3? Before the previous version, there was a lesser-known v1 version of the manager app. Check it out! It only works with names registered before 2019. If you didn’t register a name before then, try using arachnid.eth or jefflau.eth.

For the dev team, the release also marked the soft launch of our ENS utility library (ENSjs) rewrite and our design system Thorin.

There are too many improvements to go over here, and so we created a dedicated post to discuss them in detail.

Email reminders with Earnifi

We’ve partnered with earni.fi to bring you expiry reminders via email. These reminders will work for any name you are interested in, and you will get a reminder one month, one week, and one day before expiry. Simply navigate to the ‘more’ tab on any name and click ‘Remind me’ as shown below. You’ll be asked to provide the email address you would like the reminders to be sent to, and once you click the confirmation email in your inbox you’ll be all set.

As part of this update, we replaced dropdowns on mobile with 'Action Sheets' to provide a better user experience.

Wrapping and unwrapping names

We may have got a bit over excited about the NameWrapper, after release it started to become clear that many users did not feel the need to wrap their names and some people wanted to be able to unwrap them. This is likely because support for wrapped names hasn’t been added to many services in the broader ecosystem, and so users are likely to see errors on other platforms at the moment when trying to view their wrapped names. We still believe that in the future almost every name will be wrapped, but reaching that goal is also about education and community outreach.

In the manager app we are treating it more as an advanced feature for now. You’ll find the ability to wrap and unwrap a name in the ‘More’ tab, as well as info on the state of the name as it relates to wrapping.

Transaction in progress indicator

If you have a transaction in progress, you will now see a progress indicator (the blue dot) in key areas in the app.

Legacy Favourites

We intend to release a new and improved version of favourites in the coming weeks, however initially we did not provide a way for users to continue to view favourites that they had already added via v2. If you have legacy favourites, a link to them will show up in the navigation bar, and you can also navigate to them directly here.

Improved profile warning flow for various resolver states

Partly in response to community feedback, we decided to fast track improvements to the various warnings we show when opening up the profile editor depending on what resolver has been set:

• Migrate/Resolver out of sync: We've completely rethought this flow. Previously, it forced you to either migrate your records to the new resolver or use the records on the new resolver after editing the profile. Now it asks you if you want to change your resolver (which you can ignore), then checks if the records between resolvers are out of sync. If they're in sync, you'll have the option to reset or keep your profile. If they're out of sync, you'll get options to reset, migrate, or use the profile that exists on the new resolver. We've also added a warning for people resetting their profile.

• Resolver out of date: We've adjusted the flow to ask before editing the profile and to let the user ignore it if they wish. We've also added a warning for people resetting their profile.

• No resolver: We’ve updated the copy

• Registry out of date: We’ve updated the copy

These changes also allow people to use the profile editor for custom resolvers (before they had to use the record editor). Additionally we've added the option to ignore resolver upgrades in each flow.

Better handling of issues with The Graph

The ENS Manager app heavily relies on a third-party service called ‘The Graph’ for a lot of the data it displays. It is essentially a caching layer without which the app would be unusably slow. From time to time the service will be slow or unresponsive, which makes the manager app slow or unresponsive, which previously would have made the user feel like the app is down. Now we can handle this by showing a warning message and displaying data that doesn’t rely on the graph.

In-app support via Intercom

You can now reach our support team directly through the app. Look for the icon in the bottom right corner. A bot will initially try to help you but if it can’t you will always have the option to talk to a human.

Security improvements, a tale of two foxes (MetaMask, Firefox)

As a team we are taking steps to improve our security practices, and one of the outcomes of this initiative was implementing something known as a content security policy (CSP) for the manager app. This allows us to keep our users safe from entire categories of attacks by instructing the browser to disallow certain actions that could be used by an attacker to steal a user’s funds for example. It is something every dapp should consider implementing. Unfortunately, this causes problems on certain platforms, as the way some extensions work is very similar to how an attacker might try to steal your info, so only install browser extensions that you trust!

An open issue in Firefox that hasn't been fixed for years is the core of the debate. This issue means that Firefox blocks MetaMask and other wallets from interacting with the manager app when a CSP is in place. We now have a workaround for MetaMask, but there may be issues with other wallets. If you're having trouble, you can let us know directly in the app via Intercom.

Smaller Improvements

• Reduced the byte size of avatar text uploads for gas savings.

• Prevented cross-browser pre-rendering, which caused issues with MetaMask on first load.

• The app will now only migrate profiles when wrapping a name if the current resolver is not NameWrapper-aware.

• Organized useQuery cache keys using a queryKey factory.

• Improved gas estimates via the tenderly API.

• Increased the load speed of the registration page.

• Added a 'Recreate name' button so a parent can recreate a subname after it expires.

• Updated v2 to be NameWrapper-aware.

• Implemented protection against stale data during the input stage of the transaction flow.

• Removed target="_blank" for the owner/parent link

• Added custom 404 and error pages.

• Added banners for switching between v3 and v2 during the soft launch.

• Ensured v2 links direct to the correct place in v3.

• Prevented clicking outside of the transaction dialog during profile editing.

• Hosted the v2 app on legacy.ens.domains.

• Updated the avatar upload endpoint for better security.

Bug Fixes

• Fixed a bug where adding a custom record with ' or " on Desktop would crash the app.

• Resolved an issue where MetaMask wouldn't load correctly if the browser decided to pre-render the page.

• Fixed a validation failure in the Dogfood component due to a caching issue with reverse address lookup.

• Removed the 'name' record that was showing up as a default in the records editor.

• Fixed an issue where confetti would display twice after registering a name with MoonPay.

• Resolved an issue where the 'Extend name' button would hang after the page had been inactive for 2 minutes.

• Fixed an error that occurred when searching for a root node address.

• Fixed display issues with the feedback window on mobile.

• Adjusted the names list to display even if a name fails normalization.

• Fixed an issue where the 'Extend names' button would display a loading spinner each time the length was adjusted.

• Resolved a problem where searching for an address would return as invalid.

• Fixed alignment issues with the imported domain text.

• Added missing translation keys.

• Fixed an issue where an IPNS link in the content hash field would be marked as invalid in the editor window.

• Resolved an issue where a registered name would flash the register page when clicking "view name".

• Fixed WalletConnect issues.

• Corrected text alignment in the domain registrar dropdown.

• Fixed styling issues with the MoonPay dialog.

• Resolved a problem where subnames couldn't be edited if names had an expiry far in the future.

• Corrected the incorrect order when sorting names by expiry on the names list.

• Fixed an issue where the IPFS input asked for a content hash (it should ask for a content id (CID)) but expected a full IPFS gateway URL.

• Corrected an incorrect error message when setting an expiry for burning PCC.

• Adjusted the term 'Expiry' to always refer to the start of the grace period.

• Fixed issues with emoji normalization.

• Resolved an issue where the BNB address record couldn't be removed.

• Fixed an issue where the profile dropdown width was incorrect.

• Fixed an issue where the parent of ETH was shown as none.

• Resolved an issue where the Android PWA stopped working.

• Fixed an issue where searching with punycode would cause the app to crash.

• Adjusted the 'Extend' button to show when no extendable/selectable items are in the names list.

• Fixed a problem where names with hyphens were not displayed correctly in the transaction history.

• Improved the smoothness of avatar multi-touch.

• Fixed an issue where you couldn't go back in a transaction without losing your inputs when creating a new transaction flow inside a transaction input.

• Adjusted the content hash link to use .limo.

• Fixed an issue where the '%' symbol in the search would crash the site.

• Resolved an issue where resolver migration wasn't migrating ABI records.

• Fixed a display overflow issue with NightSky on Safari.

• Corrected an incorrect message when trying to delete subnames with subnames.

• Fixed an issue where the app would ask for approval to wrap a name, even if approval had already been granted.

• Resolved a problem where you couldn't unwrap a subname when the parent wasn't wrapped.

• Removed the unsupported TLD check for now.

• Fixed an issue where the app wouldn't load if a user had legacy favorites.

• Resolved an issue where the more dropdown would remain open if a user navigated away from the page while it was open.

• Fixed a glitch where expired subnames could be registered even when the parent was in the grace period.

• Fixed incorrect sorting of the names list when a user had a high number of names.

• Fixed a problem where the DNSSEC button would overlap the link to v2.

• Fixed a display issue with NightSky on Safari.

Known Issues

• There may be an issue where you're unable to connect to a wallet on Firefox due to our Content Security Policy (CSP). We have a workaround for MetaMask, but there may be issues with other wallets. Please let us know via Intercom if you're having this issue.

• Our Content Security Policy (CSP) blocks certain extensions. Be careful when installing browser extensions and only install those that you trust.

• Some services in the broader ecosystem don't yet support wrapped names. As a result, users may encounter errors on other platforms when trying to view their wrapped names.

Table of Contents

• Introduction

• The ENS Name Wrapper

• Example - Step By Step

• Example - Parent Locks Subname All-In-One

• Example - Multiple Subnames in Various States

• Name Wrapper Fuses

• Name Wrapper Expiry

• Approved Operators

• DNS Domains and Fuses

• Use-Cases

  • 1.) I want to give subnames out to all of my DAO members / NFT holders!

  • 2.) I want to sell / rent out subnames!

  • 3.) Other cool things you can do

    • Issue subdomains as tickets to an event

    • Lock the resolved records for a name

• Recap

• Other Links

Introduction

Before we dive into the Name Wrapper, let’s briefly recap some basic ENS concepts that will give some helpful context.

The Registry is the core contract at the heart of ENS resolution. All ENS lookups start by querying the registry. The registry is not just for .eth second-level names (like name.eth), but for all ENS names (subnames like sub.name.eth, and also DNS names like domain.xyz). The owner of the name in the registry is also referred to as the Controller or Manager of the name.

The .eth Registrar is specific to .eth second-level name registrations. This is essentially a subdomain registrar for the TLD (top-level domain) .eth. When you register a .eth name, the registrar issues you an ERC-721 NFT.

The owner of that NFT is also referred to as the Registrant or Owner of that name. It can be used to reclaim ownership over the name in the core registry as well (in other words, the Registrant can overwrite the Controller).

As you can see, without the Name Wrapper, only .eth second-level names are NFTs currently. Subnames and DNS domains do not have NFTs associated with them by default, unless a custom contract is created for that purpose.

The ENS Name Wrapper

Woah don’t worry, I’ll explain all of this soon enough.

The Name Wrapper wraps an ENS name into a new ERC-1155 NFT. Any ENS name can be wrapped, whether it’s a .eth name or DNS domain or even any subname!

There is a Use-Cases section later on in this article too.

You can take your name.eth…

And turn it into a wrapped ERC-1155 NFT!

Let’s take our sub1.name.eth subname from up above, and wrap it!

Now the subname is a wrapped ERC-1155 NFT too!

Those lines you see represent so-called “permission fuses” for your wrapped ENS name, which I’ll explain in a bit.

Registry Owners with the Name Wrapper

How does this affect the core registry though?

When you wrap a name, you are setting the Controller to the Name Wrapper contract. In return, the Name Wrapper issues an ERC-1155 NFT and transfers it to you.

For .eth second-level names, you transfer the Registrant / NFT (in the .eth registrar) to the Name Wrapper contract when you wrap. The Name Wrapper will automatically reclaim the Controller in the core registry too.

Before, there was no NFT at all (for subnames and DNS names at least):

After you wrap a name, technically the Controller in the registry is now the Name Wrapper contract. That means that you cannot interact directly with the ENS registry for that name, because you are not the Controller.

However, the Name Wrapper contract provides all the necessary methods so that you can still interact with the registry. You can transfer ownership, set the resolver/TTL, and even create subnames just as you would normally. On top of that, any subnames you create will be automatically wrapped by default as well!

States of an ENS Name

We’re almost ready to see some visual examples! But first, let’s get some terminology out of the way…

In addition to all the functionality that the name gains from being a fully-fledged ERC-1155 NFT, the Name Wrapper provides a number of ENS-specific features as well.

It does this with a “fuse” system. Each “fuse” represents some kind of permission for the name. When you burn a fuse, you are usually revoking some kind of permission. In the ENS Manager UI, this is available in the “Permissions” section of the name.

For example, by default when you wrap a name, you can transfer that NFT around freely, just as you can with other NFTs. However, if the “Cannot Transfer” fuse is burned, then the NFT becomes non-transferrable. In the ENS Manager UI, you would do this by revoking the “Can send this name” permission.

As the name implies, once you burn a fuse, you cannot undo that action, until the expiry at least.

The expiry is how long the fuses are active for. The expiry on a name is set by the parent owner. For .eth second-level names, the expiry is set to the same expiry from the .eth registrar. When the expiry is reached, all fuses reset. In addition, if your name is Emancipated or Locked, then you lose ownership of the name when it expires. There is a section later that goes into greater detail about the expiry.

There are also special fuses that determine the relationship between “parent” and “child” names, or alter the state of the wrapped name. A name can be in one of these possible states:

Unregistered

The name has not even been registered/created yet, or it has expired.

Unwrapped

The name exists and has not expired (in the case of .eth second-level names). The Name Wrapper contract does not have ownership over the name. You own the name in the registry and/or .eth registrar.

Wrapped

The Name Wrapper contract has ownership of the name (in the registry/registrar). You are issued an ERC-1155 NFT in return, which proves that you are the actual owner. You can unwrap the name at any time, which burns the ERC-1155 NFT, and returns ownership in the registry/registrar back to you. If your name is a subname like sub.name.eth, then the owner of name.eth can technically replace the subname and transfer it to a different owner. In addition, the parent owner can burn parent-controlled fuses on your name.

Emancipated

The owner of the parent name is no longer able to replace this name, or burn any additional fuses on it. All .eth second-level names (like name.eth) are automatically put into the Emancipated state when they are wrapped. The name can still be unwrapped and rewrapped by the owner.

Locked

The name can no longer be unwrapped. The owner can now burn owner-controlled fuses on the name. Fuses for subnames of this name can now be burned as well.

Example - Step By Step

Wrapped Subnames

Let’s dive into an example to learn more about fuses.

Say you have name.eth and sub1.name.eth, both wrapped. You have already locked name.eth, but no fuses have been burned on the subname yet.

The subname is Wrapped but not yet Emancipated, so the parent still has full control. Check out the diagram below, see that anchor there in the top-left of the subname? This means that the parent owner can still control the subname. It can burn Parent-Controlled Fuses, or it can even completely replace the subname if it wanted to.

The owner of the subname can still unwrap/rewrap, transfer, set the resolver/TTL, and even create new subnames of its own. However the owner cannot burn any fuses on the subname or any sub-subnames yet.

I’ll keep the name.eth node stripped down so it’s hopefully not as confusing, since we’re focusing on the sub1.name.eth subname right now. See the diagram below:

Burning Parent-Controlled Fuses

While in this state, the parent owner can burn Parent-Controlled Fuses while continuing to have full control over the subname.

There are 3 total predefined Parent-Controlled Fuses, and then there are 13 undefined fuses that you can use however you wish. One way to think of these fuses are as "perks" for the owner of the subname.

For example, if you are using ENS subnames to issue tickets to an event, you could use these Parent-Controlled Fuses to unlock perks, like the ability to redeem some swag or get into a special event (maybe it even automatically integrates with one of those smart door locks when the person taps an access card!).

I’ll show one of the Parent-Controlled Fuses being burned in the diagram below. In this case, it’s the CAN_EXTEND_EXPIRY fuse, which allows the subname owner to extend their own expiry (there is a section later going over all the fuses and what they do).

Burning the “Parent Cannot Control” Fuse

To Emancipate a name, burn the special "Parent Cannot Control" fuse.

After burning, no more fuses will be able to be burned by the parent.

The owner of the parent name will also no longer be able to replace the subname.

Remember that anchor in the top-left of the diagram? Burning the PCC fuse will blow that away! Without that anchor, the child drifts away from the parent and severs all the remaining fuses. So the parent owner will no longer have any control over this child!

In addition, see that other fuse going down below PCC? It will also blow away a section of wall, giving the subname owner access to its own “matchbox”! The subname owner will now be able to burn fuses on their own.

I’ve circled these places in green in the diagram below:

Emancipated Subnames

The subname sub1.name.eth is now Emancipated.

The parent can no longer burn any fuses, or replace the subname (up until the expiry).

The subname is not yet Locked though, so the owner of the subname can still unwrap the name if they want! If the name is unwrapped and then rewrapped, everything will still be in the same Emancipated state with the same fuses burned.

Because the name is not yet Locked, the owner of the subname cannot burn any other fuses (besides “Cannot Unwrap”). The owner cannot burn any fuses on any of its own subnames yet either.

See that section below that is now green? Now that the parent has burned PCC, the owner has access to its own “matchbox”, and can start playing with fire!

You might also notice that the fuse for “Cannot Unwrap” is accessible from within this same section…

Burning the “Cannot Unwrap” Fuse

To Lock a name, burn the special "Cannot Unwrap" fuse.

This can only be burned if PCC (Parent Cannot Control) has first been burned by the parent.

In other words, it can only be burned if the name is already Emancipated.

See that bundle of dynamite with “CU” next to it? That’s gonna blow when you burn the Cannot Unwrap fuse. If you follow the other fuses attached to it, you’ll see that it’ll also blow up a few other things, which I’ll go over next.

I’ve circled in green the areas that will be affected in the diagram below:

Locked Subnames

The subname sub1.name.eth is now Locked. This means that the name can no longer be unwrapped.

Look at the diagram below, Simba. Everything the green light touches is our kingdom.

Now that the name is Locked, the owner can burn other Owner-Controlled Fuses. The owner can also burn fuses for any subnames of its own.

There are 7 total predefined Owner-Controlled Fuses, and then there are 9 undefined fuses that you can use however you wish.

Burning Owner-Controlled Fuses

For example, you can burn "Cannot Transfer" and "Cannot Set Resolver".

Now the name cannot be transferred/sold, and the resolver contract can no longer be overwritten, up until the expiry.

Burning the “Cannot Burn Fuses” Fuse

If you burn the special "Cannot Burn Fuses" fuse, then no more fuses can be burned on the name.

The parent owner may burn this fuse on a subname to ensure that some permissions remain "locked open".

The owner of the name could also choose to burn it. For example, if the name uses a subdomain registrar, the owner could leave “Cannot Create Subname” unburnt, and then burn the "Cannot Burn Fuses" fuse to guarantee that new subnames can always be registered.

See the remaining bundle of dynamite with “CBF” next to it? Once that blows, all of the other Owner-Controlled Fuses will be rendered inaccessible. I’ve circled it in green below:

All Fuses Frozen

The "Cannot Burn Fuses" fuse has now been burned.

The fuses for the name are now completely frozen until its expiry. Any previously burned fuses will remain in that burned state, but no other fuses can be burned on this name now.

However, the owner can still burn fuses of any subnames, assuming that it has not yet emancipated them.

Example - Parent Locks Subname All-In-One

Okay, so I simplified a few things earlier to make it easier to follow.

Usually there won't be so many steps. The parent can burn multiple fuses at once, and take the name all the way to the Locked state in one fell swoop.

For example, say you want to emancipate and lock a subdomain, and burn a Parent-Controlled fuse, and burn some Owner-Controller fuses too?

To do that, you will burn "Parent Cannot Control" and "Cannot Unwrap", and all the other fuses you want, all in one transaction.

Remember, once PCC is burned, no further fuses can be burned by the parent.

Also, if you want to burn any Owner-Controlled Fuses, you must also burn CU (Cannot Unwrap). You may have noticed that purple “CU Lock” on the diagram. That indicates that in order to burn any of those fuses, you must also burn CU.

In addition, the CU fuse can only be burned if PCC is already burned, or burned at the same time. Similarly there is that purple “PCC Lock” on the diagram. That indicates that in order to burn CU, you must also burn PCC.

I know this is a lot to take in, but as an example, I've highlighted some fuses in green below:

After burning those fuses, the subname is now Locked.

In addition, the “Can Extend Expiry” fuse was burned, and the "Cannot Transfer" fuse was also burned.

The owner of the subname still has the ability to burn other fuses and create new subnames of its own in this case. The parent could have decided to restrict things even further by burning other fuses, like "Cannot Create Subname" or "Cannot Burn Fuses".

But now that the parent has burned PCC, it has relinquished control over this subname, and it can no longer burn anything else.

So we just saw how you can take an existing wrapped subname, and Emancipate / Lock it, with fuses burned, all in one step.

Just so you know, the same can also be done when you create an entirely new subname!

If your name is wrapped, and you create a new subname under it, that subname will also be wrapped by default. And at the same time, in the same transaction, you can also pass in your desired list of fuses to burn (and the expiry).

So you do not have to create a subname and then separately burn fuses. You can do everything in one transaction.

Example - Multiple Subnames in Various States

Now let’s zoom out a bit, and I’ll even fill in the name.eth wrapper this time.

Remember that .eth second-level names are automatically put into the Emancipated state when they are wrapped. They are not automatically Locked though. When you register/wrap a .eth second-level name, you can pass in any owner-controlled fuses you want to burn to start with, so you can go directly to the Locked state if you wish.

As you can see, each subname does not have to be in the same state. Some can be Locked, some Emancipated, and some merely Wrapped. It’s entirely up to the owner of the parent name and how much power or freedom they want to give to child names.

This will depend on the use-case. Using subnames for a temporary ticketing system is going to have different constraints than a permanent subdomain registrar, for example.

Name Wrapper Fuses

As previously mentioned, a "fuse" is a permission or perk that can be granted/revoked on a name. As the name implies, once the fuse is "burned", it cannot be unburned. Fuses will only reset when the expiry is reached.

There are parent-controlled and owner-controlled fuses:

Parent-Controlled Fuses

PARENT_CANNOT_CONTROL:

Allows a parent owner to Emancipate a child name. After this is burned, the parent will no longer be able to burn any further fuses, and will no longer be able to replace/delete the child name. This fuse must be burned in order for any owner-controlled fuses to be burned on the name.

IS_DOT_ETH:

This fuse cannot be burned by users of the Name Wrapper, it is only set internally when a .eth 2LD is wrapped.

CAN_EXTEND_EXPIRY:

The owner of the child name will be able to extend their own expiry. Normally, only the parent owner can extend the expiry of a child name.

Custom Fuses:

There are 13 other parent-controlled fuses that are not reserved, and can be used in any custom way you want!

Owner-Controlled Fuses

CANNOT_UNWRAP:

The name will now be Locked, and can no longer be unwrapped. This fuse must be burned in order for any other owner-controlled fuses to be burned on the name.

CANNOT_BURN_FUSES:

No further fuses can be burned on the name.

CANNOT_TRANSFER:

The name (wrapped NFT) can no longer be transferred.

CANNOT_SET_RESOLVER:

The resolver contract for the name can no longer be updated.

CANNOT_SET_TTL:

The TTL for the name can no longer be updated.

CANNOT_CREATE_SUBDOMAIN:

New subdomains can no longer be created.

CANNOT_APPROVE:

The approved subname renewal manager for the name can no longer be updated. See the Approved Operators section below for more information.

Custom Fuses:

There are 9 other owner-controlled fuses that are not reserved, and can be used in any custom way you want!

Name Wrapper Expiry

For unwrapped names, only .eth second-level names (like name.eth) have the concept of an expiration date (set in the .eth Registrar). The Name Wrapper has the concept of an expiry as well, which can apply to .eth subnames too. This expiry determines how long any burned fuses are active for, and may also determine whether the name itself has expired. In order to use fuses, a name must also have an expiry set.

When the Name Wrapper is used:

• The expiry for .eth second-level names will automatically be set to the expiry from the .eth Registrar (plus the grace period).

  • It’s possible the wrapped expiry can get “out of sync” if you renew via the old registrar controller contract. In this case, you can re-sync the wrapped expiry by calling the renew method on the wrapper contract.

• Other .eth subnames can have their own separate expiry, and at maximum it can be set to the expiry of the parent node.

• The expiry does not apply to any DNS names, since they currently cannot use fuses.

You may choose to not burn any fuses on a subname and leave it in the Wrapped state if you wish. In that case, the expiry has no practical effect and can just be left as 0. However if you wish to burn any fuses (or emancipate/lock a subname, which requires fuses to be burned), then you must also set an expiry.

The expiry applies to all fuses that may have been previously burned, both parent-controlled and owner-controlled. When the expiry has been reached, all fuses will be reset.

Max Expiry for Subnames

By default, the expiry for a name can only be set by the parent, and can only be increased, not decreased. The maximum value for the expiry of a name is the expiry of its parent name.

For example, say a name expires in 5 years. The owner of the name can then set the expiry of its subnames to a maximum of 5 years as well. But the parent could also choose to set the expiry to something less. Let’s say the parent sets the expiry of one of its subnames to 2 years. Then in turn, the owner of the subname can set the expiry of its own subnames up to a maximum of 2 years, but it could also set it to something less, like 1 year.

The parent can set a different expiry for different subnames too, just as it can burn different fuses for different subnames.

Renewals

When a wrapped .eth second-level name (like name.eth) is renewed, that new expiry is automatically set in the Name Wrapper as well as in the .eth Registrar. However, the expiry for any other .eth names (like sub.name.eth) will not be automatically extended when the parent expiry is extended.

The parent can extend the expiry for an existing subname at any time, even if the subname has been emancipated.

The parent can also choose to approve a separate contract to allow the expiry for subnames to be extended by the subname owner or other accounts. That is basically how .eth second-level names work: Since the eth node is locked in the registrar contract and has the Name Wrapper (which exposes a renew method) approved as a controller, .eth second-level names can be directly renewed by their owners. The parent can further lock this approved contract in by burning the CANNOT_APPROVE fuse.

There is also a special parent-controlled fuse called CAN_EXTEND_EXPIRY. If the parent burns this fuse on a subname, then the owner of that subname (or any approved controller) can also extend the expiry.

So, if you are running a subname registrar and you want to enable “unruggable renewals”, you can use one of the above options (or both).

Special Cases for .eth 2LDs

For .eth second-level names, the end of the name’s grace period (from the .eth Registrar) is used for the expiry inside of the Name Wrapper. So if the name’s expiration date in the Registrar is January 1st, then the expiry in the Name Wrapper will reflect that date plus the grace period (currently 90 days, so approximately April 1st, depending on the year).

When the name’s expiration date (from the .eth Registrar) has been reached, and the name is now in the grace period, all Name Wrapper operations on the name will be restricted. The owner will not yet lose ownership of the name, but they will also not be able to unwrap or update the name until it has been renewed.

Expiry Implications

When a name is merely Wrapped but not Emancipated or Locked, parent-controlled fuses can still be burned. This means that the parent can burn a custom fuse for a limited amount of time. When the expiry is reached, all fuses will be reset, but the name will otherwise be unaffected. Also, as a reminder, the parent must first be in the Locked state before it can burn fuses on any subnames.

When a name is Emancipated or Locked, the expiry has an important additional effect. In this scenario, when the expiry has been reached, the name itself will expire, and the owner loses ownership of the name. The Name Wrapper contract will return the null address (0x000…) as the owner for any expired name. This means:

• The name will not be able to be transferred.

• The NFT for the name may disappear from websites/dapps/wallets as the owner is now the null address.

• The resolver/TTL will not be able to be updated.

• New subnames will not be able to be created.

• Existing subnames will not be able to be altered.

• Depending on the resolver contract, the name may continue to resolve to any records that were set before the name expired.

• Depending on the resolver contract, records for the name may no longer be updatable.

When a subname expires, the parent regains the power to completely replace the subname, with a new expiry, a new set of fuses, and even a new owner. That “new set of fuses” is up to the parent. They could choose to completely reset all fuses, or they could choose to use the same set of fuses that were previously set before the subname expired. So if the parent wanted to simply “reactivate” the subname in the same state it was before, it could recreate the subname with the same owner and same set of fuses, but with a new expiry.

Approved Operators

Full-Control Operator Batch Approvals

Your wrapped name is an ERC-1155 NFT that supports the setApprovalForAll method. When you approve an address using this method, it will have full control over all wrapped ENS names that you own.

This method is typically used by NFT marketplace contracts.

Name-Specific Subname Renewal Manager Approvals

The Name Wrapper also supports the ERC-721 approve method. This method is used to approve a single “Subname Renewal Manager” for a specific name.

The “Renewal Manager” does not have full control over your wrapped name, it can only set / extend the expiry on subnames.

Further, if you burn the CANNOT_APPROVE fuse on your name, then the approved renewal manager can no longer be changed. You can use this to “lock in” that contract, so that you can guarantee to all subname owners that renewals/extensions can always be done.

This approved renewal manager will be reset if the wrapped NFT is burned or re-minted, which happens if you unwrap the name, or if an expired name gets re-registered. It will also be reset if the wrapped NFT is transferred, unless the CANNOT_APPROVE fuse is burned.

Example - Subname Registrar Contract

You can use these operator approval methods to setup a separate contract that can take certain actions on your behalf. One example is setting up a “subname registrar” to allow users to register/renew subnames.

That subname registrar contract would act on your behalf and allow users to register subnames. To allow this, you would call setApprovalForAll to give that contract full control over your name (and thus the ability to create subnames).

Then, to enable “unruggable renewals”, you could call approve on that same contract (or a separate one specific to renewals if you wish) and burn CANNOT_APPROVE to lock in subname renewals for that contract.

If you need to later on, you would still be able to revoke with setApprovalForAll. So the contract would lose full control over your name (and the ability to create new subnames), but it would still be able to perpetually renew/extend existing subnames.

And you can do all of this without needing to send your wrapped NFT to that contract.

DNS Domains and Fuses

As previously explained, in order to burn fuses on a name, the parent name must be Locked. The reason is, if the parent name was not locked, then the owner of the parent name could simply get around the constraints of the Name Wrapper by unwrapping the name, and replacing/revoking subnames against the core ENS Registry.

This is why I’ve said in this guide that currently, only .eth names support fuses, because only the eth node is on-chain native and completely locked beyond anyone’s control.

This is not to say that DNS names “can’t ever” use fuses. Technically speaking, the owner of a DNS TLD has the ability to burn fuses on that TLD in the Name Wrapper, and set it to the “Locked” state. And then from there, all subnames under that DNS TLD will be able to use fuses. The DNS TLD owner would need to:

• Request the Controller of that TLD from the ENS DAO

• Wrap the TLD node in the Name Wrapper

• Burn the PARENT_CANNOT_CONTROL and CANNOT_UNWRAP fuses on the wrapped TLD to lock it

However, this still does not have all the immutable guarantees that .eth names do. This is because for DNS names, the “source of truth” always lies not in the Ethereum network, but in the DNS network, and the DNS root zone governed by ICANN stakeholders.

So even if the DNS TLD owner “Locks” that TLD in the ENS Name Wrapper, if that TLD were to ever change ownership on the DNS side, then (per the ENS DAO constitution) the new owner would be able to override control of that TLD on the ENS side, unwrap it, and replace/revoke all 2LDs.

This is just something to keep in mind for wrapped DNS domains.

However, even if wrapped DNS domains do not support fuses, you can still use them as ERC-1155 NFTs. They will still have their own NFT metadata and show up in your wallet, with whatever avatar you have set, etc. They just won’t have all the extra functionality that comes with the fuse/permission system.

Use-Cases

1.) I want to give subnames out to all of my DAO members / NFT holders!

Say you own the wrapped name mycoolnft.eth, representing a popular NFT project you created. You want to distribute subnames like 6529.mycoolnft.eth to all holders.

One option is to just bulk create the subnames and drop the wrapped NFTs into their wallets. This might be good at least as an initial drop, because then the holders don’t need to interact with any contract or spend any gas, you’re doing that for them!

To create the subnames, you’d use the setSubnodeOwner or setSubnodeRecord methods.

You must also decide:

How much control over the subnames do you want to relinquish?

Do you want to be able to revoke subnames? Or do you want them to be completely outside your control?

One thing to consider is whether you want the current holder of your NFT to always be able to claim/reclaim the corresponding ENS subname. If so, then you will not want to Emancipate those subnames (in other words, do not burn PARENT_CANNOT_CONTROL). If the subname is Emancipated, then the NFT holder could sell/transfer the NFT but keep the subname (up until the expiry).

To make it easy for anyone to claim/reclaim a subname after your initial drop, you can set up a contract for this.

Setting up a subname claim contract

The claim method of your contract could:

1. Call ownerOf or balanceOf on your NFT contract to get or verify the current owner of the NFT

2. Call ownerOf or balanceOf on the ENS Name Wrapper contract to get or verify the current owner of the wrapped subname

   1. If both owner addresses are the same, just return, nothing to do

3. Call setSubnodeOwner or setSubnodeRecord on the ENS Name Wrapper:

   1. owner: The current owner of the NFT

   2. fuses: What fuses you want to burn (if any) on that subname. If you burn any fuses, you must also set an expiry.

   3. expiry: When the subname will expire.

Then, to give that contract access to create subnames on your behalf, you would call setApprovalForAll on the Name Wrapper to approve your contract as an operator.

Now, even if the NFT gets sold / transferred, the new owner will be able to claim their mycoolnft.eth subname at any time.

In addition, if you expand your NFT collection in the future and there are new owners, then those new owners would be able to claim their subnames as well.

If you are creating a new NFT contract, you could even bake this functionality directly into the NFT contract too, instead of needing a separate contract! By doing this, you wouldn’t need a separate claim method either, your NFT contract would just automatically transfer the wrapped ENS subname whenever the NFT itself gets transferred!

Giving your subname owners perks

If you decide to not Emancipate the subnames that you issue, you will still be able to burn any Parent-Controlled Fuses. There are 13 unreserved parent-controlled fuses that you can use however you wish!

For example, perhaps you want to grant on-chain “perks” or “roles” to certain holders. You would call setChildFuses on the Name Wrapper and pass in the fuses you want to burn, and the expiry.

This means that those “perks” or “roles” can also be time-boxed if you want. Maybe a perk expires in 1 week or something, up to you.

There is also the reserved CAN_EXTEND_EXPIRY parent-controlled fuse. If you burn this, then the subname owner will be able to extend their own expiry whenever they want.

2.) I want to sell / rent out subnames!

Say you own the wrapped name verypopularname.eth. Obviously you can just manually create wrapped subnames like my.verypopularname.eth and then sell them on an NFT marketplace. But that sure doesn’t scale well.

To accomplish this, you will want to create a subname registrar. This is a contract that will handle all the registration / renewal for you, and then users will be able to interact with that contract in order to register their own subnames.

In fact, this is exactly how .eth 2LDs are registered. The owner of the eth TLD (the NFT contract) delegates registration / renewal to the ETHRegistrarController contract. It is acting as a subname registrar for the name eth.

Your contract would expose a register method that anyone can call. Under the hood it will use the setSubnodeOwner or setSubnodeRecord methods to create subnames, passing in the fuses and expiry you want to set.

What fuses should I burn???

First, note that if you want to burn any fuses on subnames, then your name must be Locked (meaning CANNOT_UNWRAP is burned).

Assuming that you want your subnames to be “unruggable”, such that you cannot replace / revoke them, then you will want to burn PARENT_CANNOT_CONTROL on the subnames. This will place them in the Emancipated state upon registration.

If you want to sell “forever” subnames, where users register once and can then keep them for as long as they wish, then you can consider burning the CAN_EXTEND_EXPIRY fuse. This will allow the subname owner to extend their own expiry whenever they want. The max expiry is the expiry of the parent name, but the .eth Registrar allows anyone to renew/extend a .eth 2LD as well.

If you just want to rent subnames, then do not burn CAN_EXTEND_EXPIRY. Instead, you could include a renew method on your contract that users can call for another fee.

If you want to enable “unruggable renewals” for your registrar, to guarantee that users will always be able to renew, then you can call approve on the Name Wrapper and approve your registrar contract as the “subname renewal manager” for your name. Then, burn the CANNOT_APPROVE fuse on your name, to guarantee that you can never revoke that contract for subname renewals. See the Approved Operators section above for more info.

If you want to impose other restrictions on your registered subnames, then you can burn the CANNOT_UNWRAP fuse to Lock the subname, and also burn whatever other fuses you want.

For example, if you want to prevent owners of your subnames (like my.verypopularname.eth from creating their own subnames (like buy.my.verypopularname.eth), then you would burn CANNOT_UNWRAP and CANNOT_CREATE_SUBDOMAIN.

To recap on fuses…

• Sell permanent names:

  • CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL

• Sell permanent names, but prevent them from creating their own subnames:

  • CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_CREATE_SUBDOMAIN

• Rent out names:

  • PARENT_CANNOT_CONTROL

• Rent out names, but prevent them from transferring or reselling them:

  • PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_TRANSFER

And so on, it’s up to you. You can also burn whatever custom parent-controlled or owner-controlled fuses you want to.

Can I customize my own rules and fees?

Yes! It’s your registrar contract, so you can impose whatever rules and fees you want.

For example, the .eth Registrar imposes a 3-character minimum on all names, as well as a custom fee structure and a temporary premium auction upon expiration.

By default there is no character limit on subnames, but your contract could have its own rules and fee structure or whatever you want. For example, you can:

• Allow or disallow specific addresses from registering / renewing

• Only allow registration based on some custom criteria like holding a specific NFT

• Custom length restrictions like only 3+ characters or < 100 characters

• Only allow names with characters [a-z0-9] and nothing else

• Use a custom fee structure based on:

  • The length of the name

  • The specific characters that are in the name, like emojis

  • A pre-curated list of “good” names like people’s first names

• And whatever other rules you want.

But I can’t write my own contract!

If writing and deploying your own contract seems daunting, then don’t worry, the ENS Labs devs are working on some basic subname registrar contracts that anybody will be able to use.

I’m sure that the ENS community will create all kinds of other registrar contracts and tools you can use too!

3.) Other cool things you can do

Issue subdomains as tickets to an event

Maybe you have mycoolevent.eth and you want to issue tickets like 1.ticket.2023.mycoolevent.eth.

If you want, you can choose to not Emancipate those subnames, but still burn some custom parent-controlled fuses. Those fuses might:

• Indicate what “tier” their event ticket is

  • Maybe they can upgrade their ticket to a higher tier, which would burn some additional fuses

• Allow them access to the express line or some VIP room

  • Maybe even automatically via some smart door

When you burn those fuses, perhaps you also set the expiry to the day after the event ends.

Or, maybe you want your attendees to be able to keep their subnames as a souvenir or proof-of-attendance!

If so, then instead of letting the names expire at the end of the event, you could extend the expiry and burn some additional fuses to allow the attendees to keep them forever! In that case you might want to burn these fuses:

• CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL

If you want those tickets to be non-transferrable (soulbound to the address that attended), then burn these fuses:

• CAN_EXTEND_EXPIRY | PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_TRANSFER

Lock the resolved records for a name

By default, newly registered names will use the Public Resolver, which just allows the current manager/controller of the name to update any records.

However, in some cases perhaps you want to make sure that a name resolves to specific records and never changes. You can accomplish this with the CANNOT_SET_RESOLVER fuse.

Say you own mycoolcontract.eth representing a smart contract. You can use ENS subnames to refer to specific versions of that contract, like 1.mycoolcontract.eth. And perhaps you want those versioned subnames to always point to:

• The ETH address of that immutable contract

• The ABI for that contract

• The contenthash for some versioned documentation page

• etc.

One way to do this is just to make sure the name is Locked, all the records are set correctly, and then transfer the owner to some burn address so it can never be updated again.

But of course this isn't ideal, because maybe there are some records that you do want to update in the future. Or maybe you still want to keep ownership of that subname for other reasons.

Instead of essentially burning the name, you could create a custom resolver that locks in certain records forever. Then:

1. Set the resolver of that name to your custom contract

2. Set the records however you want and lock them into the resolver

3. Burn these fuses on the name:

   • PARENT_CANNOT_CONTROL | CANNOT_UNWRAP | CANNOT_SET_RESOLVER

Now you can still keep ownership and even some limited management power over the name, while still guaranteeing that the ETH address, ABI, and whatever other records are completely immutable, as long as the expiry is set appropriately.

Recap

The Name Wrapper takes control of your ENS name, and issues you an ERC-1155 NFT in return.

For .eth names, fuses can be used to apply perks or restrictions on subnames.

DNS names can be wrapped, but currently cannot use fuses. (See the DNS Domains and Fuses section for additional nuance.)

All .eth second-level names (like name.eth) are automatically placed into the Emancipated state when wrapped.

Emancipated means that the parent no longer has control over the child name. It can no longer burn any fuses or replace the subname, up until the expiry.

A name is Emancipated when the parent burns the “Parent Cannot Control” (PCC) fuse. The parent must first be in the Locked state to be able to do this.

Locked means that the name cannot be unwrapped. This provides assurance to subnames that the parent owner cannot unwrap and then, for example, start replacing subnames directly against the registry.

An Emancipated name is Locked when the “Cannot Unwrap” (CU) fuse is burned.

Think of the special PCC / CU fuses recursively:

• To burn owner-controlled or subname fuses, CU must be burned.

• To burn CU, PCC must be burned.

• Only the parent can burn PCC on the child name, and only if CU is first burned on the parent

• To burn CU on the parent, PCC must be burned on the parent

• Only the grandparent can burn PCC on the parent name, and only if CU is first burned on the grandparent

• And so on…

Follow that chain up until you hit a .eth second-level name like name.eth, since .eth second-level names will have PCC automatically burned when wrapping. The parent eth node is already in the Locked state.

A parent name can burn all the fuses it needs to on a child name in one transaction. This can be done when the subname is created, or on an existing subname that has not yet been Emancipated.

Finally, in order to use fuses, an expiry must also be set on the name. When the expiry is reached, all fuses are reset on the name. If the name is Emancipated or Locked, then in addition, when the expiry is reached, you lose ownership of the name.

Other Links

The actual contracts as well as technical documentation are here:

ens-contracts/contracts/wrapper at master · ensdomains/ens-contracts

The core contracts of the ENS protocol . Contribute to ensdomains/ens-contracts development by creating an account on GitHub.

https://github.com

We also have a section on the Name Wrapper in the support docs with much of this same information: Developer Basics - Name Wrapper Overview

As well as a how-to section for the new ENS Manager App: Support Docs - Name Wrapper How-Tos

There is also a useful third-party integration guide here: NameWrapper third party support guide

Also see all of our other technical docs at https://docs.ens.domains.

Why StarkNet?

Despite being in the Ethereum ecosystem, StarkNet is very unique. Most layer 2 chains are so-called “Ethereum Virtual Machine (EVM for short) compatible” where developers can use the same tools to develop smart contracts and end users can use the same wallet such as Metamask. Even though there are multiple projects to make StarkNet compatible with the EVM, they have their own unique programming language called Cairo. StarkNet also has so-called “account abstraction” built in that allows users to manage their wallets in more flexible ways. To use their system, you have to install special wallets such as Argent X and Braavos.

Before I came to the event, I have been thinking about why people build on StarkNet with all the extra work of learning new languages and getting used to new software. This trip was to find out the answer to this question. One of the key answers is “Zero Knowledge Proof”, which is lately the hottest topic within the Blockchain ecosystem.

matoken.eth

@makoto_inoue

Zk giga brains at #StarkWareSessions2023 @zksync @0xPolygon @aztecnetwork @Starknet

43

10:09 AM • Feb 5, 2023

Zero Knowledge proof (ZKP for short) is a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true.  Even though the primary use case of ZKP is for privacy, ZKP provides another trait called “Verifiable computation” that allows us to outsource computation to another entity while maintaining verifiable results. Verifiable computation is critical to improving processing speeds on blockchains without reducing security.

Because StarkNet is one of the first projects built on ZKP, it managed to attract lots of people interested in the topic into the ecosystem. In their “ZKVM OGs” session (ZKVM or ZKEVM is an attempt to convert ZK code into EVM), there were speakers from other chains such as Polygon, Aztec and ZKSync and that created the vibe of “Festival of all things ZKP”, rather than an event only focused on their own chain.

Many participants are very passionate about the technology around ZKP and StarkNet. Many people seem more interested in building “something cool and innovative” rather than building clones of something already built on Ethereum, even if it costs them to rebuild all the toolings from scratch. There are fewer speculators and more builders.  It reminded me of the passion and enthusiasm of 2016 when I first joined the Ethereum ecosystem.

ENS #FRENS

The majority of people in the event seemed already in the Ethereum ecosystem.

When I asked how many people have ENS names to the audience during my panel session, probably more than 80% of people raised their hands. I have been asking this since I joined the ENS team back in 2018 and that was one of the highest ratios.

matoken.eth

@makoto_inoue

#StarkWareSessions2023 show hands if you have @ensdomains names!

135

4:08 AM • Feb 6, 2023

Zero Knowledge is a very advanced topic even within the Ethereum ecosystem. I guess that people interested in such topics are fairly advanced users within the ecosystem hence the high ENS ownership rate.

I have been giving away my personal POAP event badges (with my jpeg drawings) using the ENS card we distributed at the last Devcon. 50 people collected my POAP during my visit to Tel Aviv, and 70% of the recipients set their primary names. Again it shows the high ENS and crypto literacy among the participants.

And yes, the ENS sticker was popular again among the participants.

ENS on StarkNet

When I spoke to dapps, wallets, and builders that we are working on ENS integration within StarkNet, many people welcomed the initiative and they said they would support ENS on their app.

As I explained earlier, StarkNet is built on its unique language called Cairo and ENS labs team members do not have expertise in building and maintaining the codebase. This is where the enthusiasm of the StarkNet community kicks in.

Nethermind is the creator of an Ethereum client software used by over 20% of validators but is also known for building the infrastructure in the StarkNet ecosystem such as Warp (Solidity to Cairo Transpiler) and Voyager (the StarkNet block explorer). They proposed to implement the CCIP-read (our offchain data retrieval framework) on StarkNet at the end of last year, and part of my visit to Tel Aviv was to meet the team to discuss the progress of the proposal which we also provided some grants.

A week leading up to the StarkWare Sessions summit, there was a hacker house near the Tel Aviv beach organized by “Only Dust” where people spent a week together to contribute to StarkNet ecosystem projects and get rewards from the prize pool.

Even though the beach looked amazing from the building, it was one of the windiest times of the year and it was almost impossible to even walk outside so participants couldn’t do much apart from hacking at the venue for the whole week.

Nethermind, ENS, and starknet.id (Name service on StarkNet) spent significant time at the hacker house discussing the details of how ENS can integrate with StarkNet. You may wonder why we are discussing with competing name service providers. Thanks to the flexible approach of CCIP-read, it is possible for StarNet to integrate with ENS so that matoken.stark on starknet.id can also become a subdomain in Ethereum as matoken.starknet.id

It is great that community members are actively contributing to the implementation of the standard to the point that they can give the master class on how CCIP-read works to the hacker house participants.

matoken.eth

@makoto_inoue

At @OnlyDust_xyz hacker house in Tel Aviv @mempoolsurfer from @nethermindeth giving the master class of @ensdomains CCIP-read and how to integrate into @Starknet

51

2:22 AM • Feb 4, 2023

On the second day of the hacker house, we had a workshop with partners who are interested in issuing subdomains on StarkNet with the implementation we are working on. You can read the full meeting notes here.

Talks and Panels

In addition to my talk “ENS on StarkNet” talk (slide), I was invited to two panes both focusing on Identity. The first panel (Identity and Social) was with other decentralised ID providers (Lens, Starknet.id) and Privacy solution provider (Sismo), while the second panel was with projects built on top of ENS (Nimi profile, Esteroid dweb search).

While both panels made some comparisons between web2 and web3 identities and agree that web3 can provide more transparency and interoperability, they also showed worries about privacy and how ZK technology would fit into the distributed identities. Both talks were recorded so hope the videos get published soon.

This is it from me. Many thanks to the StarkWare Sessions, BuildingBlocks, OnlyDust event organisers, all the people I met, and Eli Ben-Sasson and Uri Kolodny (the founders of StarkWare) for building such a fantastic technology and community.

matoken.eth

@makoto_inoue

#StarkWareSessions2023 had a pleasure of doodling @ukolodny and @EliBenSasson are @ensdomains #frENS moment

15

3:32 AM • Feb 5, 2023

We implemented and deployed mitigations for this in both the subgraph and the metadata API, paid lcfr a bounty, and closed the issue. However, in December 2022, the issue reocurred. The below is a postmortem describing the process issues that led to its reappearance, and describing how we will improve our process going forward to prevent this kind of reversion happening in future. We’re posting it as part of our commitment to transparency and process improvement. We’ve also awarded lcfr a further bounty of $20k for finding the reversion.

Topic: Null byte character bug

Reported date: 05.04.2022 / 10.01.2023

Summary

When an attacker creates a domain with null byte character added in front or back of the name, due to a known issue in The Graph, the attacker is able to impersonate any domain which is already registered by someone else. The issue, first reported around April 2022, we as ENSLabs took an immediate action to prevent it from happening. 9 months later the issue re-appeared.

Root cause

PostgreSQL does not store null characters in text columns. The Graph uses PostgreSQL, meaning that any text data saved in a subgraph would never include null characters.

Root cause for the re-appearance

After hotfixes, we haven’t followed up with persistent actions (as I know of) and the hotfix was never pushed into a repository. There was only a hot-fix shipment during the event, to prevent the issue happening till the permanent solution to be put in place. Later, during some other feature changes and refactors, patch was removed unintentionally on the metadata-service side.

The subgraph fix was never tested, and therefore was never confirmed as working. It assumed that the input label was already void of any null characters. However, event data in graph-node is stored as raw bytes in PostgreSQL. This meant that the label used for generating the comparison labelhash was yet to be stored in PostgreSQL, therefore still had null characters.

Fix hash check, add dot check · ensdomains/ens-subgraph@a7ec901

ENS data source for The Graph. Contribute to ensdomains/ens-subgraph development by creating an account on GitHub.

https://github.com

Resolution

In the first incident, as an immediate solution to the given problem we decided to make a hotfix on both metadata-service and our subgraph repositories (as I know). The solution was simply double checking if queried labelhash matches with the one provided by the subgraph.

In the second incident, we will be re-applying the same patches compatible with the current feature set in the metadata-service, will have necessary tests and descriptions, comments alongside the code. https://github.com/ensdomains/ens-metadata-service/pull/142

The fix for the subgraph is a different implementation, each label will be manually checked for null characters and disallowed if the label contains any. Alongside this, a unit test will be added to prevent regression.

Preventative Measures

Reporting and following persistent fix from the TheGraph side? Having a procedure for both temporary and permanent solutions?
Semi - automated deployment for metadata-service, all the code merged into master branch will trigger –no-traffic deployment then we will split the traffic later.

Impact

There are 14 incidents found, some were taken down by marketplaces after our fixes, the others taken down after we gather the full list.

Lessons Learned

After an immediate action, be sure persistent solutions are discussed and applied. Even though the hotfixes are temporary, provide necessary testing as soon as possible. Put clear description and comments alongside the hotfixes.

The queue lasted for 3 days and the wait time was over one hour at the busiest time. That was our ENS swag station where we gave away POAP cards to over 2000 Devcon participants in partnership with POAP and IYK. Many people have heard of POAP, Proof Of Attendance Protocol, and the badge NFT you can collect at events. The POAP team extended the idea to make it as a personal token where anyone can give away the “I met xxx” POAP if they have a special NFC card provided by IYK. Once you touch the card with your mobile phone, it will automatically pop up the POAP claim code. The concept already existed and you can purchase the POAP card at IYK site. The swag was to personalize the IYK card with your own ENS name and avatar record set on ENS.

The road to Devcon

When we announced the swag back in late September, we asked people to pre-register their names at http://swag.ens.domains/ by signing a signature that sends the redeemed QR code via email. We requested people to sign a signature via the address which has a primary name set to prevent people from claiming other people’s cards (such as vitalik.eth). We also asked people to pre-register because we expected that many people wouldn’t bring wallets to sign for security reasons.

In the end, over 5941 people registered for the card (of which over 800 people registered during the event).

We were aware that we don’t have enough cards for everyone, hence we printed the cards on the spot for people who pre-registered 24hrs in advance on day one, then allowed anyone who registered on days two and three. We had one special machine brought by nick.eth.

That beast had a printing speed of 180 cards per hour, so the actual printing rate was pretty close to the capacity. In the end, 1,912 cards were printed (we had a total supply of 2,000 but had some defects and duplicate prints).

The game is ON

Once printed, the participants started swapping each other’s cards and a total of 18,743 POAPs were collected by 2,197 people.

For those people who didn’t have an avatar set on ENS, we partnered with artist Zsolt Kosa, and created a series of generative art.

Historically, only 10% of ENS users set avatar text records. However, we had nearly half (47%) of the participants put avatars. Nearly half of the ENS card holders set their avatar after we announced so the swag card was a strong incentive for people to set the record.

The latest addition to the swag page was the leaderboard built by luc.computer throughout the EthBogota hackathon showing who collected the most POAP. Despite offering any prize, people loved the leaderboard!

The young gentleman proudly standing in front of the leaderboard with his dad is ethilio.eth. He is 7 years old, came in without an ENS name, and ended up meeting 340 attendees. 

You can see the interactive leaderboard here. luc.computer had an early lead but brantly.eth and eydrent.eth came very close to the point that they overtook him at some point. luc.computer and ethilio.eth had a “Batman and Robin” style partnership and were running around the venue together to retain the crown in the end.

There is another fun story to share. Towards the end of the swag booth, I was chatting with a pair of the conference facility staff and noticed that they also have their swag cards.

I asked them if they have been into crypto (hence have them) and their answer was no. Apparently, they came to our booth on the first day concerned that our queue may cause a security hazard but later came back asking for the card.

I have been to various Ethereum events since 2016 and have seen many crypto related event swags but it was always too difficult to onboard even people who are into crypto, let alone newbies on the spot. In the year 2022, we now have many mobile wallets to choose from and installing and setting up accounts seem doable. Converting fiat to crypto is still not the easiest hence we onboarded some people (26 people in precise) by gifting ENS names through ENS fairly bots created by our ENS DAO member gregskril.eth. At the end of Devcon, we received the “Trojan Unicorn Award” for bringing web3 and blockchain to the mainstream, without losing our core values. Unlike many speculative NFTs, ENS annual registration ($5/year) is cheap enough to gift and we think it’s the best first NFT for anyone new to crypto and Web3.

This was our first swag store attempt and we have already received many requests to deploy it in other events. Please let us know if there are ways to improve

Grab the data

This experiment also generated tons of interesting insights to write this post. There are some other interesting insights which I created on the following dashboard.

• Dune Dashboard = L1 onchain activity of the swag card registrant

• Flourish Story = for POAP claim network graph and the leaderboard

The data and scripts I used are open-sourced at https://github.com/makoto/ens-card-data . If you are a data whiz, please dive into the data and show us more interesting insights!

I have attended ETHcc every year since 2017 (when it was still called EDCON) and I am glad to be able to come back to Paris again with alisha.eth and lucemans.eth.

Here’s a recap of how ENS participated at Ethcc5 and Ethcc week in Paris.

ENS talk sessions

** **

I gave a quick recap of the growth ENS had over the last year as well as introduced our new features https://alpha.ens.domains site and an upcoming feature called NameWrapper — it turns any ENS subdomain into an NFT with a more flexible access control feature called a “fuse”. ** **

It was also great to showcase not only what our team worked on but also other sites our ecosystem members have built such as https://ethleaderboard.xyz and https://ens.vision . The full video and the slides are as follows.

• video

• slide

alisha.eth was also in town joining the DAO governance workshop hosted by Optimism.

** **

** **

L2

One thing I didn’t cover in my “State of ENS talk” is our plan for L2 integration. I actually gave a whole talk about our ENS L2 strategy last year (talk video). Our overall approach hasn’t changed since last year but we now have a complete specification and library support such as ethers.js  

I spent most of my time at ETHcc talking to various chain and bridge providers, exploring the possibilities of bringing the integrations to their chains. As our integration relies on roll-up mechanism of the L2 chains, it was great to see many zk rollup providers (zkSync, Polygon Hermez, Scroll) announce their own version of zkEVM, which was a hot topic during Ethcc. Here is my ETHcc5 watch list, all related to cross-chain bridge and interoperability (yes, I didn’t have time to attend all the talks because I was too busy meeting people). 

• Trustless bridges in the Ethereum Beaconverse = Gnosis trustless bridge

• State tree - Hermez zkEVM 

• Polygon-Hermez zkEVM BridgeL1-L2

• Beamer - an optimistic bridge 

• Optimism Bedrock: Upgraded optimistic rollups architecture

• Nicolas Laurent : The Soul of a New Machine: Next-Generation Optimistic Rollups with Cannon

• The Age of Rollups = Arbitrum

• Celestiums: Scaling Ethereum Rollups by using Celestia for Data Availability

• StarkNet - Next steps

One thing I was asked repeatedly is “which chain is ENS picking”. The short answer is “we don’t pick one, your Dapp/Wallet/Exchange does”.

This is the diagram I often show when I explain our architecture.** **

Our extensible ENS architecture allows each domain (eg: uniswap.eth, mirror.xyz) to select a “resolver” contract that can proxy their data access layer to the chain of their choice through so-called “gateway” service.  The ideal use case is a dapp/wallet/exchange for picking the chain they already support and issue subdomains on the chain, which anyone can look up through our CCIP Read framework. If you want ENS to be supported on your favourite chain, it is important to understand that we need to work on both the chain and dapps that live on the chain. If you know any dapps/wallets/exchanges which could potentially issue subdomains to their users, please do let us know so that we can work with them, alongside the chains they support.

IRL merch

Since EthBarcelona we bought a few small inkless printers and printed name tags with your .eth names and avatars to those who set the avatar text record. Even though many participants now have their own ENS name, it’s still a minority of people who actually know how to set up their PFP as an ENS avatar. However, many people came back to me the following day so I print name tags for them. Two people even set up an ENS avatar record in the middle of the side events (it was at a Wallet Connect side event so the ratio of participants who can interact with Ethereum from mobile was high).

For those of you who want to set the avatar text record can follow this guide%20Setting%20the%20Avatar%20record&text=Make%20sure%20you%20Connect%20with,ll%20fine%20the%20avatar%20record.&text=You%20can%20find%20all%20of,of%20your%20NFT%20on%20OpenSea.). Our ENS manager is still difficult to set NFT as an avatar text record. Our dev taytems.eth created a small utility site https://avatars.taytems.xyz/ to generate the text record for NFTs. 

If you missed us at Ethcc but want to have ENS name tag, you can go to https://ensdomains.github.io/ens-print and generate one on your own. The example below is how vitalik.eth looks and I managed to stick it into Vitalik himself right before his keynote.

** **

I was not the only one with ENS merch. Our ENS DAO delegate/steward avsa.eth brought tons of ENS badges and placed them everywhere possible, even on his own vest!

Hope you enjoyed the little tour of our ENS team activity at Ethcc5 in Paris. Some of our team members will be at other IRL events so make sure to set your avatar text record in advance to get your ENS sticker!

**

**

The next big milestones will be 1000 integrations and 1 million owners. I would like to address how we achieve that and what key metrics we should keep an eye on.

Names > Address > Primary Names

.eth  registration exploded when people started buying 3-5 digits names and the 10k Club was quickly formed.

This brought huge revenue to ENS DAO (we had $7 million .eth registration revenue in April, and already have over $5 million within the first week of May). The news about the 10k club was spread across CT and that also brought the number of unique participants (unique Ethereum addresses that hold ENS names) where it grew monthly new users from 33k to 41k.

However, the most important metric is the total number of primary names set and this number growth hasn’t shown as much increase as other metrics.

1.157 million names are owned by 407k addresses, meaning each address has an average of 2.8 ENS names, which seems fair (I also have matoken.eth and makoto.eth owned by 2 different addresses). Of the 407k addresses, 70% of addresses set a primary name which isn’t too bad either. It is likely that the real unique ENS users are still somewhere around 300k-400k.

The primary name is what allows ENS to be “Web 3 user name”.

By associating your ETH address to your ENS name, dapps and marketplaces can recognise your ENS user name.

I personally think that the primary name registration number is the real indicator of ENS as a web3 user name. The more people set their primary name, the more people see in various places and it has the maximum marketing effect as well. Our next release should allow users to set their primary name at the registration point so we hope the primary name number will go up faster.

Avatar record, decentralised web, and other cryptocurrencies

The original use case of ENS was to lookup Ethereum addresses and it still remains as the majority of use cases.

In comparison to ETH addresses which are automatically set at registration, the number of other record sets still has lots of space to grow. Avatar record in particular has grown a lot in April, almost similar growth ratio to the last November whereas decentralised web (aka Dweb) and other cryptocurrencies have decreased slightly.

Dweb provides decentralized hosting via IPFS and Avatar text record shows up on Dapps such as Uniswap to show the avatar record you associated with your ENS name set as your primary name.

Even though these new fields make your ENS names a lot more productive, the uptake number is still low. Part of the reason is that our current site is a bit difficult to set dweb address and avatar record. We are working hard for the new UI (you can see the preview version here) that makes setting more records easier.

Once the new version is released, I would like to see the Avatar fields to be set for more than 10% of all the addresses with primary names set.

The number of Integrations

The number of integrations.

Unlike the metrics I have already covered, the number of integration can only be tracked manually. We keep adding the integration partners to our website , but if you find any dapps not listed on the site, please contribute by raising PR like this.

If you notice that the site you use doesn’t support ENS, please pledge to the dapps!

There is also a discussion about creating an affiliate program targeted for content creators but the program can be also useful for Dapp integrations. It not only incentivise Dapps to integrate with us but also it will give good data insight about which projects bring more users to ENS (either offchain data like google analytics, or onchain data if we decide to handle it on chain).

The increase in the number of integration makes ENS names not only more useful but also gives natural exposure of ENS brand to the rest of the users who are new to Web3.

I can see the positive cycle that the increase of Primary Name & Avatar record leading to more Integration leading to more ENS user name registration.

Summary

Our 1M name registration brought large revenue and community awareness. To transition from the short term hype to the continuous growth, this is a great opportunity to improve other key metrics

• Unique owner names = from 400k to 1M (x2.5)

• Primary names = from 291k to 900K (x3)

• Avatar text record = from 18k to 180K (x10)

• Dapp integration = from 502 to 1000(x2)

The increase of the number in each metric will have a positive effect on other numbers and we need the support from ENS community to achieve the target

Here’s what you need to know.

ENS Token & Claim Site

The claim site is now open: claim.ens.domains.

The ENS token contract is token.ensdao.eth: 0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72

Double check the website URL and contract address to avoid scams.

Users have until May 4th, 2022 to claim their tokens, after which any remaining tokens will be sent to the DAO treasury.

The snapshot for all allocations - airdrop, contributors, Discord users, etc - took place on October 31, 2021. While we encourage you to continue to use ENS and participate in the community, nothing you do now will change your token allocation.

During the first week, anyone claiming their tokens will also vote on the proposed ENS Constitution, a set of rules for the DAO. If you wish to have a say on the Constitution, be sure to visit the claim site and cast your votes (which are off-chain and gasless) during the first week; you can still come back later and complete the process to claim your tokens (which requires gas) at any time before May 4, 2022.

Here is a YouTube video walking through the token claim app:

DAO Overview

The core components of ENS are decentralized and self-running (e.g., no one can take away another person’s .ETH name), but there are a few things that require some human discretion.

In its first act as a DAO, $ENS token holders will vote to formally request from the ENS root keyholders the ability to:

• govern protocol parameters, like pricing, the price oracle, and more

• control funds from the existing community treasury, as well as receive future revenue.

For more detail on the DAO, its goals, and the token distribution, see this earlier Mirror post.

Get Involved

If you’ve ever owned an ENS name, you’re eligible to receive $ENS governance tokens. Head over to claim.ens.domains to claim your tokens and vote on the ENS Constitution.

In the claim process, you will be encouraged to delegate your voting power to one of the delegates that have nominated themselves to help with ENS governance. If you don’t plan on being an active governance participant, this is a great way to ensure the protocol continues to grow and develop in the right direction.

There are many more ways to be involved in ENS governance other than being a delegate. To get more involved with ENS governance, join the ENS Discord and visit the ENS governance forum to weigh in on proposals or draft your own.

Let’s build the future of the Internet together.

This also applies to all the work we do, e.g. no one privy to insider information due to working for True Names LTD should be using it to give themselves an advantage with ENS names sales.

Several weeks ago, we worked with our lawyer to produce the ethics policy below.

We’re sharing it publicly to demonstrate our commitment to these principles. We encourage other blockchain projects to consider producing and publicly sharing similar statements.

Introduction

True Names Ltd (“Company”, “we”, “us”) is a non-profit company based in Singapore that leads and supports development and standardisation of the Ethereum Name Service project (“ENS”). Our donors, contributors and the Ethereum ecosystem as a whole trusts and relies on us to act responsibly and with integrity at all times. As such, the manner in which we conduct ourselves and deal with others will impact how well we build, retain and strengthen their trust. As contractors, volunteers, interns, consultants, and/or business partners (“you”, “your”, “yourself”) who work with us in any capacity, how you conduct yourself will similarly be a reflection on us as well.

It is our policy (“Policy”) to conduct all of our business in an honest and ethical manner. We take a zero-tolerance approach to exploitation or improper disclosure of confidential and proprietary information for personal gain and are committed to acting professionally, fairly and with integrity in all our business dealings and relationships.

Definitions

In this Policy, the following terms have the following meanings ascribed to them:

“Confidential Information” means any information and data of any kind that the Company designates as being confidential or which, under the circumstances surrounding disclosure, ought to be treated as confidential whether disclosed before, on or after the date of this Policy by the Company or any of its representatives, to you or any of your representatives.

“ENS Digital Assets” means any digital assets launched by the ENS Project or by projects in which the Company is involved, including (without limitation) ENS names.

“Inside Information” means any market-sensitive or material non-public information, which refers to any information not publicly available that a reasonable investor would consider in deciding whether to buy or sell ENS Digital Assets and may relate to the Company, the ENS Project, a partner, sponsor, donor, project, ENS names or digital assets.

Guidance on Confidential Information

Just to provide a few examples, Confidential Information includes the following:

• technology, information and/or personal data provided by the Company pertaining to the Company’s business, operations, processes, plans, projects or strategies;

• the Company’s trade secrets, market opportunities, negotiations, discussions, and contracts with other companies, customers or projects; and

• any information relating to or generated by the Company that is not publicly available through independent public sources (e.g. the newspaper, websites, social media pages).

Guidance on Inside Information

There is no bright line test for determining whether particular information is material or market-sensitive. Such a determination depends on the facts and circumstances of each case. If information could reasonably be expected to affect the price of the ENS Digital Assets, or would provide a buyer or seller of ENS Digital Assets with a material informational advantage in a decision to buy, sell or register any ENS Digital Assets, then such information should be considered material or market-sensitive. Importantly, whether such information is considered material or market-sensitive will be considered with the benefit of hindsight. Hence, if the price of the ENS Digital Asset changed as a result of such information have been made public, it will likely be considered material or market-sensitive by us.

Just to provide a few examples, the following information and matters should normally be regarded as material or market-sensitive:

• news about token sales, airdrops, token listings, forks, project launches;

• financial performance of the Company, or significant changes in financial performance or liquidity;

• strategic plans, business initiatives, potential mergers or acquisitions, new partnerships;

• new major contracts, orders, projects, suppliers, customers or finance sources or loss thereof;

• major discoveries or significant changes or developments in research or technologies;

• significant changes in senior management;

• actual or threatened major litigation, or resolution of such litigation; and

• contents of draft press releases and publications which may affect the market price of the ENS Digital Assets.

What is prohibited?

You may, during the course of your work, be aware of Inside Information and Confidential Information.

Confidentiality obligations

You must always:

• protect Confidential Information – even after your engagement, partnership, collaboration or work with the Company ends;

• keep electronic and paper documents and files containing Confidential Information in a safe place with access limited to only those who are authorised to peruse it;

• obtain appropriate approval from Confidential Information content owners and non-disclosure agreements from external parties before releasing Confidential Information to them;

• ensure that information received from third parties is from authorised sources and that information is used in accordance with specified conditions; and

• implement necessary safeguards to protect Confidential Information against risks of loss or destruction, or unauthorised access, use, modification or disclosure.

You must never:

• disclose Confidential Information to any third party unless you are authorised by us to share such Confidential Information with a specified third party for business reasons; or

• provide personal information to anyone without appropriate approval.

• General Prohibitions against insider trading, market misconduct and abuse of first-mover advantage

You must never:

• use Inside Information and/or Confidential Information for your personal gain or to cause detriment to others either directly or indirectly (including without limitation by way of information-advantaged decisions to register or purchase ENS names, or through family members, friends, associates or acquaintances);

• engage in activities to manipulate the price of Company-related Digital Assets;

• discuss or disclose any Inside Information and/or Confidential Information inside or outside your dealings with the Company other than in the proper course of business and as authorised as part of your regular duties for the Company;

• provide any Inside Information and/or Confidential Information to another person who may trade or advise others to trade on the basis of that Inside Information and/or Confidential Information; and/or

• make any recommendations or give trading advice of any kind to others to deal in ENS Digital Assets, where you are aware of Inside Information and/or Confidential Information.

If in doubt as to whether any course of action may be a breach of this Policy, please consult Nick Johnson or Brantly Millegan.

Breach of this Policy

The consequences of prohibited insider trading, market manipulation and breach of confidence can be severe. Even an appearance of a breach of this Policy can seriously damage our reputation. As such, we may terminate any contractual relationship with you without any compensation and without notice, in the event that we find that you are in breach of this Policy.

Persons found in violation of this Policy may also be required to disgorge the profit made or loss avoided by the trade of ENS Digital Assets, or purchase, registration or transfer of ENS names and compensate the Company for such related losses.

Here’s an overview of what we have planned.

ENS Token and DAO Overview

The core components of ENS are decentralized and self-running (e.g., no one can take away another person’s .ETH name), but there are a few things that require some human discretion.

During the first week of the claim process, community members will vote directly on a proposed ENS Constitution, a set of rules and guidelines for the community.

After that, and in its first act as a DAO, $ENS token holders will vote on a proposal to formally request from the root key holders the ability to:

• govern protocol parameters, like .ETH pricing, the price oracle, and more

• control funds from the existing community treasury, as well as receive future revenue.

Proposals will require the support of at least 100k tokens to go to a vote and a simple majority voting to approve with a quorum of at least 1% of all tokens.

Claims will open on November 8, 2021. Users will be encouraged to delegate their voting power to a community member that represents their views (call for delegates) and will have until May 4th, 2022 to claim their tokens, after which any remaining tokens will be sent to the DAO treasury. NOTE: The snapshot for the airdrop was taken October 31, 2021. Nothing you do after that date will change your airdrop amount or get you an airdrop if you don’t already have one.

We have established an organization called The ENS Foundation in the Cayman Islands to legally represent the DAO, e.g. fulfill any tax obligations. The foundation's articles of incorporation give token holders the right to appoint and dismiss directors, and to instruct the foundation to take real-world actions. More details are available here.

ENS Constitution

As part of the claim process, those claiming $ENS tokens will vote on a proposed ENS Constitution. The ENS Constitution is a set of rules and guidelines for the ENS community on how ENS should be governed. For an article to pass, it’ll need 67% approval of all votes cast in the first week of the token launch.

The Constitution can always be amended by the ENS DAO in the future with a threshold of 67% approval and a quorum of 5% of total tokens.

ENS Token Distribution

The contract address for $ENS is token.ensdao.eth (0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72).

There will be 100 million total $ENS tokens, and the distribution is as follows:

• 25% airdrop to .ETH holders (>137k accounts)

• 25% to ENS contributors (>100 individuals and groups, plus hundreds of Discord users)

• 50% to the DAO community treasury

Airdrop to users

The 25% of the total supply allocated for the $ENS airdrop to users will be distributed to all addresses that are or have been the registrant of a .ETH second-level domain. The distribution is based on the total time of an address's past registration and future registration as of October 31st, 2021.

The total time of future registrations is capped at 8 years. Importantly, the retroactive airdrop is per account, not per name. This means that each address is counted for a given day based on whether it owns at least one .ETH name on that day.

The airdrop also features a 2x multiplier for Ethereum accounts that have set their Primary ENS Name (formerly known as Reverse Record), since this is an indicator that someone is an active user.

The airdrop formula is roughly:

0.27 * (# days the account owned at least one ENS name)

+

0.062 * (# days until the expiration of the last name on the account)

The total is then multiplied by 2 if the account also has a Primary ENS Name set.

NOTE (Nov 7, 2021, 2:06pm EST): We tweaked the above formula due to a previous calculation error

We recognize that this will be disappointing to some users who only own subdomains or DNS domains imported to ENS. Given that the initial purpose of the DAO is to govern the parameters of the .ETH registrar, and determine how to allocate the funds collected by it, however, we determined it was fair to give users that have contributed to that system the power to affect its future.

Contributors

The 25% designated for contributors will be allocated to over 100 individuals and organizations that have contributed in significant ways to ENS over the last four years, including the core team at True Names LTD, external contributors, significant integrations, translators, root key holders, and more.

Tokens for core contributors and launch advisors will have a four year lock-up and vesting schedule.

There are no tokens allocated for investors, since there are none.

A portion of the contributors allocation has also been set aside for >450 active participants in the ENS Discord.

Community Treasury

The remaining 50% of $ENS tokens is allocated to the DAO. 10% of this allocation will be available to the DAO at launch, with the remaining unlocking over 4 years. This is in addition to the ENS treasury of funds raised from .ETH name registrations that the DAO is expected to receive from the ENS root multisig.

The DAO is encouraged to allocate these tokens towards community focused initiatives to help the development and growth of ENS, such as grants, hackathons, meetups and more.

Next Steps

We’ll be opening the token claim process on November 8. Keep an eye on the ENS Twitter account and here on Mirror for an update then!

ENS has always been an open public utility that belongs to the community. The core components of ENS are decentralized and self-running (e.g., no one can take away another person’s .ETH name), but there are a few things that require some human discretion. We believe that both ENS and the DAO space have matured enough that now is the time to pass ENS governance over to the community via the creation of a DAO and the $ENS governance token.

Specifically, we wish to have the ENS root multisig pass over control of the existing ENS treasury, its future funds, and control of the .ETH registrar contract that is in charge of the pricing and registration mechanism for .ETH names. The first order of business for the ENS DAO will be to formally request these from the ENS root multisig key holders.

Starting today, people may nominate themselves as ENS governance delegates. $ENS tokens will be opened for claiming a week from today (snapshot was made yesterday). Here is more information about the token distribution.

A Call for Delegates

We expect ENS governance will evolve over time. Learning from Gitcoin’s governance experience, we believe a delegate model is a good place to start. This helps the DAO represent the interests of members who can’t personally consider and vote on each proposal.

While anyone will be welcome to self-delegate and vote independently, we’ll be encouraging token holders to delegate to one of the community leaders who put themselves forward.

In order for this to happen, we need delegates!

We need individuals and groups who are dedicated to the growth and longevity of ENS. If you’re interested in taking an active role in ENS governance, now’s your chance.

If you’re an active member of the ENS ecosystem and want to help direct the future of ENS, follow this link and submit your application to be a delegate.

Time is of the essence: We plan to open the $ENS token claim process one week from today. More details about that will be available then.

Important note: You only need to submit yourself as a delegate if you want to appear in the list of delegates shown when other people claim their tokens. You do not need to submit a delegate profile if you only want to claim your airdrop, or if you only intend to delegate to yourself! There will be no POAP issued for delegates. And delegates are not awarded extra tokens for being delegates.

Best of luck to all delegate candidates.

Let’s build the future of the Internet together.