---
# System prepended metadata

title: A Glimpse into ENS's Exciting Journey to Layer 2

---

# **ENS & Layer 2's: Our Roadmap**

Hello frENS,

The Ethereum Name Service (ENS) has always been dedicated to enhancing the user experience on Ethereum, which is interchangeably referred to as Layer 1, L1, or Mainnet. Today, I am excited to announce and share the roadmap for ENS's expansion beyond Mainnet to Layer 2. This move significantly enhances both access and utility for ENS users. While it's a bit technical, I've done my best to explain it in simpler terms. We'll be sharing more in the coming weeks and months to make sure we're clarifying the content and answering any questions you may have.

## **Why Layer 2?**
With the evolution of [Ethereum's architectural roadmap](https://ethereum.org/en/roadmap/), there's a clear shift in the role of Ethereum Mainnet. It's gradually pivoting from its traditional transactional framework to assume a role as more of a foundational security layer. This transition promises to see a bulk of transaction activity migrating to Layer 2 solutions. L2s offer a way to process transactions at a much cheaper cost than Mainnet, while still ensuring the security and decentralization benefits of Ethereum. Given these advancements, integrating ENS into Layer 2 is not just an enhancement; it's a strategic imperative for Ethereum's future. 

Our transition to L2 will occur in four phases, each designed to build out the technical requirements of the transition while providing tangible benefits to users along the way. While in our phases we'll mention specific L2s for deployment our final solution will be L2-agnsostic, meaning that all L2s will eventually be supported. For those interested, you can review the full [L2 architecture proposal](https://gist.github.com/jefflau/7e9d303078891a969bfe70011e347bc0) on Github. 

## **Phase 1: Bringing Your Ethereum Mainnet ENS names to L2**

The initial phase focuses on developing a proof of concept that will allow you to "delegate" your names to L2. In this phase, the deployment will be restricted to the Optimism L2 network. By "delegate" we mean that the ownership of your names (TLDs & subnames) remain anchored on L1, but you'll be able to set and update your records from the Optimism network. This means that updating your ENS name's records will cost far less than transacting with higher gas costs on Ethereum Mainnet. This results in significant cost savings, usually just pennies on an L2.

**Here's How We'll Do That**
- **Optimism Resolver:** Our friends at [dm3](https://dm3.network/) are currently developing an Optimism Resolver which we'll leverage in our first step into L2.
- **CCIP Metadata:** We'll need to finalize and integrate our [CCIP metadata specification](https://github.com/ensdomains/docs/pull/142). These changes will allow a standard way to determine the owner of an offchain resolved name. 
    - `metadata` function returns name, coinType, graphqlUrl, storageType, context
    - `Offchain` schema is moved from L2 scheme to L1 scheme
    - `Offchain.id` is the address of the L1 resolver (no chain specific info so that non chain solutions can also save record updates without having chain id / cointype
    - Add `expiryDate` on L2 Domain schema
- **Testnet Demo:** We'll deploy application to testnet where you'll be able to see the following features in action:
    - List of L2 subnames
    - List of Custom Text Records
    - Switch Network between Mainnet and Optimism
    - Update Records from Optimism

Please note that your names cannot be tokenized or transferred on L2 at this point. You will only be able to use the above listed features as the owner of an ENS name on Mainnet. 

Target rollout: Mid-Q4.

## **Phase 2: The Reverse Registrar Replication**
In this phase we'll be focused on deploying our new [L2 Reverse Registrar](https://github.com/ensdomains/docs/pull/132/files#r1199191577) to both Optimism and Base. The new L2 reverse registrar, along with CCIP-Read will allow for L1 to read specific reverse registrar data. 

**Here's How We'll Do That**
- **L2 Replication:** We'll create a copy of the L1 registry and deploy it to the L2 networks.
- **Registrar Update:** Then, we'll modify the L1 reverse registrar to require all names to use a specified resolver. Additionally, we’ll add CCIP-Read to resolve L2 reverse nodes on L1. 
- **Platform Expansion:** Initial deployment to Optimism, with plans to expand across all L2 platforms.

Once this phase is completed, you'll be able to set a primary name on an L2! However it's worth mentioning that your primary name will need to be set per chain. For example, a primary name set on Optimism will only reflect for Optimism, and will not work for Arbitrum or any other L2. We are extremely excited to roll this out to everyone! 

Target Rollout: End of Q1, 2024.

## **Phase 3: Names Become Tokens**
In Phase 3, we plan to introduce tokenized and transferable names on L2 networks through “trusted issuers of domains”. Users will have to select their own trusted issuer and trust that they won't compromise their delegation on L1. As long as the L1 owner is not a malicious actor, then the tokens will remain sovereign on the L2 they've been delegated to. 

In simpler terms, each issuer (TLD owner) has their own token contract and each one issues tokenized NFTs (subnames).

*Note that the registry deployed in Phase 2 won't be utilized in Phase 3. This is because a name cannot simultaneously exist on L1 and be claimable on L2 until Phase 4 is completed.* *

***Here's How We'll Do That***
- **Tokenization:** The development of a new tokenization contract the controls the L2 resolver. 
- **L2 Resolver Update:** We'll need to make modifications to the new L2 resolver so that it can be controlled by the new tokenization contract. 

Anticipated launch: Late Q2, 2024.

## **Phase 3.5: Transition to Mainnet**
In this bonus phase we'll deploy Phases 1-3 from Testnet to Mainnet. We may decide to deploy a phase to mainnet ahead of the bonus phase, but at this point we'll make sure all previous work is live on mainnet. This will ensure ENS users get as much functionality up front as we can provide. 

Once Phases 1-3 have been deployed, we'll begin the 4th and final phase...

## **Phase 4. The Ultimate Connection: Linking L1 and L2 seamlessly!**

The final phase is significant in scope, so please bear this in mind when considering our proposed timeline for the target rollout. In this phase we'll be delivering full portabillity of an ENS name between L1 and L2. This bridge effectively tokenizes and enables the transfer of any ENS name by locking it on Ethereum Mainnet, making it portable to any other L2 network. 

***Here's How We'll Do That***
- **Deployments:** We'll need to deploy the following:
    - Canonical Registry
    - Canonical Registrar
    - L1 <-> L2 Bridging Mechanism
- **Data Migration:** Finally, we'll migrate all of the data from Phase 2 into the new Canonical Registry. 

Finally, your ENS name can be ported to and from any L2 network at your discretion, including the added ability to edit records and creation of subnames, all onchain! 

Completion target date: End of 2024.

## **In Closing**

Our shift to L2 represents a significant milestone and focus in direction for both ENS Labs and the wider ENS community. While we'll continue to investigate all avenues possible, it's important to note that at this time there is no plan to migrate .eth registrations to another L2. Thank you for reading through to the end, we welcome your thoughts and feedback so that together we can shape the future of ENS!