Last week, we announced the hardhat-enscribe plugin for smart contract developers to name their contracts. We showed how smart contract developers can name their contracts with hardhat:

• Using a CLI command, powered by the hardhat-enscribe plugin, that can be executed after the deployment command
• Using the enscribe library in the hardhat deployment script

Under the hood, the hardhat-enscribe plugin uses the same @enscribe/enscribe library. It is a small TypeScript library you can use in any app or tool.

In this post, we will take a look at how to use the library to name your smart contracts in your apps.

It is very simple to use. From its public API, a single abstraction function creates the subname, sets forward and reverse records, and returns useful metadata (tx hashes, detected contract type, explorer link).

Using the Library​

Start by installing the library:

pnpm install @enscribe/enscribe  

Once installed, import the nameContract function:

import { nameContract } from "@enscribe/enscribe";

The nameContract function itself has a simple interface. It accepts the following parameters:

• Contract name
• Contract address
• Wallet client (from viem or wagmi)
• Name of the chain on which the contract address is
• Optional flag for logging naming metrics

We now create a wallet client object with wagmi:

import useWalletClient from ‘wagmi’
…
const { data: walletClient } = useWalletClient()

Once we have the wallet client created, we are ready to name our contract with nameContract:

const res = await nameContract({
  name: "vault.myapp.eth",
  contractAddress: "0x…",
  walletClient,
  chainName: "sepolia",
  enableMetrics: true
});

That’s it! With this single function, developers can easily set a name to their contracts without having to worry about sending individual transactions like creation of subname and setting resolutions.

However, the library is also flexible in leaking this abstraction (which isn’t a bad thing always 🙂) by exposing the following functions and use them however you want:

• createSubname
• setForwardResolution
• setReverseResolution

We want to make it easier for developers to name their contracts during contract deployment time and this is where the library comes in – they can integrate it in their Hardhat scripts. But they can also name their contracts after the contract is deployed with the hardhat-enscribe plugin. You can head over to the library documentation to explore the API.

Get started​

• Hardhat plugin: install, configure, and run npm hardhat enscribe name ... to label new or existing deployments. (GitHub)
• Core library: import @enscribe/enscribe and call nameContract() wherever you manage contracts (GitHub)
• Docs & guides: quick starts, concepts, and best practices for contract naming and multi-chain resolution. (enscribe.xyz)

Happy naming! 🚀

Adding support for contract naming into dev workflows has always been our top priority. Hardhat is a leading Ethereum developer environment. It’s TypeScript-first, fast, and built around a clean plugin architecture. Hence, it’s the perfect tool for contract management like deployment, testing, etc. We are excited to announce a plugin for the popular Hardhat ecosystem that adds contract naming to it.

Naming your contract from the CLI​

hardhat-enscribe is a Hardhat v3 plugin that assigns ENS names to contracts, handling the full flow for you:

• subname creation
• forward resolution and
• reverse resolution

It auto-detects common patterns like Ownable and ReverseClaimer, waits for confirmations, and plugs neatly into a viem-powered stack. It can be installed using the following command:

pnpm install @enscribe/hardhat-enscribe  

Let’s create new Hardhat project to deploy a contract on Sepolia:

mkdir hardhat-example
cd hardhat-example
pnpm dlx hardhat --init

This will generate a skeletal Hardhat project with a sample contract with the following project structure –

hardhat.config.ts
contracts
├── Counter.sol
└── Counter.t.sol
test
└── Counter.ts
ignition
└── modules
    └── Counter.ts
scripts
└── send-op-tx.ts

We can build our project with the following command:

npx hardhat build

Let’s now deploy our contract on Sepolia. For this, we’ll need to add configuration to interact with Sepolia. First, let’s export some env variables for the RPC URL and the private key of the account that we want to use to deploy the contract:

export SEPOLIA_RPC_URL=<sepolia rpc url>
export SEPOLIA_PRIVATE_KEY=<your sepolia account private key>
npx hardhat keystore set SEPOLIA_RPC_URL
npx hardhat keystore set SEPOLIA_PRIVATE_KEY

Now open the hardhat.config.ts file and add configuration for sepolia –

