Mentioned in This Article
1. What is the ENSv2 activation proposal?
ENS Labs, the developer behind the Ethereum Name Service, has asked the service's decentralized autonomous organization to activate ENSv2 on Ethereum mainnet. The proposal, published on the ENS governance forum on October 11, would stop new .eth registrations on the original v1 registrar and move them to the second-generation system. Sign-ups are expected to pause for a few hours before reopening on v2.
Holders of existing .eth names do not need to do anything. Their names keep resolving as before, and there is no deadline for moving them. A vote by the ENS DAO is still required before any of this can happen, and as of publication no voting date had been announced.
2. What is the Ethereum Name Service?
The Ethereum Name Service is a naming system built on the Ethereum blockchain. It lets users register human-readable names ending in .eth and link them to wallet addresses, websites and other data, so that a person can share a short name instead of a long string of letters and numbers. Each name is held as a token and is registered for a set period, after which it must be renewed.
The system is governed by the ENS DAO, a community of token holders who vote on changes to the protocol, its treasury and the contracts that run it. ENS Labs is the company that builds and maintains the software, but contract permissions on the live system are controlled by the DAO through a timelock, a mechanism that enforces a delay and requires approved actions to execute onchain.
ENS Labs first pitched ENSv2 in 2024 as a move to a layer 2 network. The new proposal states that the full set of v2 contracts is already deployed on Ethereum mainnet, so the current question is not whether to build the system but whether and how to switch it on.
Because names are tokens, they can be held, transferred and sold much like other digital assets. That is why changes to the registrar matter well beyond developers: anyone who owns a name, or who uses one to receive payments, depends on the contracts that define who controls it and when it expires.
3. What the executable would do
The proposal was posted by ENS founder Nick Johnson, who participates under the name nick.eth. It contains an executable, a bundle of instructions that the DAO's timelock would carry out if token holders approve it. In this case the bundle holds 15 calls combined into a single atomic transaction, meaning that either all of them succeed or none take effect.
The calls remove all five controllers that are currently authorized on the v1 BaseRegistrar, the contract that records .eth names. Two are then added back. The first is ETHRenewerV1, which handles renewals for names that have been reserved on v2. The second is a Graveyard contract, which can claim names that have expired beyond their grace period.
Ownership of the registrar would pass to ETHRenewerV1. According to the proposal, that contract cannot register names or add new controllers, so the effect is to freeze new registrations on v1 while leaving renewals and the claiming of long-expired names available through narrowly scoped contracts.
No voting date was given at publication, and no link to a Tally or Snapshot vote was included in the post. Those are the venues commonly used for DAO voting, so their absence indicates that the process is still at an early stage.
An atomic transaction is a safeguard in a change of this size. If one of the 15 calls failed halfway through, the registrar could be left in an inconsistent state, with some controllers removed and others still active. Bundling the calls means the system moves directly from its current configuration to the intended one, with no intermediate state that users or applications could encounter.
4. What happens to existing .eth names?
Owners of existing names face no required action. Their names keep working, and nobody has to migrate by a particular date. Those who want to move to v2 can do so through the ENS app whenever they choose.
There is one group for whom the outcome differs. Names that have already lapsed beyond their grace period will not carry over to v2. Instead, they will become available for anyone to register once v2 is live.
The proposal also changes how long a name stays recoverable after it expires. On v2, the post-expiry grace period is cut from 90 days to 28. To offset the shorter window, the v2 expiry date of each name is extended by 62 days, so holders do not lose time in the transition.
Between the moment the executable runs and the point at which v2 goes live, registrations stop on both versions. The post expects that gap to last a few hours.
The practical effect for most users is therefore limited. Someone who registered a name last year and renews it on schedule would continue to use it exactly as before, and would simply have the option of moving it to the new system later. The people who need to pay closest attention are those holding names that are close to or beyond expiry, since the rules for recovering them differ between the two versions.
5. How would activation work in five stages?
The plan is organized into five stages, and only one of them requires a DAO vote. That stage is the executable described above, which removes the v1 controllers and hands the registrar to the renewal contract.
The remaining steps are commitments from ENS Labs rather than onchain governance actions. After the freeze, Labs plans to re-run name reservations, open registration on v2, and route name lookups through v2 so that applications resolve names through the new system.
The final stage is the one with the most lasting effect on governance. ENS Labs would renounce its administrative roles over the v2 contracts and transfer them to the DAO timelock. According to the proposal, the DAO would then control v2 in the same way it controls v1, and Labs would hold no privileged role over the system.
Registration fees on v2 would be directed to the timelock, which has owned the fee contracts since they were deployed. In practice this means that revenue from new registrations would continue to flow to the DAO.
Separating the stages in this way keeps the binding part of the plan small. The DAO is asked to approve one transaction, and everything else is presented as a sequence of steps that Labs has said it will take, which the community can check against what actually happens onchain.
6. What are the tradeoffs?
The proposal acknowledges a cost. It removes an emergency path that exists on v1, under which a designated controller can disable a registrar controller without a vote. That kind of fast-response power is useful if a flaw is found, but it is also a form of centralized authority, and the change would eliminate it on the legacy system.
ENS Labs argues that the freeze on v1 is reversible, whereas migration of individual names is not. If the DAO later decided to restore the v1 controllers, it could do so through another executable. Tokens that owners have already moved to v2, however, cannot be returned to v1.
That asymmetry is the main reason the proposal separates the steps. The v1 freeze can be undone by governance, while a name's move to v2 depends on each owner's own decision, which is why no forced migration is attached to the plan.
Both sides of the tradeoff are visible in the proposal itself. The loss of the emergency controller path reduces the ability to react quickly on v1, but it also removes a lever that one party could use without a vote, which is consistent with the stated aim of putting the DAO in charge.
7. Why DAO control of the new contracts matters
Decentralized naming systems depend on the claim that no single company can seize, censor or alter the names people hold. That claim is only credible if the party that wrote the software does not retain special powers over it once it is live. The commitment to move all administrative roles over v2 to the DAO timelock addresses that point directly.
The structure also reflects a broader pattern in decentralized finance and infrastructure, where development teams launch a system under their own control and then hand authority to token holders in stages. The approach lets the team fix early problems quickly, but the handover is the step at which the project becomes accountable to its community.
For the ENS DAO, the vote will therefore combine a technical question, whether the executable does what it says, with a governance question about how much trust to place in the commitments Labs has made outside the onchain portion of the plan.
8. What happens next?
The next step is for the proposal to move into a formal DAO vote. At publication there was no scheduled date, and the forum post had not linked to a voting page. ENS community members can be expected to review the 15 calls, test the executable and discuss the tradeoffs on the forum before a ballot opens.
If the DAO approves the executable and the timelock carries it out, new .eth registrations will stop on v1 and pause for what ENS Labs expects to be a few hours before resuming on v2. Owners of existing names will see no change unless they choose to migrate.
If the vote fails or is delayed, v1 remains the active registrar and the live v2 contracts stay dormant. Either way, existing names are unaffected, which is the central assurance the proposal offers to the people who already hold them.
Readers following the ENS DAO should watch the governance forum for the posting of a formal voting page, any questions raised about the executable, and any changes Labs makes to the proposal in response. Those signals will indicate how soon the switch to ENSv2 could take place and whether the community considers the handover terms sufficient.