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 by user listing a name on Namespace platform.
Creating an L2 listing involves:
Storing the listing configuration on an offchain backend server
Deploying ERC721 Registry contract on selected L2 chain
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 rightful ENS name owner, before allowing it to list a name and deploy 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 a complex rules ( prices based on complex label rules, whitelisting, token gated access, name reservation etc). Whenever an address want to mint a subname, it will have to create a request towards an offchain server, the server will respond with a minting parameters and a signature. The signature is used so that smart contract can verify that minting parameters are coming from a valid source.
So the minting process consists of:
Request signed minting parameters from offchain server
Call the contracts with 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
As per mentioned ENSIP, the resolution always starts on the L1.
The client first calls the ENS registry to try to fetch a resolver address for a given name
If the Registry returns address(0) for a resolver, the client will strip the label from the left side and try again
If the proper registry is found, the client is going to call a "resolve" function
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
Last updated