const config: HardhatUserConfig = {
  …
  networks: {
    sepolia: {
      type: "http",
      chainType: "l1",
      url: configVariable("SEPOLIA_RPC_URL"),
      accounts: [configVariable("SEPOLIA_PRIVATE_KEY")],
    },
  },
}

Our sample contract Counter.sol can now be deployed on sepolia with:

npx hardhat ignition --network sepolia deploy ignition/modules/Counter.ts

Once deployed, we are now ready to name our deployed contract. We need to add the hardhat-enscribe plugin to the list of plugins first. Open the hardhat.config.ts file and add the plugin:

import hardhatEnscribePlugin from "@enscribe/hardhat-enscribe";
…
const config: HardhatUserConfig = {
  plugins: [hardhatToolboxViemPlugin, hardhatEnscribePlugin],
  …
}

Then, invoke the plugin by passing the name and contract address in the command:

pnpm hardhat enscribe name mycontract.app.eth --contract 0x1234...abcd

This is what you’ll see in the output –

normalized name is mycontract.app.eth

Naming completed successfully!
Contract Type: ReverseClaimer
Transactions: {
  subname: '0xb5a4131bb0bf3c2708a8181349998f57c76226559042cf68423aeefc74e8cd55',
  forwardResolution: '0xa6aa6ac9a0857aaeaff1ef3d69b2962ab01650230bc5c9d8d3108dcfb63cebfa',
  reverseResolution: '0xb1f260a587f793251804b6f809b4d1546d81dd98c1605c5eb7d812d1afc190b9'
}

Naming your contract from a Hardhat deployment script​

You aren’t limited to setting a name for a contract from the CLI though. Scripting is a very powerful feature of Hardhat that allows you to do more than just contract development. You can call APIs, interact with contracts and even interact with the blockchain. You can now name your contract from a script too and we shall now see how you can do that.

First, connect to the network and deploy the CounterModule:

import hre from "hardhat";
import CounterModule from "../ignition/modules/Counter.js";


const connection = await hre.network.connect();
const { counter } = await connection.ignition.deploy(CounterModule);

Next, get the walletClient –

 const [walletClient] = await connection.viem.getWalletClients();
 console.log(`Using account: ${walletClient.account?.address}`);

Now create a normalized name –

 const ensName = `wpsqhsld.abhi.eth`;
 const normalizedName = normalize(ensName);

We are now ready to set the name by using the enscribe library (more about this in the next blog) –

import { nameContract } from "@enscribe/enscribe";
…

try {
   const result = await nameContract({
     name: normalizedName,
     contractAddress: counter.address,
     walletClient: walletClient,
     chainName: networkName,
     opType: "ignition-deploy-and-name",
     enableMetrics: true,
   });
  …
} catch (error) {
  …
}

That’s it! Your contract can be deployed and named with a Hardhat script easily. You can see the full example here.

Parting Thoughts​

Our focus will always be on improving developer workflows for contract naming and the hardhat-enscribe is an important integration for us.

We are continuing to focus on different ways to make contract naming better for developers. So go ahead and integrate contract naming today in your workflows!

Happy naming! 🚀

Vitalik Buterin recently published an essay on low-risk DeFi, arguing that Ethereum’s long-term strength won’t come from chasing the highest yields or the flashiest innovations. Instead, it will come from protocols that are boring, safe, and dependable, akin to how Google’s simple search box became the foundation of the modern web.

The core idea is straightforward: the future of DeFi depends not on yield farming and perps trading, but on building resilient, accessible financial tools that normal people can actually trust.

At Enscribe, we couldn’t agree more.

Why Low-Risk DeFi Matters​

Most of DeFi today is still intimidating and opaque. Users are faced with hex contract addresses, complex front-ends, and endless warnings about scams or unaudited code. The reality is that even experienced developers struggle to keep track of what’s safe and what isn’t.

This is precisely the problem Vitalik is highlighting. Just as search unlocked the web by making it human-navigable, we need infrastructure that makes DeFi human-readable and transparent. Without it, only degens and developers will ever feel confident participating.

Names Over Hex​

This is why we created Enscribe.

Instead of interacting with 0x5c63…ef7a or some random string of characters, users should see names like the following when they use Uniswap or Aave:

