ENS contracts status update

We’ve been working on a number of improvements to some of the core ENS smart contracts, and I thought it’d be helpful to give a short update on them and their status here.

Name Wrapper

We’re working on a new contract called the ‘name wrapper’, intended to offer several new features. All wrapped names will be ERC1155 NFTs with native metadata. It’ll be possible to wrap a name at any level in the hierarchy, and wrapped names have a permissions model that allows the owner of the name to revoke permission over the name permanently. Permissions include:

  • Unwrapping the name
  • Creating subdomains
  • Replacing existing subdomains
  • Setting the resolver of a name
  • Transferring the name to another account

There are a number of use-cases for this functionality, but the primary one is easier trustless issuance of subdomains. A name owner can wrap the name, revoke their own ability to unwrap it or replace existing subdomains, then start issuing subdomains to people trustlessly. A variety of contracts can be used for the actual issuance, and the name owner can still transfer ownership or upgrade to a new contract without affecting existing registrations.

The wrapper has already been audited by chainsecurity and given a code review by Sam Sun.

Reverse Registrar

It’s been a very long time since we updated the reverse registrar. The new version includes several notable improvements:

  • Now emits events when reverse records are set or updated, so that offchain processes can log them correctly.
  • Now emits the address the reverse record is being set for and the resolver in an event, so offchain consumers don’t need a preimage database of Ethereum addresses.
  • Support for ‘controllers’ that are allowed to set reverse records (primary ENS names) on another address’s behalf. These can be authorised by the DAO and will initially include the new version of the ETH registrar controller (see below). This will permit registering and setting a reverse record in a single operation.
  • Support for the ‘owned’ standard for contract accounts. The owner of a contract account will be permitted to set the reverse record on its behalf.

The event changes in particular will make it possible for Etherscan to update their reverse resolution to be more standards-compliant.

The changes have been thoroughly reviewed but not audited.

ETH registrar controller

Numerous improvements are planned for the ETH registrar controller. These include:

  • Support for wrapping an ENS name at the time it’s registered.
  • Gas cost improvements that almost entirely offset the additional cost of wrapping a name.
  • Support for setting an account’s reverse record (primary ENS name) at the same time as registering, using the new reverse registrar.
  • Support for setting arbitrary records (not just ETH addr record) at the same time as registering.
  • Permits anyone to withdraw accumulated funds to the DAO account rather than requiring a DAO operation for this.

The changes for this contract are still a work in progress. Planned but not yet implemented is a change to the price oracle structure so that it can report separate values for name premium (for temporary premiums on recently expired name) and base registration fee so that these can be logged separately.

The plan once this is complete is to deploy and enable the new controller, but leave the existing one enabled for now; the two can run in parallel without any issues. This will be followed by a significant upgrade to the manager to allow the user to enter their ENS records while they wait for the first of the two registration transactions to complete.

Public Resolver

More modest changes are planned to the public resolver, to facilitate the changes above; the resolver will be deployed with a list of trusted contracts - the registrar controller and the reverse registrar - to allow those contracts to set records on a user’s behalf without requiring a separate approval transaction. These addresses will be immutable, so users can be assured a future contract upgrade cannot result in resetting their ENS records arbitrarily.

25 Likes

Why making it an ERC1155 token? NameWrapper contract allows to mint token only once, during wrapping, so the choice of ERC1155 is not clear.

Can we please know the broader context of NameWrapper? Will it be integrated in other parts of the ENS infrastructure? At this point, it looks like a permissions system for ENS domains. What really worries me is that, with the fuses system enforced, there will be no way to integrate an ENS domain owning contract with custom issuance logic into the ENS infrastructure.

ERC1155 tokens are significantly more gas-efficient than ERC721 tokens.

Registering and wrapping will be supported by the new version of the registrar controller, and anything that checks name ownership will be updated to be “wrapper aware”. Resolution is unaffected.

What did you have in mind as a potential problem?

What did you have in mind as a potential problem?

The scenario I have on my mind is when token holders are allowed to register a subdomain as long as they’re holding a token. When they sell their tokens, someone else might take their subdomain name. Such mechanism requires a smart contract with domain ownership transferred to it and that implements custom subdomain issuance/claiming logic. Will there be a conflict between the fuses system and such custom logic? Will it be required to wrap tokens to get some other benefits besides the fuses system?

You can still create a registrar that does this - just use unwrapped names, or wrapped names without the “can replace subdomains” fuse burned.

We don’t have any plans to deliberately “gate” features based on using wrapped names, but for some things they’ll be the best option.