The ENS DAO proposal would stop new registrations on the old version and hand administrative powers to the DAO. Existing names could be renewed, but moving a name to v2 would be irreversible.
An October 11 proposal on the ENS DAO forum would move new .eth name registrations to ENSv2. Under the activation draft posted by nick.eth, the old version would close to new registrations while existing owners could choose when to migrate. The proposal remains a draft, with no confirmed activation date.
Ethereum Name Service provides readable names that can stand in for long blockchain addresses. ENSv2 would change the registration and permissions system on Ethereum mainnet. According to the draft, the new contracts have been deployed, but the registrar has not yet been authorised to register names.
A pause of a few hours for new registrations
The five-stage transition starts by reserving existing names for their current owners on the new system. After the transaction requiring DAO approval removes the old registration permissions, ENS Labs would run a final sync. Names registered or renewed since the initial preparation would then be added to the updated records. New registrations and the process of resolving names to addresses would open through ENSv2.
Neither version would accept new registrations during the final sync. ENS Labs expects a pause of a few hours, although no maintenance schedule has been announced. Only the second stage requires a DAO vote. At the final stage, ENS Labs commits to handing its remaining administrative powers to the DAO, removing its own access and publishing verifiable records of the transfers.
The draft contradicts itself on renewals. The activation section says unmigrated names can be renewed through the new renewer contract once the DAO transaction executes. The section for name owners says renewals will be unavailable until v2 goes live. Renewal access during the transition remains unresolved.
How existing names and their protection periods carry over
After ENSv2 goes live, names left on the old version would continue working with their existing records and could be renewed through a separate contract. Each renewal would also extend the name’s reservation for its owner on ENSv2. The proposal says, “There’s no deadline to migrate.” Owners would still need to track expiry dates and renew their names.
The official migration documentation explains that the 90-day grace period on v1 becomes 28 days on v2. The new expiry date gains 62 days to preserve the overall protection period. Its example uses a name with 100 days remaining: v1 makes it available again after 100 plus 90 days, while v2 protects it for 162 plus 28 days. Both calculations total 190 days.
Names already past their grace period would not be reserved for their former owners and could be registered by someone else on v2. For owners who migrate, the NFTs representing their old names would enter the Graveyard smart contract. The contract has no function to return those NFTs, making completed migrations irreversible. The DAO could reopen new registrations on v1 through a separate proposal, but that would not reverse an owner’s completed move.
Subname permissions separate as security fixes continue
ENSv2 would let each name use its own registry for subnames. An owner could allow a subname holder to change the address it resolves to without granting permission to transfer the name to someone else. The draft says locked permissions from the old system would carry over. Contracts receiving registration and renewal fees would belong to the DAO from deployment; ENS Labs’ administrative handover would leave the recipient of those fees unchanged.
According to ENS’s October 8 security update, 255 researchers submitted 787 reports during a four-week review. The 538 validated reports became 88 distinct findings after duplicates were removed, including 38 rated High or Critical. The review covered the ENS App, Explorer and supporting infrastructure. The reported counts therefore extend beyond mainnet contract vulnerabilities.
In the same thread, ENS said changes addressing 61 of the 81 engineering tickets opened from those findings had been shipped and merged into the main code branch. The team said on October 8 that work on the remaining fixes was continuing.