• router.uniswap.eth
• eth-staking.aave.eth

Names build trust. They create clarity that hex addresses cannot. A simple ENS-based naming layer makes it obvious what you’re interacting with, reducing the cognitive load and risk of mistakes for users.

When contracts are named, the experience of DeFi starts, users begin to feel they have greater agency over what they’re doing and

Aligning With Vitalik’s Vision​

In response to our post on this very idea, Vitalik added an important companion point:

https://x.com/VitalikButerin/status/1970820664853741959

“This, and use fixed html page UIs on IPFS with onchain version control.”

That’s the other half of the equation. If contracts have an identity and aren’t simply hex addresses, we start building a DeFi ecosystem where trust can be earned through simplicity and durability.

Low-risk DeFi is about eliminating uncertainty at every layer:

• Names instead of hex addresses.
• Fixed, verifiable front-ends instead of mutable websites.
• Contracts with clear provenance and open verification.

Put together, this isn’t just “lower risk.” It’s a pathway to mainstream adoption.

The Road Ahead​

Enscribe isn’t about creating yet another shiny DeFi product. It’s about providing the naming and verification layer that lets the entire ecosystem evolve into something usable and trustworthy.

Imagine a future where:

• Every DeFi protocol publishes named, verified contracts.
• UIs are simple, consistent, and immutable.
• Audits and provenance records are tied to contract names.

That’s the infrastructure Ethereum needs to onboard not just the next million, but the next hundred million users.

Vitalik’s essay was a reminder that chasing complexity isn’t the winning strategy. The winners will be the builders who make DeFi boring, reliable, and safe.

At Enscribe, we’re betting that naming is a critical step in that journey.

Happy naming! 🚀

As part of our mission to fix Ethereum UX, educating users on everything to do with naming smart contracts and ENS is a key part of this.

While we have a lot of technical documentation on our site, what's been missing is guides that tie together the content in an easy to follow manner. We're launching a new Guides section to help developers deploy and name smart contracts with Enscribe on L1 and L2 networks. Think of it as a hands-on companion to our technical documentation.

What's New​

The Guides section focuses on practical tutorials you can follow along. While our documentation covers technical details, these guides walk you through real workflows step by step.

The new Guides section

What You'll Find​

Quick Start Guides​

We organized the most common use cases:

• Deploy & Name New Contract — Deploy fresh smart contracts with ENS naming during deployment
• Name Existing Contract — Add ENS names to contracts that are already deployed
• L2 Contract Naming — Name contracts on Layer 2 networks

Conceptual Guides​

For developers who want to understand the underlying concepts:

• ENS Primary Names Explained — Forward vs. reverse resolution
• L2 Primary Names Explained — Cross-chain ENS identity

We will be expanding the guides and add more real world examples and use cases shortly.

Share Your Feedback​

What guides would help your development workflow? Join our Discord, Telegram, or X to share ideas and connect with other developers using Enscribe.

Visit the Guides section to start naming your smart contracts.

Happy naming! 🚀

Historically the Enscribe App only supported creating subnames for naming smart contracts. This has changed with our latest release!

We recognise that some people may want to name their contracts directly with a 2LD such as mymultisig.eth or use a subname they have already created such as treasury.mytoken.eth.

We’re excited to introduce a revamped naming UX, where we’ve not only simplified the naming experience further for users, but now provide a second option when naming your contract via the Use Existing Name button.

This required us to think over the current naming flow and so we redesigned our Name Contract page all the while still keeping everything simple.

Creating a New Subname​

We now have a button called Create Subname that lets you create a new subname. We show the same UI elements as before but with a few changes. We’ve simplified selecting a parent domain by replacing the Parent Name drop-down with a text field instead.

We’ve added a Select Domain button that lets you select either one of your existing domains or the one provided by Enscribe –

You can also create a new domain using the ENS app by clicking on the Purchase New Domain button. Clicking on this button will show a dialog that will confirm if you want to go to the ENS app.

Using an Existing Name​

When you click on the Use Existing Name button, we show a Contract Name text field alongside the Select Name button to select one of the several names you already own.

