Namespace L2 Subnames

This page describes the process of how l2 listing and subname minting works.

The whole process is separated between offchain servers and smart contracts which are deployed on multiple chains.

Everything starts with the user listing a name on the Namespace platform.

Listing an ENS Name

Creating an L2 listing involves:

1. Storing the listing configuration on an offchain backend server

2. Deploying ERC721 Registry contract on selected L2 chain

3. Updating listed ENS name on L1 with a special offchain resolver contract

1. Listing an ENS name

The offchain backend server controls which wallet is allowed to list ENS name, so whenever a user wants to list his ENS name, he/she will need to sign a message proving the ownership of an address. Using this information, the backend checks if the wallet address is the rightful ENS name owner, before allowing it to list a name and deploy the ERC721 registry contract for a given ENS name.

High-level overview:

2. Minting L2 Subname

Subname minting process is controlled by an Offchain server. Since the listing configuration has complex rules ( prices based on complex label rules, whitelisting, token-gated access, name reservation, etc), whenever an address wants to mint a subname, it will have to create a request towards an offchain server, the server will respond with minting parameters and a signature. The signature is used so that the smart contract can verify that minting parameters are coming from a valid source.

So the minting process consists of:

1. Request signed minting parameters from offchain server

2. Call the contracts with the provided parameters and mint a subname

High-level overview:

3. Subname resolution

All the minted subnames, even tho they do not come from an official ENS contracts, are resolvable to all the clients that support Wildcard resolution ( wallets, daps etc. ). This is achieved using ENSIP-10 Wildcard resolution and CCIP read protocol

ENSIP-10: Wildcard Resolution | ENS Docs

As per mentioned ENSIP, the resolution always starts on the L1.

1. The client first calls the ENS registry to try to fetch a resolver address for a given name

2. If the Registry returns address(0) for a resolver, the client will strip the label from the left side and try again

3. If the proper registry is found, the client is going to call a "resolve" function

4. Since the OffchainResolver contract uses CCIP-Read protocol the function call will revert with OffchainLookup, pointing client to a gateway which will return the proper data

https://eips.ethereum.org/EIPS/eip-3668