L2 Subnames!

This repository contains a proof of concept code for issuing subnames on L2 chains. In a nutshell, every name has a separate NFT contract, deployed on an L2 chain. The minters can mint a subname via NameRegistryController contract.

NameFactory is responsible for allowing listing a name only to a lister who really owns a name on mainnet.

ENS Name Listing

The listing of an ENS name will allow the name to be used for minting of subnames. The initial step is to generate an EIP712 signature.

The signature type is defined as: "RegistryContext(string listingName,string symbol,string parentLabel,string baseUri,address owner,address resolver,uint8 parentControl,uint8 listingType)" The signature is generated using the private key of the verifier account, which is stored in the NameRegistryFactory contract.

The next step is to call the create(RegistryContext memory context, bytes memory verificationSignature) function of NameRegistryFactory, with the following paramaters:

• verificationSignature - the signature generated by the verifier private key
• context - registration parameters defined as:

struct RegistryContext {
    string listingName;
    string symbol;
    string parentLabel;
    string baseUri;
    address owner;
    address resolver;
    ParentControl parentControl;
    ListingType listingType;
}

enum ListingType {
    BASIC,
    EXPIRABLE
}

enum ParentControl {
    NO_CONTROL,
    CONTROLLABLE
}

There are two types of listings BASIC and EXPIRABLE. The BASIC listing creates a simple ERC721 token for the listed ENS Name, while the EXPIRABLE listing also creates ERC721 token, whose subnames will have an expiry.

Also, there is a level of control, with CONTROLLABLE listings allowing the parent to burn minted subnames, so that they can be minted again.

Once the create() function is called and verificationSignature is verified that it was generated by the verifier address, NameRegistryFactory will create a new ERC721 contract for the listed ENS name. The contract will then be used to mint subnames by assigning ERC721 token IDs to each subname.

ENS Subname Minting

Once the ENS name is listed, it can be used to mint subnames using the NameRegistryController contract. Similarly the minting process requires a signature generated of chain. The type of the signatrue is defined as: "MintContext(string label,string parentLabel,address resolver,address owner,uint256 price,uint256 fee,address paymentReceiver,uint256 expiry)" and it represents minting data.

Once the signature is generated the mint(MintContext memory context, bytes memory signature, bytes memory extraData) function of NameRegistryController can be called with the following parameters:

• signature - the generated MintContext signature
• extraData - data parameter set in the NameMinted event to track mints
• context - minting parameters defined as:

struct MintContext {
    address owner;
    string label;
    string parentLabel;
    address resolver;
    uint256 price;
    uint256 fee;
    address paymentReceiver;
    bytes[] resolverData;
    uint256 expiry;
}

Architectural overview

Resolution

The subs are resolvable by ccip-gateway, using the ccip-read protocol (until we get an emv-gateway running).

Minting

Setting Records