Clicking on this button will show a dialog showing your names that can be selected.

When you select one of these names, it will be chosen as the name you want to set to your contract.

You can also enter an existing name in the text field.

This way, you don’t have to mint a new subname (and save gas!) and simply pick whichever name you would love to set for your contract

Simplifying Naming​

With the ability to use an existing name, we’ve cut down the effort it takes to name a contract when you already own a primary ENS name.

Our goal is for every contract on Ethereum to be named. Adding an option to use an existing name simplifies the naming process, giving users the choice to either create a new subname or simply use an existing name

It’s one more step in our broader mission to retire hex addresses for good from the Ethereum UX.

Head to Enscribe App and try to name your contract with an existing name.

Happy Naming! 🚀

The Enscribe team believes in the importance of having metrics to track our progress against our mission — eliminating hex contract addresses for users and making Ethereum safer. Ethereum Name Service (ENS) is central to this vision, but despite ENS adoption growing steadily, the gap between deployed contracts and named contracts remains significant.

That’s why we built a Dune Analytics dashboard to understand where ENS naming adoption for contracts stands today.

Unpacking the Dashboard​

Our dashboard provides a number of key charts, these are outlined below.

• Total Number of Named Contracts shows a count of how many contracts have primary ENS names

• Total Number of Contracts That Can Be Named (ERC-173/ERC-5133) shows how many contracts deployed on Ethereum can be set a primary name. These include ERC-173 and ERC-5133 contracts

• Monthly Contract Naming Activity shows contract naming activity since the last 4 years

• Contract Names Set in Past 12 Months reveals how many contracts have been assigned a primary ENS name in the past 12 months

• Most Recently Named Contracts shows the latest 1000 contracts with their primary ENS names sorted by date

Making Hex a Relic of the Past​

By tracking these metrics, we directly measure the impact of our efforts at Enscribe. We want to see the number of named contracts on Ethereum increase, with a view to ultimately eliminating hex contract addresses for users.

Millions of contracts are still unnamed, and each one represents an opportunity to make Ethereum more user-friendly and safer.

Join us in shaping a more human-readable Ethereum. Head over to Enscribe and start naming your contracts today, then check the impact of your activity in our Dune dashboard.

Happy naming! 🚀

Smart contracts power the onchain economy, but they lack proper identity infrastructure. When users encounter a contract address like 0x742d35cc567890c000c000c07c81c25d7df34793, they can't easily verify what it does, who built it, or whether it's safe to use.

Enscribe has been working to solve this through contract naming. Now we're taking the next step by proposing a new ENS Improvement Proposal that establishes a comprehensive metadata standard for smart contracts.

The Problem with Contract Identity​

Smart contracts face several identity challenges:

• Trust Issues: Users can't easily verify if a contract is legitimate or malicious
• Missing Documentation: No standard way to find a contract's docs, source code, or audit reports
• Inconsistent Information: Wallets and dApps show different (or no) contract details
• Poor Developer Experience: No standard API for contract discovery and metadata

While ENS enables human-readable contract names, the ecosystem lacks standardized metadata storage. Projects create custom solutions, users rely on centralized services, and critical information gets scattered across different platforms.

Our Proposed Solution​

We've submitted an ENSIP that extends ENSIP-5 (Text Records) with standardized metadata fields for smart contracts. This creates one source of truth for contract information, stored directly in ENS records.

Imagine if instead of simply seeing a hex contract address you had a rich view of the contract such as this:

Our proposed standard would serve as a foundation to make such information available for smart contracts across Ethereum.

New Text Record Fields​

Contract Classification:

• category: Contract type (defi, dao, utility, gaming)
• license: Software license (MIT, Apache-2.0)
• docs: Official documentation links

Security Information:

• audits: Structured audit report data with auditor names and report links
• proxy: Proxy contract details and implementation addresses

Compiled Metadata Resolver​

The proposal introduces a new resolver profile for complete compiler-generated metadata. Building on ENSIP-4's (Support for contract ABIs) multi-encoding approach, it supports:

• JSON formats: Uncompressed and compressed
• CBOR encoding: For onchain parsing
• URI storage: IPFS, Arweave for large files

