The technical barrier to issuing ENS subnames is lower than you might think, but your permission design determines whether you can change your mind later. If you just want to give out a batch of names to your own team or for an event, using an offchain approach costs almost nothing. If you want to sell or rent subnames to users long-term, you must handle NameWrapper's fuse mechanism carefully. Burning PARENT_CANNOT_CONTROL means you permanently give up control over those subnames. Burning CANNOT_TRANSFER means users receive a non-transferable soulbound name. Choose the wrong fuse, and your operating cost is not in gas fees but in the fact that mistakes cannot be fixed afterward.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
First choose an issuance method: L1, L2, or offchain
The official ENS documentation divides subnames into three categories. The choice depends on how you balance control and cost.
L1 onchain subnames are the most direct option. You own myname.eth, create subnames in the ENS Manager, or deploy a registrar contract so users can register by themselves. Each subname is an onchain NFT fully controlled by you or the user. The downside is that every creation requires Ethereum mainnet gas, so costs rise quickly for bulk issuance. This suits scenarios with small issuance volume and a need for native Ethereum ownership.
L2 subnames move registration logic to L2 while L1 keeps only the resolution entry point. Durin is a set of solutions recommended by ENS. It helps you handle the wiring between the L1 resolver and the offchain gateway, so you only need to write business logic on L2. Costs are much lower than L1, and users still receive onchain NFTs. This suits scenarios where you have a clear issuance volume and want users to truly own their subnames.
Offchain subnames are stored in a centralized database and resolved through CCIP Read. Issuance costs almost zero gas, bulk creation can happen instantly, and management is just calling a REST API. Coinbase's cb.id and Uniswap's uni.eth both use this model. The trade-off is that control stays in your hands: you can modify or revoke subnames, and users do not receive an onchain asset. They receive your service promise. This suits large-scale airdrops, event tickets, or in-app usernames where users do not need long-term ownership.
My view is this: if you are building a product where users will use the name long-term to receive payments or show identity, choose L2 or L1. If it is just a one-time identifier for an event or onboarding, offchain is enough. There is no need to spend extra money just for the word "decentralization."
Permissions: once a fuse is burned, it cannot come back, so think carefully first
NameWrapper turns ENS names into ERC-1155 NFTs and uses fuses to control permissions. Once a fuse is burned, it cannot be undone before the name expires. When issuing subnames, as the parent name owner you decide which fuses to burn in the subname creation transaction.
The most important fuse is PARENT_CANNOT_CONTROL (PCC). Burn it and the subname enters the Emancipated state: you can no longer replace it, delete it, or burn more fuses on it. The user truly owns the subname until it expires. If you do not burn PCC, you keep final control over the subname and can take it back at any time, but that means users cannot trust that the subname will always belong to them. The official ENS documentation describes burning PCC as the way to make a subname "unruggable."
CANNOT_TRANSFER determines whether a subname can be resold. Burn it and the subname is bound to the receiving address and cannot be transferred. Use this for event tickets or soulbound credentials. Do not burn it, and users can sell it on NFT marketplaces.
CAN_EXTEND_EXPIRY allows the subname holder to renew it themselves. If you issue "permanent" subnames by setting the expiry to the parent name's expiry, but you want to give users the ability to renew on their own, burn this fuse. If you want renewal to remain fully under your control, do not burn it.
There is also a precondition that is often ignored: to burn any fuse, the parent name must first be Locked, which means burning CANNOT_UNWRAP. Locked means you can no longer unwrap the parent name. If you may need to take myname.eth out of NameWrapper in the future, do not burn fuses and issue subnames now. This decision must be made before issuance. It cannot be changed afterward.
Resolution: after a user enters a subname, how does the wallet find the address
After a subname is created, it still needs a resolver to resolve addresses, avatars, and social records. L1 subnames use the Public Resolver by default, and you can set records during or after creation. L2 and offchain subnames rely on CCIP Read (EIP-3668): the client queries the L1 resolver, the resolver throws an OffchainLookup error telling the client which gateway to fetch data from, the client gets signed data back from the gateway, calls the resolver again to verify it, and finally receives the resolution result.
This process is transparent to users and most dApps, but you need to maintain a gateway service. For L2 solutions, the gateway reads data from L2. For offchain solutions, the gateway reads data from your database and signs it. If the gateway goes down, subnames cannot be resolved. Users' wallets will show "unable to resolve" rather than showing a wrong address. This is the main usability risk of offchain solutions: it is not asset loss, but temporary name failure.
Operating costs: not just gas
Onchain gas: issuing each subname on L1 requires mainnet gas. Bulk issuance can be optimized with batch contracts, but per-transaction costs still exist. Onchain costs for L2 and offchain issuance are close to zero.
Gateway operations: CCIP Read requires an always-online HTTP endpoint. If you use a service provider like Namespace, they host the gateway and you pay a subscription or usage-based fee. If you build it yourself, you need servers, monitoring, and signing key management.
Parent name renewal: all subnames depend on the validity of the parent name myname.eth. If the parent name expires, all subnames become invalid. This is a fixed annual cost, not a one-time investment.
The hidden cost of permission management: if you do not burn PCC, users cannot verify that you will not take back their names. In scenarios that require trust, this uncertainty lowers the value of the subname. If you burn PCC, you lose the ability to correct subname abuse. For example, if someone registers an offensive label, you cannot delete it. The official ENS documentation recommends that operators do label review and reservation for offchain issuance, but onchain Emancipated subnames cannot do this.
Completion standard
The standard is not "the subname was created successfully." It is: an external user or wallet, without relying on your frontend, can enter the subname and resolve the address you set; if you promised user ownership, the subname's state in NameWrapper is Emancipated and cannot be revoked by the parent name; and the parent name's expiry covers the usage period you promised for the subname. If you issue offchain subnames, the completion standard also includes: the gateway stays online without your active intervention, and resolution latency is within an acceptable range. First run one test subname through the full process from creation to resolution in a third-party wallet, then issue in bulk.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
