https://github.com/thenamespace/l2-subnames-poc
https://github.com/thenamespace/l2-subnames-poc
Last synced: 4 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/thenamespace/l2-subnames-poc
- Owner: thenamespace
- Created: 2024-06-25T06:03:07.000Z (almost 2 years ago)
- Default Branch: master
- Last Pushed: 2024-06-26T16:23:41.000Z (almost 2 years ago)
- Last Synced: 2024-06-26T22:42:37.300Z (almost 2 years ago)
- Language: TypeScript
- Size: 1.12 MB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# 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](https://eips.ethereum.org/EIPS/eip-712).
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