This metadata contains everything needed for contract verification: ABI definitions, compiler settings, source code hashes, and NatSpec documentation.

Real Impact​

This standard solves concrete problems:

• Users can verify contract authenticity before signing transactions
• Developers get standard APIs for contract metadata across all applications
• Projects build professional contract identity that increases user trust
• Ecosystem reduces dependence on centralized services

Contract Metadata in Action​

We've implemented this metadata standard for our own contract as a demonstration. You can see v0.enscribe.named.eth on ENS Manager with all the proposed metadata fields populated (some values are placeholder for now).

Since the ENS manager app doesn't yet render contract metadata optimally (it's designed for user profiles), here's how we envision displaying contract metadata in applications built for contracts:

Current ENS Manager view - shows metadata but not optimized for contracts

Enscribe's contract-focused interface - Technical details, security audits, and expanded metadata view

The difference is clear: contract-specific interfaces can organize and display metadata in ways that help developers and users understand what they're interacting with.

We Need Your Input​

The proposal draws from our experience building contract naming tools, but community feedback shapes the final standard.

Help us refine:

• Technical implementation approach
• Additional metadata fields
• Wallet and dApp integration needs
• Use cases we should address

Review and Feedback​

Enscribe makes smart contracts easier to trust by giving them human-readable names. This ENSIP extends that mission — moving from basic naming to complete contract identity infrastructure.

Read the full proposal: ENSIP: Contract Metadata Standard and Text Records

The proposal includes technical specifications, implementation examples, and design rationale. Whether you build protocols, develop wallets, or use onchain applications, your input helps create better infrastructure.

Join the discussion and help us build standardized, discoverable contract identity for the onchain world. You can also share your thoughts, suggestions, and any issues you encounter through our Discord community, Telegram, or X.

Happy naming! 🚀

With Enscribe, our mission has always been simple yet ambitious — to eliminate hex contract addresses from the Ethereum user experience. Hex strings like 0x123abc… are cryptic, intimidating and unfriendly to users.

ENS transforms these meaningless identifiers into human-readable names like vitalik.eth just like DNS resolves domain names on the internet to IP addresses.

With our latest update, we’re eliminating these annoying hex addresses from URLs, further enhancing Enscribe’s UX.

A Friendlier Way to Explore Contracts and Accounts​

Previously, if you wanted to explore details about an account or contract on Enscribe, you had to navigate using its hexadecimal address:

https://app.enscribe.xyz/explore/1/0xd8da6bf26964af9d7eed9e03e53415d37aa96045

Where 1 is the chain-id (Ethereum) and 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 is an EOA on Ethereum.

Now, we’ve enhanced the experience so you can simply use ENS names instead:

https://app.enscribe.xyz/explore/1/vitalik.eth

Whether it’s an EOA (Externally Owned Account) or a smart contract, Enscribe will resolve the ENS name and fetch its details.

This doesn’t just work for the mainnet. Thanks to the support for resolving names on Layer 2 chains, we can also use a Layer 2 chain-id and the name with it, such as

https://app.enscribe.xyz/explore/8453/greg.base.eth

Why This Matters

Ethereum’s UX still leans heavily on raw addresses, making the ecosystem less approachable for everyday users. Our goal at Enscribe is to flip that narrative, to make names the default, and hex addresses optional. By supporting ENS names everywhere we display or consume on-chain data, we’re moving toward an Ethereum experience that’s:

• Human-friendly → Users interact with alice.eth, not 0x4b2...9f7.
• Consistent → Works across EOAs and contracts alike.
• Aligned with ENS adoption → Encouraging the ecosystem to name their contracts and improve discoverability.

Enscribe isn’t just about contract naming — we’re helping reshape Ethereum’s UX around names, not hex.

You can try it out now in the Enscribe app, check out vitalik.eth at

https://app.enscribe.xyz/explore/1/vitalik.eth

Happy Naming! 🚀

With Enscribe, we’re always looking for ways to make viewing smart contracts details simpler and safer for users. Our latest update to the Contract Details page introduces two subtle yet impactful changes designed to improve clarity and usability for our users.

Spot Your Primary Contracts at a Glance​

