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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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:
L1 + L2 Naming: Set primary names on both L1 and selected L2 chains when your contract has the same address across all networks
L2 Only Naming: Skip L1 naming and set primary names only on specific L2 chains
Multi-Address Naming: Use the same ENS name for different contract addresses on different L2 chains
If you want to set up primary names only on specific L2 chains without L1 naming:
Follow steps 1-3 from Case 1
Enable "Skip L1 Naming" to skip L1 forward and reverse resolution
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:
Enter the first contract address and select its corresponding L2 chain
Enable "Skip L1 Naming" to focus only on L2 naming
Execute the naming process
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.
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.
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.
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.
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.
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.
At Enscribe, we're dedicated to improving the onchain experience for users. One part of this is by making smart contract addresses more human-readable and user-friendly by simplifying contract naming with ENS.
While making the experience more user-friendly, we also want to improve the UI/UX of the Enscribe platform. In line with this commitment, we're excited to announce a key enhancement: Enscribe now fully supports a dark mode theme!
You can find the theme toggle button in the top right corner of the Enscribe application. The white sun icon indicates the light theme, and the dark moon icon activates the new dark theme.
Every screen within Enscribe now adapts to dark mode, designed with carefully chosen color contrasts for optimal readability. This ensures a consistent and comfortable visual experience across the entire application, whether you're deploying a new contract or reviewing your existing ones.
Deploy a new smart contract with primary name
Name an existing smart contract
Transaction loading state
Successful contract naming modal
View account details along with Ethereum Follow Protocol card
Detailed contract information view
Browse your deployed named and unnamed contracts
We've ensured that key workflows, from deploying new contracts and naming existing ones to viewing your account details and managing your contracts, are all optimized for the new dark theme. The improved contrast aims to make your interactions with Enscribe smoother and less straining on the eyes.
We've updated Enscribe to make contract exploration clear and useful across multiple networks. This update focuses on direct sharing links, multi-chain support, and better ENS integration to help you identify and trust smart contracts.
The updated search bar lets you look up any Ethereum address or ENS name without connecting your wallet first. Just paste a 0x address or type an ENS name, and Enscribe immediately shows you the relevant details.
The search works with:
Standard Ethereum addresses (0x...)
ENS names
Automatic detection of which chain to use
The ENS resolution works correctly across different networks, using mainnet resolvers for production chains and Sepolia for test networks, then directing you to the right page based on chain context.
Our new Explore page serves as a central hub for getting ENS details for any address onchain. It detects whether you're looking at a smart contract or a regular account (EOA) and shows you specific information that matters for each type.
You can directly access any address using this URL format:
This standardized URL structure makes addresses easy to bookmark and share with others, allowing for collaborative exploration of the Ethereum ecosystem.
Primary ENS name (if available) with appropriate expiry status icon similar to contract view
All associated ENS names pointing to this address
ENS names owned or managed by this address with expiry information
Copy functionality for addresses and names
Both account and contract views include external links — addresses link to Etherscan while ENS names link to the ENS app. When you click on an ENS name that a contract or account owns, Enscribe resolves it to an address and opens that address in a new tab within Enscribe.
The ENS name resolution for owned names:
Opens resolved addresses in a new tab for convenient exploration
The chain selector helps you navigate between networks while examining an address. It sits at the top of the interface and changes how it works based on whether your wallet is connected.
When No Wallet is Connected:
Choose any supported chain from the dropdown
Switch networks to compare the same address across chains
All data loads specifically for the selected network
When a Wallet is Connected:
Chain selector automatically syncs with your connected wallet's network
When switching chains on wallet, you'll be redirected to view the same address on the newly selected chain
Base Sepolia - Partial support (working with ENS node Namehash team for full integration)
This design handles the specific requirements of each chain, including ENS resolution differences and verification source availability. When you switch chains, the URL updates with the new chain ID, creating direct links to the same address across different networks.
This update makes Enscribe a more useful tool for everyone who works with smart contracts. It creates clarity around contract identity and verification status across multiple networks.
We've rolled out a great new feature in Enscribe — the ability to easily choose your owned or managed ENS domains when deploying or naming smart contracts.
This makes it straightforward to find the right ENS parent name you want to name your contract with.
Thanks to the integration with ENS Subgraph , Enscribe can now fetch all ENS names that your connected wallet owns or manages and show them to you.
When a user connects their wallet, Enscribe queries the ENS subgraph and retrieves a complete list of ENS domains owned or managed by that wallet. These names are then:
Note: Support for Base Sepolia testnet is pending because no ENS subgraph exists yet. We're actively working with Namehash to add support — see GitHub issue #768.
Visit enscribe.xyz and try the new ENS parent selection workflow in both the Deploy and Name Contract flows.
Let us know what you think — your feedback helps us shape a smoother, safer, and more trusted smart contract experience.
We'd love to hear your feedback on this feature — join our Discord community or Telegram communities and let’s eliminate hex smart contract addresses for users.
We’re excited to share a new enhancement in Enscribe's “My Contracts” page that gives users
more visibility and confidence around their verification of deployed smart contracts with Contract Verification Badges.
Smart contract verification is essential for transparency. It lets users and developers inspect the exact source code that’s running on-chain.
Until now, finding all your deployed contracts and checking whether they were verified required manually opening Etherscan or other block explorers, copying contract addresses, and digging through multiple tabs.
With this update, Enscribe now shows verification badges next to every contract you’ve deployed — across both the Named Contracts and Unnamed Contracts tabs on the "My Contracts" page.
If verified, you’ll see a green-bordered badge labeled "Verified" for that platform. Clicking on this badge will take you directly to the verified record on the respective platform, where you (and your users) can inspect the source code, compiler details, and verification status like “Exact Match” or “Partial Match.”
If the contract isn’t verified yet, you’ll see a “Verify” label instead — which links to the verification page for that platform. This way, users can quickly take action without needing to search for the address manually.
Visit the updated My Contracts page and explore the verification status of your deployed contracts. If any of them are missing verification, take a moment to complete it — and get one step closer to making your contracts trusted and verifiable.
As always, we’d love your feedback on this feature. We’re just getting started with trust layers in Enscribe, and your input helps shape what comes next.
For more details, visit our site, and don't hesitate to join our Discord community and Telegram group to share your feedback and experiences.
We’re excited to announce a new update to the “My Contracts” page on Enscribe. If you’ve ever deployed smart contracts and wished for a clearer, more structured way to manage and track them — especially across ENS names — this update is built just for you.
In this release, we’ve reimagined how developers interact with their deployed contracts by dividing the view into two clear categories:
Named Contracts - Contracts deployed by the user which have an ENS Primary Name
Unnamed Contracts - Contracts deployed by the user which doesn't have ENS Primary name
This makes it easy to monitor which of your contracts have verifiable identities through ENS, and which ones are still waiting to be named.
Historically, developers had to use blockchain explorers such as Etherscan, or keep their own records as which contracts they've deployed. With Enscribe we're changing that.
The “My Contracts” page automatically surfaces all contracts directly deployed by your connected wallet. This includes both contracts deployed through standard Ethereum transactions (where the transaction "to" is null) and contracts deployed using CREATE2 via Enscribe.
One thing to note: we currently do not track indirect deployments — such as contracts created through another factory contract (internal contract creation calls). This is a planned improvement and is on our roadmap for upcoming releases.
In the Named Contracts tab, you’ll find all contracts that have been deployed by your wallet and already have a Primary ENS Name.
Each contract entry displays its ENS name, contract address, the transaction hash for creation, and direct links to tools like Etherscan, Chainlens, and the ENS App.
This makes it easy to verify and share your named contracts.
We support Ethereum, Base and Linea mainnets and testnets.
The Unnamed Contracts tab, helps you track contracts you’ve deployed that haven’t yet been named with ENS. Each entry includes the contract address and creation transaction hash, along with a contextual action button. Depending on the contract’s structure,
this button will either prompt you to “Name Contract” (if it supports Primary Name assignment through Ownable/ERC-173/ReverseClaimer) or “Forward Resolve” (if only forward resolution is possible).
We’ve also added smart visual cues to guide you:
A "yellow exclamation" icon indicates contracts that support only ENS forward resolution.
A "green info" icon marks contracts that are eligible for full ENS primary name assignment.
Clicking on the action button takes you directly to the naming interface with the contract address pre-filled — allowing you to easily upgrade your unnamed contracts into trusted, named entities.
One of the most powerful aspects of our DApp is that it’s completely trustless. Enscribe doesn’t use a centralized database. All contract discovery, naming info, and status checks are done on-chain, directly from your connected wallet via RPC calls.
This means no vendor lock-in, no stale cache, no single point of failure — just accurate, permissionless data every time you load the page.
Because we query the chain live, loading the full list of contracts happens asynchronously and can take a bit of time. While your contracts are being processed, you’ll see a spinner at the bottom of the table. Once loading is complete, the spinner disappears, indicating the tables are now fully up to date.
This will be optimised soon.
We’ve recorded a short walkthrough showing how the updated “My Contracts” page works and how you can use it to name your existing or new contracts instantly.
This update turns Enscribe into more than just a naming tool — it’s now your command center for managing smart contract identity across Ethereum and Layer 2s. Whether you’re shipping production contracts or deploying testnet experiments, the new “My Contracts” page gives you a structured, intuitive way to understand what you’ve deployed and what still needs to be named.
Naming your contracts helps users trust them. It makes them recognizable in wallets, block explorers, and dApps. And now, managing that naming process is easier than ever.
For more details, visit our site, and don't hesitate to join our Discord community and Telegram group to share your feedback and experiences.
We’re thrilled to announce that Enscribe is now officially live on mainnet — across Ethereum,
Linea, and Base networks.
Enscribe is a smart contract deployment and naming service purpose-built to bring human-readable identity to on-chain contracts. It allows developers to deploy
contracts and assign ENS names — including subname creation, forward resolution, and reverse resolution (primary name) — all in a single, atomic transaction.
Until now, naming smart contracts using ENS was a fragmented and manual process that required interacting with multiple ENS contracts post-deployment. Enscribe abstracts that complexity entirely.
And yes — we’ve used Enscribe itself to name our production deployments.
This is a major step toward bringing trust and transparency to on-chain contracts through meaningful naming and identity. We’re excited to see what you build with it.
Enscribe your contracts. Make them recognizable.
For more details, visit our site, and don't hesitate to join our Discord community to share your feedback and experiences.
We’re excited to announce a major refresh to the Enscribe Documentation — built to help developers and users better understand
how ENS naming works for smart contracts and how Enscribe makes that process seamless.
Whether you’re deploying new contracts or assigning ENS names to existing ones, the updated docs walk you through every part of
the experience with clear explanations, examples, and new video walkthroughs.
For those looking to dive deeper into ENS internals, smart contract design, and Layer 2 nuances — the Advanced section will soon include:
ENS Terminology - A glossary of ENS-specific concepts for developers and power users.
ENS on L1 vs L2 chains - A detailed breakdown of how ENS behaves differently across Ethereum mainnet, Base, Linea, and other L2s.
Design and Architecture - A full overview of the Enscribe contract system, including sequence diagrams, CREATE2 deployment flow, and ENS contract interactions.
The new Guides section
Current ENS Manager view - shows metadata but not optimized for contracts
Enscribe's contract-focused interface - Technical details, security audits, and expanded metadata view
Deploy a new smart contract with primary name
Name an existing smart contract
Transaction loading state
Successful contract naming modal
View account details along with Ethereum Follow Protocol card
Detailed contract information view
Browse your deployed named and unnamed contracts
