Hello, Arti here from Namespace
With ENSv2 coming, one of our main milestones as a Service Provider is to make our subname issuing infrastructure compatible with it, right after launch.
As a first step, we developed a new onchain subname infrastructure based on ENSv2.
To test it, go to app.ens.dev, register a name.
Then go to demo.namespace.ninja to activate name and enable minting.
This demo lets you activate your ENS name (deploy a subregistry, grant permissions to our contract, configure the activation) and mint subnames under activated names, paying with ETH or stablecoins.
Loom video: Onchain Subnames with ENSv2 | Loom
How subnames worked so far
One of the first features of the Namespace platform was onchain subnames. An ENS name owner can “list/activate” their owned ENS name and allow others to mint subnames under it, with configurable pricing, deadlines, whitelists, reservations etc.
This feature depends on and is built around the NameWrapper, which never saw much popularity. The name owner has to wrap their name and burn fuses, and I personally feel that the NameWrapper just introduced technical debt for ENS rather than some real utility.
The initial onchain subnames feature was also only partly onchain. Our backend decided whether a user can mint or not, the whole listing config lived in our database, and to mint, the server had to provide signed parameters which the contract verified. That meant we as developers/maintainers could always update the activation of any ENS name, since we control the server and the data.
We went with this approach 3 years ago, because when we implemented the feature initially, gas prices on Mainnet were drastically higher than today and putting all the logic onchain was not practical for our ambitious set of features.
With ENSv2, that is changing.
How is it different now
-
It is based on ENSv2 registries. Every activated name gets its own subregistry, and no more wrapping names or burning fuses.
-
It is completely onchain and decentralized. Activation, pricing and minting all happen onchain, no more backend-signed parameters. A small server still exists, but only to store the Merkle tree leaves for whitelists and reservations. Only the root is onchain and every proof is verified against it, so we cannot tamper with the data: the worst the server can do is go offline and make names that use reservations and whitelist not mintable. In the future we plan to move the leaves data to IPFS.
-
Added new features aside from the existing ones
-
Multi token gates: minting can be gated on up to 5 different tokens (ERC20, ERC721, ERC1155) combined with AND/OR logic, previously only a single token gate was possible
-
Prices are in USD and minting works with ETH + stablecoins (previously ETH only)
-
Expirable or permanent subnames: rented per year with permissionless renewals, or minted once, forever
-
Permission control, the name owner decides the permissions of minted subnames (previously a fixed set of fuses)
-
Resolver control, the name owner picks the resolver subnames mint with (previously our public resolver)
-
Since ENSv2 is still in the development phase and the registry contracts get redeployed/changed frequently, we use the latest ENSv2 .eth registry on Sepolia, deployed at 0xBDC85dD5b15D7ecb354cd7cb6f2c50b4f2c4F0E2 (the same one app.ens.dev currently uses).
This is still work in progress
We have yet to do audits, the resolver handling is not final, and there will be more fixes and features based on feedback.
Feedback
Asking everyone to test it, ask questions, tell us what you like or what you don’t like, or special feature requests if you have any.