When looking at contract information, it can be a little overwhelming when trying to identify what the primary name of the contract is. To simplify this, we’ve introduced a blue tick next to primary contract names.

Now, when you view the Contract Details page for a particular contract, you can easily see if a primary name is set for the contract.

We’ve also shown a tooltip that tells you you are looking at a primary name:

For contracts that have no primary name set but do have at least one forward resolution name set, we now also show that name:

However, to make sure that we differentiate between primary and forward resolution names, we show the usual cautionary warning sign as well as explain it in the tooltip:

Introducing the “Name It!” Button​

Contracts without names can make browsing blockchain data cumbersome. That’s why we’ve added the Name It! button next to contract addresses that:

• Don’t yet have a primary name set, or
• Have at least one forward resolution name available.

Here’s a proxy contract that has no name set:

Here’s a contract that doesn’t have a primary name set but has a forward resolution name set:

Clicking the button takes you straight to the Name Contract page on Enscribe, with the contract address pre-filled. This saves you time, reduces manual input and ensures you can seamlessly add meaningful, human-readable names to your contracts.

By making it easier to name your contracts, we’re helping you keep your on-chain activity clear and structured.

Why These Changes Matter​

With these enhancements, we’re continuing our mission to make on-chain data more accessible and user-friendly. Whether you’re a developer, an ENS enthusiast, or just someone managing multiple contracts for a project, these updates simplify contract name identification and improve overall interaction experience on Enscribe

Go check your contract on the Contract Details page today and let us know what you think about them on our X/Telegram/Discord channels.

Happy naming! 🚀

Enscribe now supports L2 primary names, extending our smart contract naming capabilities across the Ethereum ecosystem. This feature helps developers maintain consistent contract identities across multiple Layer 2 networks.

What Are L2 Primary Names?​

L2 primary names solve a fundamental problem in the multi-chain Ethereum ecosystem. A single DApp can have different contract addresses across various Layer 2 networks, or sometimes the same address (often due to CREATE2 deployments). Without a standard way to name them, users and developers must manage a confusing list of addresses.

According to ENSIP-19, L2 primary names enable reverse and primary name resolution for all coin types across the multichain Ethereum ecosystem. This standardizes how ENS names resolve to different addresses based on the network, making the ecosystem more legible and trustworthy. This works regardless whether the contract's address is the same or different across networks.

This is possible through a coinType parameter in the ENS resolver function addr(bytes32 node, uint256 coinType), which specifies the network. A single ENS name like mycontract.eth can be configured to point to the correct contract address on each chain.

• Coin type 60 (0x3c) for Ethereum mainnet
• Coin type 2147483658 (0x8000000a) for Optimism
• Coin type 2147483653 (0x80002105) for Base
• Coin type 2147483656 (0x8000e708) for Linea
• Coin type 2147483652 (0x8000a4b1) for Arbitrum
• Coin type 2147483657 (0x80082750) for Scroll

L2 Primary Names in Enscribe​

Enscribe supports L2 primary names across five Layer 2 networks:

• Optimism (Mainnet & Sepolia)
• Arbitrum (Mainnet & Sepolia)
• Scroll (Mainnet & Sepolia)
• Base (Mainnet & Sepolia)
• Linea (Mainnet & Sepolia)

The feature works in two directions. Forward resolution means your ENS name resolves to the correct contract address on each L2. Reverse resolution means your contract address resolves back to your ENS name on each L2.

Example: If you set up myname.eth → 0x123... on Ethereum and Base:

Forward Resolution:

• Ethereum: Coin type 60 (0x3c) - myname.eth resolves to 0x123...
• Base: Coin type 2147483653 (0x80002105) - myname.eth resolves to 0x123...

Reverse Resolution:

• Ethereum: 0x123...addr.reverse - resolves back to myname.eth
• Base: 0x123...80014a34.reverse - resolves back to myname.eth

Note: L2 primary names for Linea and Base are different from currently supported .linea.eth and .base.eth names. L2 primary names work through ENSIP-19 coin types, while .linea.eth and .base.eth are separate ENS domains.

How to Use L2 Primary Names​

Prerequisites​

You must set up L2 primary names from an L1 chain (Ethereum mainnet or Sepolia). This process cannot be done by connecting directly to an L2 network.

