Namespace L2 Subnames
Last updated
Last updated
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.
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
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:
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:
Request signed minting parameters from offchain server
Call the contracts with the provided parameters and mint a subname
High-level overview:
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