The reason is that the core ENS infrastructure, which manage name registration and resolution rules, reside on L1. Key actions, like creating subnames and configuring them to point to different addresses on various L2s—must be recorded on these foundational L1 contracts to ensure a single, authoritative source of truth.

Enscribe supports three main scenarios for setting up L2 primary names:

1. L1 + L2 Naming: Set primary names on both L1 and selected L2 chains when your contract has the same address across all networks
2. L2 Only Naming: Skip L1 naming and set primary names only on specific L2 chains
3. Multi-Address Naming: Use the same ENS name for different contract addresses on different L2 chains

Case 1: Same Contract Address Across All Chains​

This approach is for contracts that have the same address on different L2 chains. You can name this contract on all L2 chains together.

1. Connect to L1: Connect your wallet to Ethereum mainnet or Sepolia
2. Enter contract details:
   • Contract Address: Your contract's address on L1
   • Contract Name: Choose a name for your contract
   • ENS Parent: Select your preferred ENS parent domain
3. Select L2 chains: Click "Choose L2 Chains" and select which L2 networks you want to set up
4. Review steps: The system shows all steps that will execute:
   • Create subname on L1
   • Set forward resolution on L1
   • Set reverse resolution on L1 (if applicable)
   • Set forward resolution on each selected L2
   • Switch to each L2 and set primary name
5. Execute transactions: The modal guides you through each step, automatically switching chains

Case 2: Name Only on Selected L2 Chains​

If you want to set up primary names only on specific L2 chains without L1 naming:

1. Follow steps 1-3 from Case 1
2. Enable "Skip L1 Naming" to skip L1 forward and reverse resolution
3. Submit to execute only L2-related steps

Case 3: Different Contract Addresses on Different L2 Chains​

If you deployed the same contract on different L2 chains but it has different contract addresses, you can use the same ENS name as the primary name for all chains.

Use the same name label and ENS parent, then:

1. Enter the first contract address and select its corresponding L2 chain
2. Enable "Skip L1 Naming" to focus only on L2 naming
3. Execute the naming process
4. Repeat for each different contract address on different L2 chains

Don't worry — it won't create a subname every time on L1. The subname creation happens only once, and subsequent operations just set up the L2 primary names.

Note: The default Enscribe parent domain, deployd.eth, is not yet compatible with L2 primary names. For now, please use your own ENS domain as the parent. We will resolve this issue in our next release, which will involve redeploying the Enscribe contract.

Benefits for Different Users​

For Contract Deployers​

Contract deployers get a unified identity for their contracts across all chains. Users can interact with your contract using the same name regardless of which chain they're on, eliminating the need to explain different addresses for the same contract.

For Users​

Users benefit from simplified interactions — they can use the same ENS name to interact with contracts across chains. This reduces errors from sending transactions to wrong addresses and makes it easier to find and verify contract addresses.

For the Ecosystem​

The broader ecosystem sees improved interoperability as cross-chain contract interactions work smoothly. Enhanced security comes from reduced risk of address confusion, leading to a more intuitive multi-chain experience.

Video Tutorials​

Complete walkthroughs for above 2 use cases: same address across chains and L2-only naming

What's Next​

L2 primary names support represents a step forward in making the multi-chain Ethereum ecosystem more legible. We plan to:

• Add more L2 networks as the ENS team adds support for more L2 EVM chains
• Improve the user experience with better chain switching and transaction flow
• Offer analytics insights into L2 primary name usage and adoption

Try It Out​

Ready to give your contracts a unified identity across the Ethereum ecosystem? Visit app.enscribe.xyz, connect your wallet to Ethereum mainnet or Sepolia, navigate to "Name Contract", enter your contract details, select your desired L2 chains, and execute the naming process.

Feedback and Community​

We want to hear your experience with L2 primary names. Share your thoughts, suggestions, and any issues you encounter through our Discord community, Telegram, or Twitter/X.

L2 primary names help make the multi-chain Ethereum ecosystem more legible and trustworthy. We're excited to see how this feature helps developers and users navigate the onchain landscape more effectively.

Happy naming across chains! 🚀