We’ve spent the last few months focused entirely on the technical side of Enscribe building out the web app and tools for Foundry and Hardhat to make ENS integration for smart contracts less of a headache.

But we don't want to build in isolation. Smart contract identity is complex and the best way to build and improve tools for it is to actually talk to the people who are interacting with naming contracts every day.

We’re moving away from just sharing updates. Instead, we want to build a space where smart contract developers and ENS enthusiasts can actually get into the weeds with us.

We already have our active communities on Discord and Telegram, but in today’s increasingly AI-driven environment, we believe it's important to have more of a human connection with our users and community.

Starting next week, we’re hosting monthly Enscribe community calls. These are the activities we will be doing during the sessions:

• Showcases: Hands-on sessions on naming contracts, using our libraries, and getting the most out of the Enscribe web app and our developer tooling.
• Contract identity clinics: Support for breaking down the more hairy parts of the ENS protocol so it’s easier to build on.
• Roadmap & Demos: We’ll show you what we’re shipping next before it goes live and we want to see what you’re building too.

The goal here is to be a high-signal spot for our community to learn more about contract identity services, provide feedback, suggest features and help us shape where Enscribe goes.

We want to hear how you’re using the web app and our developer tools so we can refine them to fit real-world workflows. If a library doesn't play nice with your specific dev environment, we want to hear about it. We’re opening this community specifically to get your feedback so we can iterate on things that actually matter to your workflow.

We’ve officially set the date for our first community sync. If you’re building with ENS or just curious about what we’re putting together, we’d love to have you there.

You can register for the call here.

Happy naming! 🚀

If you have spent any time using Ethereum wallets or block explorers, have you ever questioned why smart contracts are still referred to via their hexadecimal addresses?

You don’t have to enter numeric digits to visit websites. Why can’t you refer to smart contracts by name?

Smart contracts can have human-readable names. The Ethereum Name Service (ENS) has existed for almost 9 years which solves this problem. Some protocols already use human-readable names for their smart contracts. And yet, for most users, smart contracts still appear as long hexadecimal strings that are opaque, hard to distinguish, and easy to confuse.

This is not an accident, and it is not because naming does not work. It is the result of several structural choices in how Ethereum infrastructure evolved. Understanding those choices matters, because the lack of discoverable contract identity is not just a UX issue. It has real security and trust implications for users.

So why, in practice, are contract names not discoverable by default?

1. Wallets and infrastructure do not surface primary names​

The most immediate reason is simple. Many wallets do not show ENS primary names for smart contracts, even when they exist.

Take MetaMask as a common example. When interacting with a contract, MetaMask may display:

• An Etherscan label, if one exists
• A Solidity file name, if the contract is verified

Coinbase’s Base wallet, on the other hand, simply shows a hexadecimal contract address.

What neither wallet reliably displays is the ENS primary name associated with that contract address.

Other wallets are experimenting in this direction. Ambire, for example, has started to surface ENS names more prominently in contract interactions, showing that better visibility is possible today.

The result is that a contract can be correctly named in ENS and the user still only sees a hex address in their wallet.

From a user’s perspective, the name effectively does not exist. From a protocol’s perspective, the effort spent naming contracts has limited downstream impact unless wallets and explorers choose to surface that information.

This is a visibility problem at the infrastructure layer. The data exists, but the most important interfaces do not yet treat it as first-class.

2. ENS identity has historically focused on wallets, not contracts​

ENS identities have typically been associated with wallet identities for individuals and projects. ENS names became a way to represent people, DAOs, and accounts, rather than deployed infrastructure.

There has never been a coordinated push to establish smart contract identities as a first-class concern. As a result, naming contracts was not treated as a default expectation, either socially or technically.

This shaped how tooling, documentation, and mental models evolved. ENS was widely understood as an account naming system, not as a layer for organisational or protocol infrastructure.

This gap is a large part of why Enscribe exists. The goal is not to replace ENS, but to extend it into the domain it has historically underserved — smart contracts.

3. Developers historically have not named contracts​

This wallet-centric framing was reinforced by developer practice.

For most of Ethereum’s history, developers simply did not name their smart contracts once they were deployed. Contracts were deployed and verified at best. Then identified primarily by addresses listed on docs portals or in GitHub repos.

This made sense in a smaller, highly technical ecosystem. Developers knew which address was which. Users were expected to rely on audits, documentation, or social context rather than any notion of onchain identity.

But Ethereum has changed. Smart contracts are now interacted with by:

• End users
• DAOs and governance systems
• Wallet interfaces
• Agentic systems

At this scale, it’s embarrassing to have unnamed infrastructure.

Compounding this, many of the largest and most respected protocols in the ecosystem, including Uniswap and Aave, have historically not named the majority of their deployed contracts. When leading protocols do not treat contract naming as important, there is less incentive for others to do so.

One of the goals of Enscribe is to change this default. That means making it straightforward to name existing deployed contracts, and making it easy to name new contracts at deployment time.

Crucially, this has to fit into existing developer workflows. That is why Enscribe focuses on developer tooling that integrates directly with environments developers already use, such as Foundry and Hardhat, rather than introducing entirely new processes.

Naming needs to become something developers do by default, not something that feels optional.

4. Users have been conditioned to accept hex as normal​

The combination of wallet behaviour and developer practice has had a direct effect on user expectations.

Because ENS identities were primarily associated with wallets, and because most smart contracts were never named in the first place, users have spent years interacting with contracts that had no visible identity at all. Over time, this conditioned users to accept hexadecimal addresses as normal.

Ethereum users, even non-developers, scroll past hex strings, copy them, and compare the first and last few characters almost instinctively. What began as a technical necessity gradually became a learned behaviour.

This conditioning hides how problematic hex addresses really are:

• They are visually noisy

• They take up a disproportionate amount of space in wallet interfaces

• They are almost impossible to distinguish reliably at a glance

In most other computing contexts, this would be unacceptable. We do not identify websites, applications, or organisations by raw identifiers. We use names.

But because smart contract identity was never treated as a first-class concern, users were never given a viable alternative. Wallets did not surface names, protocols did not consistently set them, and expectations adjusted accordingly.

The absence of pushback is not evidence that this model works. It is evidence that users have adapted to a system that offers very little transparency at the moment when trust decisions matter most.

5. Primary name mechanics are still constrained​

Even when teams want to do everything correctly, there are real mechanical limitations today.

Setting an ENS primary name for an address typically requires the address to the ERC-173 Ownable standard. This works well for some contracts, but not all smart contracts fit neatly into that model.

As a result:

• Some contracts can have forward-resolving names but no primary name
• Some naming setups are technically correct but invisible to wallets
• Some teams simply give up because the rules are unclear or restrictive

There are ongoing discussions within the ENS ecosystem about expanding the scope of what can set and manage primary names, particularly for contracts. These discussions are important, but changes at this level take time.

In the meantime, the ecosystem lives with a fragmented approach to contract identity.

Why this matters​

When contract names are not discoverable by default, there is a real cost to users.

They experience:

• Confusion during transactions
• Difficulty distinguishing real contracts from impostors
• Increased susceptibility to spoofing and address poisoning
• Over-reliance on off-chain, often centralised labels

This doesn’t need to be the case. The pieces for a better system already exist. What is missing is alignment between naming practices, infrastructure support, and user expectations.

Contract identity should not be a nice-to-have. It is foundational infrastructure for transparency and trust at scale.

If Ethereum is going to support millions of users interacting with thousands of contracts per protocol, then human-readable, discoverable identity needs to stop being optional and start being treated as essential.

Giveth has adopted ENS-based naming across its core smart contract infrastructure, bringing clear, human-readable identities to the contracts that power the Giveth ecosystem.

This update makes it easier for donors, builders, researchers, and ecosystem partners to understand and verify how Giveth works onchain — without changing how the protocol itself operates.

Why contract naming matters for Giveth​

Giveth exists to support public goods, community funding, and transparent coordination. Trust and transparency are foundational to that mission.

However, raw contract addresses are difficult to interpret, especially for:

• donors who want confidence in where funds are flowing
• contributors and integrators building tools around Giveth
• researchers and community members analysing impact and governance

ENS-based naming helps bridge this gap by making contract roles explicit and verifiable.

Clear, structured naming across the protocol​

Giveth’s smart contracts are now organised under a structured ENS namespace, with each contract receiving a name that reflects its purpose within the system.

These names form a clear, browsable onchain directory of Giveth’s infrastructure. This makes it easier to understand what powers donations, project funding, governance, and supporting infrastructure across the Giveth ecosystem.

What this improves​

Transparency for donors

Human-readable contract names make it easier to verify that donations and interactions are going to the intended components of the protocol.

Safer integrations

Builders and partners can integrate against named contracts, reducing the risk of address-level mistakes.

Easier research and accountability

Clear naming improves long-term traceability of how Giveth’s onchain infrastructure evolves over time.

Accessibility

Lowering the cognitive barrier to understanding smart contracts helps make Giveth more approachable to a broader audience.

Enscribe’s role

This rollout is supported by Enscribe, which provides the infrastructure for creating and managing structured, verifiable ENS names for smart contracts.

Enscribe ensures that Giveth’s contract identities remain consistent and resolvable across ENS-enabled wallets, explorers, and developer tools.

Supporting public goods through better infrastructure

ENS-based contract naming may seem like a small change, but it meaningfully improves how onchain systems are understood, trusted, and maintained.

By making its contract infrastructure more legible and accessible, Giveth continues to lead by example in building transparent, community-oriented public goods on Ethereum.

Name your contracts. Strengthen 🦾 your protocol​

Naming isn’t just for Giveth, it’s for any project building on Ethereum.

Whether you’re a funding platform like Giveth, DAO, game, or DeFi protocol with dozens of contracts, Enscribe helps you structure and create trust for your users.

Join the growing standard for Ethereum: Name your contracts with Enscribe.

Happy naming! 🚀

When ENS Contract Naming Season launched, our goal was simple — to increase trust for users of smart contracts in Ethereum through contract naming with ENS. A few months in, we’re starting to see that shift take shape.

Teams across the ecosystem are naming deployed contracts, integrating ENS into deployment workflows, and treating contract identity as part of core infrastructure rather than an afterthought.

This post is a short update on why Contract Naming Season exists, what has changed so far, and what to expect next.

Why smart contracts need onchain identities​

Despite significant progress in Ethereum UX, users still interact with unnamed hex addresses every day across explorers, wallets, governance tools, and DeFi applications.

That has real consequences:

• Security risks, including spoofing and address poisoning
• Poor usability, particularly for non-technical users
• Loss of context, where it’s unclear what a contract actually represents

Contract naming directly addresses these issues. It improves clarity, trust, and interpretability across the stack, while extending ENS usage well beyond EOAs.

Contract Naming Season exists to accelerate this shift through a combination of coordination, incentives, and tooling.

Protocols are naming key contracts​

One of the most encouraging outcomes so far is that contract naming is already happening in practice.

Multiple protocols have publicly announced contract naming efforts, with others actively in progress. In many cases, naming has been applied across entire contract suites, rather than single deployments.

At the time of publication, we’ve already shared updates about Cork, Liquity and Nouns DAO, with more to follow very soon!

This reflects a growing understanding that contract identity needs to be consistent, hierarchical, and maintainable over time. This is especially important for protocols, applications, and DAOs with long-lived infrastructure.

Contract naming takes time​

It’s also worth noting that contract naming for established protocols is not an instantaneous process. For teams with mature deployments, multiple environments, and governance controls, lead times of two to three months are common.

This includes protocol wallet and contract inventory work, review of naming structures, multisig coordination, and, in some cases, governance approval. As a result, many naming efforts currently underway will surface gradually, and we expect the cadence of public announcements to increase as Contract Naming Season continues.

Tooling has caught up​

Momentum around contract naming has been supported by meaningful improvements in tooling.

Since launch, Enscribe has shipped updates aimed at real-world protocol needs, including:

• Batch contract naming, to support large deployments
• Full Safe support, aligning with standard treasury and admin setups
• Calldata export, enabling review, coordination, and use with custom multisig workflows

On the developer side, we have integrated contract capabilities into Foundry and Hardhat via our developer plugins, reducing friction and making naming easier to adopt as part of standard deployment and maintenance processes.

Naming audits​

A notable secondary outcome of Contract Naming Season has been the emergence of what teams are calling naming audits.

It can be challenging for teams to know where to start with respect to naming their existing protocol contracts and wallets. When we first speak to projects we often find:

• A lack of good ENS name hygiene
• No standardised approach to contract naming
• Relying on docs and GitHub repos to articulate key project contracts
• No naming of deployment and treasury wallets

With our naming audits, we help teams better understand their on-chain footprint and document it using ENS names. In addition we are using our learnings to help establish better practices about contract naming and versioning with ENS.

You can read more about how we approach them on our dedicated Naming Audits page.

What’s next​

Contract Naming Season is moving into its next phase.

In the coming weeks, this will include:

• Further protocol announcements and outreach
• The first Contract Naming Season awards, with the first batch of $ENS distributions expected soon
• New category additions the ENS Awards Contract Naming Season leaderboard
• Continued improvements to Enscribe, including hierarchical name browsing and richer metadata support

Together, these steps are intended to reinforce contract naming as a normal and expected part of Ethereum infrastructure.

Looking ahead​

If you deploy smart contracts, naming is a crucial component of how users understand and trust your protocol.

Contract Naming Season provides a practical opportunity to:

• Improve security and user confidence
• Make contracts legible across wallets, explorers, and applications
• Contribute to how smart contract identity evolves on Ethereum

The groundwork is in place, participation is growing, and the first recognitions are about to be distributed.

The best time to name your contracts was yesterday, the next best time is today.

Happy naming! 🚀

Cork has adopted ENS-based naming across its smart contract infrastructure, using Enscribe to assign clear, verifiable identities to its core protocol contracts and wallets.

Cork is tokenized risk infrastructure: a programmable risk layer for onchain assets such as RWAs, vault tokens, and yield-bearing stablecoins.

This marks another step toward making contract naming a default expectation for production-grade DeFi protocols, not an optional enhancement, but foundational infrastructure.

From addresses to identities​

Smart contracts are the backbone of onchain applications, yet they are still most commonly identified by opaque hexadecimal addresses. While precise, addresses provide no information about intent, ownership, or role within a protocol.

As protocols scale, this creates friction:

• audits require repeated address-to-purpose mapping
• integrations become more error-prone
• analysts and explorers rely on off-chain labels to verify deployments

ENS-based naming replaces ambiguity with explicit, verifiable identity.

How Cork uses Enscribe​

Using Enscribe, Cork has assigned structured ENS names across its contract stack. Each subsystem is given a clear namespace, and each contract is named according to its role within the protocol’s architecture.

These names are bound to deployed addresses via ENS. Wallets, explorers, and dashboards that support ENS can surface these identities automatically, without requiring any protocol changes.

The result is a coherent, browsable onchain directory that mirrors how Cork is actually built.

Why this matters beyond Cork​

While this rollout directly benefits Cork’s users and contributors, it also reflects a broader shift happening across Ethereum.

More protocols are recognising that:

• human-readable contract identities improve safety
• structured naming reduces operational risk
• ENS resolution is already widely supported across the ecosystem

Naming contracts is becoming part of the baseline for how serious onchain systems present themselves.

Enscribe’s role​

Enscribe provides the tooling and infrastructure that makes structured contract naming practical at scale.

For Cork, Enscribe ensures that contract identities remain:

• consistent across deployments
• verifiable via ENS standards
• compatible with wallets, explorers, and developer tooling

Our goal is simple: make contract naming boring, reliable, and universal.

Naming as shared infrastructure​

ENS-based naming doesn’t change how protocols work — it changes how they are understood.

Cork’s adoption reinforces a growing norm: if a contract is important enough to secure value, it should have a name that clearly communicates what it does.

Name your contracts. Strengthen your protocol​

Naming isn’t just for Cork, it’s for any project building on Ethereum.

Whether you’re a DAO, social app, game, or DeFi protocol with dozens of contracts, Enscribe helps you structure and create trust for your users.

Join the growing standard for Ethereum: Name your contracts with Enscribe.

Happy naming! 🚀

In software engineering, versioning is a core tenet of release management. However, when smart contracts are deployed to Ethereum networks, the deployment artifacts live as 42-character hexadecimal strings, with no onchain versioning information being captured about them.

They may be versioned in the GitHub repositories they were deployed on, or documented in docs, but there is no decentralised location where release information is captured, which seems ironic given they live on permissionless networks.

We want to see this change. It is now possible to easily deploy smart contracts with onchain versioning, and in this post we’re going to outline how you can do it.

We will demonstrate how you can bridge the gap between CI/CD pipelines, deployment scripts and onchain identity by programmatically assigning ENS names during deployment using open source tools.

Most developers use Foundry and Hardhat - two very popular options for smart contracts management. We provide examples showing usages of both these tools.

We’ll use Github Actions as an example but the steps/configs described should be fairly straightforward and similar with other CI/CD tools.

Naming with Foundry​

We can use the Enscribe Foundry library that is written in Solidity to version your contracts. This is an example script that demonstrates how you can set a name to a contract using an environment variable:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {Script, console} from "forge-std/Script.sol";
import {Counter} from "../src/Counter.sol";
import {Ens} from "enscribe/Ens.sol";

contract MyContractScript is Script {
    function run() public {
        vm.startBroadcast();

        counter = new Counter();
        Ens.setName(block.chainid, address(counter), 
string.concat(vm.envString("VERSION"), ".", vm.envString("ENS_PARENT")));

        vm.stopBroadcast();
    }
}

Assume we already have a top level domain name registered like mydomain.eth. You can now run this script directly from the command line to deploy & set a version for your contract:

$ export VERSION=v1 ENS_PARENT=app.mydomain.eth
$ forge script script/Counter.s.sol:CounterScript --rpc-url <BASE RPC URL> --chain-id 8453 --broadcast --private-key <PRIVATE KEY>

You can also run this script from Github Actions like so:

- name: Version Contract
        env:
          VERSION: v1
          ENS_PARENT: app.mydomain.eth
          RPC_URL: ${{ secrets.RPC_URL }}
          PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
          
        # Execute forge script command to set the name
        run: forge script script/Counter.s.sol:CounterScript --rpc-url "$RPC_URL" --chain-id 8453 --broadcast --private-key "$PRIVATE_KEY"

You can name multiple contracts in the same script as well:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {Script, console} from "forge-std/Script.sol";
import {Counter} from "../src/Counter.sol";
import {HelloWorld} from "../src/HelloWorld.sol";
import {MyAwesomeApp} from "../src/MyAwesomeApp.sol";
import {Ens} from "enscribe/Ens.sol";

contract DeployScript is Script {
    function run() public {
        vm.startBroadcast();

        counter = new Counter();
        hello = new HelloWorld();
        app = new MyAwesomeApp();

        Ens.setName(block.chainid, address(counter), string.concat(vm.envString("VERSION"), ".counter.", vm.envString("ENS_PARENT"));
        Ens.setName(block.chainid, address(hello), string.concat(vm.envString("VERSION"), ".hello.", vm.envString("ENS_PARENT"));
        Ens.setName(block.chainid, address(app), string.concat(vm.envString("VERSION"), ".app.", vm.envString("ENS_PARENT"));

        vm.stopBroadcast();
    }
}

- name: Version Contracts
        env:
          VERSION: v1
          ENS_PARENT: mydomain.eth
          RPC_URL: ${{ secrets.RPC_URL }}
          PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
          
        # Execute forge script command to set the names
        run: forge script script/DeployScript.s.sol:DeployScript --rpc-url "$RPC_URL" --chain-id 8453 --broadcast --private-key "$PRIVATE_KEY"

Naming with Hardhat​

If Hardhat, instead, is what you use for contracts management, then you can version using Hardhat and the Hardhat Enscribe plugin.

We can now set an environment variable in your CI/CD pipeline like $CONTRACT_NAME=v1.app.mydomain.eth and add a Hardhat Enscribe plugin command to set this name to the contract address to the pipeline:

$ npx hardhat enscribe name $CONTRACT_NAME --contract <contract address>

For e.g., this is an example Github Actions workflow file where you can set this variable and set the name of a contract:

- name: Version Contract
        env:
          CONTRACT_NAME: v1.app.mydomain.eth
          CONTRACT_ADDRESS: ${{ env.DEPLOYED_ADDRESS }}
          RPC_URL: ${{ secrets.RPC_URL }}
          PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
          
        # Execute Hardhat plugin command to set the name
        run: npx hardhat enscribe name "$CONTRACT_NAME" --contract "$CONTRACT_ADDRESS" --network mainnet

Your should add the Hardhat Enscribe plugin to your dev dependencies in the package.json file before:

{
  "devDependencies": {
    "hardhat": "^3.0.0",
    "@enscribe/hardhat-enscribe": "^0.1.5", 
    ...
  }
}

When you trigger a build and release cycle in the pipeline, your contract is now automatically versioned.

We can use a Git based commit hash as a part of the contract version if it is preferred over semantic versioning by extracting it programmatically and exposing it as an environment variable:

- name: Extract and set Git Hash
        shell: bash
        run: |
          # 1. Get the short hash (7 chars)
          SHORT_SHA=$(git rev-parse --short HEAD)
          
          # 2. Save it to the Global Environment for this job
          echo "GIT_HASH=$SHORT_SHA" >> $GITHUB_ENV

- name: Run Deployment
        run: npx hardhat enscribe name "$CONTRACT_NAME" --contract "$CONTRACT_ADDRESS" --network mainnet
        env:
          CONTRACT_NAME: ${{ env.GIT_HASH }}.app.mydomain.eth
          CONTRACT_ADDRESS: ${{ env.DEPLOYED_ADDRESS }}
          RPC_URL: ${{ secrets.RPC_URL }}
          PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}

Why Versioning Matters​

By adopting onchain versioning, we aren't just making our own lives easier; we are establishing long-overdue transparency for releases. We are moving from a world where users are forced to trust hexadecimal strings to one where every deployment has a human-readable, verifiable name. The tools to make this happen are now here and ready to integrate into your pipeline.

Ready to upgrade your workflow? Check out the Foundry Library, Hardhat Plugin and TypeScript SDK or these examples to start versioning your contracts.

Happy Versioning! 🚀

The Enscribe homepage has been redesigned. The new layout uses three feature cards for clearer navigation, and the search now resolves ENS names in your browser before making any backend calls.

Why We Changed It​

As Enscribe added the new feature Batch Naming, the text-heavy homepage made it hard for new users to find what they needed.

The search bar also created unnecessary load. Users would search for an ENS name, navigate to a details page, and only then discover the name didn't resolve or pointed somewhere unexpected or they were on the wrong chain. This meant:

• Wasted API calls for typos and invalid names
• Extra clicks to discover resolution failures
• Backend queries for exploratory searches

The redesign fixes both issues.

Card-Based Navigation​

The homepage now shows three feature cards:

📄 Name Contract​

Name existing smart contracts with ENS names. Set forward and reverse resolution for contracts you've already deployed.

🚀 Deploy Contract​

Deploy and name contracts in one flow. Skip the extra step of naming after deployment.

📚 Batch Naming​

Name multiple contracts under a single parent domain.

Client-Side ENS Resolution​

The search bar is now a modal that resolves ENS names before you navigate.

How It Works​

1. Click "Explore Contract or Wallet"
2. Type an ENS name like vitalik.eth or 0x1234...5678
3. See the resolved address: vitalik.eth → 0x1234...5678 on the desired chain
4. Verify it's correct and resolves to an address, then click to view details

If the name doesn't resolve, you see it immediately — no wasted navigation.

Why This Matters​

For users:

• Catch typos before navigating
• Verify resolution and chain before committing

For the platform:

• ENS resolution happens in the browser using viem
• Only validated searches hit the backend

The new design is live at Enscribe. We'd like to hear what you think:

• Does the card layout help you find what you need?
• Is the search modal helpful?
• What would you like to see in the future?

Reach out on Discord, Telegram, or X.

Happy naming! 🚀

Liquity V2 has adopted ENS-based naming across its core smart contract infrastructure. Liquity V2 allows users to take out loans against their (staked) ETH at a fixed rate they set, in its fully decentralized stablecoin $BOLD. Liquity is one of the few projects with immutable contracts and no upgradable parameters — meaning no governance and no unpredictable changes to the protocol can be implemented.

The registration of Liquity’s immutable contracts with Enscribe introduces clear, human-readable, and verifiable identities for the contracts, replacing reliance on raw hexadecimal addresses alone.

The protocol’s mechanics remain unchanged. What improves is how those mechanics are identified, verified, and integrated across the ecosystem.

Motivation​

Liquity V2 is designed around simplicity, robustness, and minimising trust assumptions. As the protocol has matured, a growing number of contracts underpin core functionality such as borrowing, stability operations, liquidations, and system coordination.

While contract addresses are precise, they do not communicate intent. This introduces avoidable friction for:

• auditors reviewing deployments and upgrades
• developers integrating Liquity into tooling and applications
• researchers and users verifying onchain interactions

ENS-based naming makes contract roles explicit, without altering protocol behaviour.

Structured contract naming​

Each Liquity V2 contract is now assigned a structured ENS name that reflects its function within the protocol architecture.

These names form a coherent onchain directory that mirrors Liquity’s system design. Wallets, explorers, and dashboards that support ENS resolution can display these identities, making it immediately clear which component of the protocol is being interacted with.

Names are resolved to their deployed addresses, ensuring they remain verifiable and trusted.

Benefits​

Auditability​

Clear naming simplifies locating and viewing contracts by reducing the cognitive overhead of address mapping.

Integration safety​

Developers can reference contracts by name rather than by address alone, reducing the risk of misconfiguration.

Operational transparency​

Tooling and analytics can present Liquity interactions with greater precision and confidence.

User assurance​

Human-readable identities make it easier to verify that interactions are occurring with the intended contracts.

Enscribe’s role​

This rollout is supported the Enscribe contract naming infrastructure, which includes the Enscribe App and plugins for Foundry and Hardhat.

Enscribe ensures that Liquity’s contract identities remain consistent and resolvable across ENS-enabled wallets, explorers, and developer tooling.

Long-term maintainability​

ENS-based contract naming is a small change in surface area, but an important improvement in how the protocol is understood and interacted with over time.

By making contract intent explicit, Liquity strengthens transparency, reduces operational risk, and improves long-term maintainability — without compromising the protocol’s core principles.

Name your contracts. Strengthen your protocol​

Naming isn’t just for Liquity, it’s for any projects building on Ethereum.

Whether you’re a DAO, social app, game, or DeFi protocol with dozens of contracts, Enscribe helps you structure and create trust for your users.

Join the growing standard for Ethereum: Name your contracts with Enscribe.

Happy naming! 🚀

Enscribe has shipped Contract Batch Naming feature for our Enscribe UI app. Teams and projects can now name multiple smart contracts at once under a single parent domain. This reduces the contract naming process for projects with multiple deployed contracts from hours to minutes.

Why Batch Naming?​

Managing multiple smart contracts across different chains has always been a challenge and time-consuming. Whether you're a DAO with governance contracts, a DeFi with multiple vault, protocol, core and utility contracts, or an infrastructure project with contracts deployed across chains, naming each contract individually means repeating the same steps: creating subnames, setting forward resolutions, and setting reverse resolutions. Each step costs gas.

When we worked with Nouns DAO to name their contracts, we saw this problem firsthand. They had to create subnames, set forward resolutions, and set reverse resolutions for each contract as a new step and their governance only allows maximum 10 transaction in a single proposal. This was their first proposal: ENS x Nouns, Name our Smart Contracts which didn't get through because of this issue.

Thus we built the Enscribe V2 contract to support batch naming with multi-chain support. This contract is now live on Ethereum mainnet and Sepolia testnet. You can read more about it in this blog post. Using the Enscribe V2 contract, you can name multiple contracts in one transaction.

We are now adding this batch naming feature support to our Enscribe UI app.

How Batch Naming Works​

Batch naming uses the Enscribe V2 contract's setNameBatch() function. This involves a single transaction for creating subnames under the same parent domain and setting forward resolutions for all contracts at once. For example, if you're naming 10 contracts under myproject.eth, you just need one transaction to create 10 subnames and forward resolutions for all 10 contracts.

But for setting primary names, you need to execute one transaction for each compatible contract (contracts that are ownable/ERC-173 compliant) to set reverse resolution. Here's what happens under the hood:

The Technical Flow​

1. Operator Access: First, Enscribe requests operator approval for your parent ENS domain. This is a one-time permission that allows the Enscribe contract to create subnames under your domain.

2. Batch Creation: All contract addresses and their corresponding names are sent in a single transaction to the Enscribe V2 contract. This creates subnames and sets forward resolutions for all contracts at once.

3. Reverse Resolution (L1): For contracts which are ownable/ERC-173 compliant and owned by your wallet, Enscribe sets up reverse resolution on Ethereum mainnet (or testnet), enabling address-to-name lookups.

4. L2 Primary Names: If you've selected L2 chains, Enscribe automatically switches to each chain and sets up primary names for the contracts there, ensuring consistent naming across all networks.

5. Operator Revocation: Finally, operator access is revoked, returning full control of your ENS domain to you.

All of this happens in one modal flow, with clear progress indicators for each step.

Parent Subdomains Support​

Batch naming supports automatic parent subdomain creation. If you're naming contracts hierarchically (e.g., vault1.defi.myproject.eth, vault2.defi.myproject.eth), Enscribe automatically creates the intermediate parent (defi.myproject.eth) with no forward resolution. This keeps your namespace organized.

Note that each new level of parent subdomain requires a new batch naming transaction. For example, if you're naming three contracts under myproject.eth (app1.myproject.eth, app2.myproject.eth, app3.myproject.eth) and two more contracts under defi.myproject.eth (vault1.defi.myproject.eth, vault2.defi.myproject.eth), you need two separate batch naming transactions:

1. First transaction: app1.myproject.eth, app2.myproject.eth, app3.myproject.eth, defi.myproject.eth
2. Second transaction: vault1.defi.myproject.eth, vault2.defi.myproject.eth

Step-by-Step Guide: Batch Naming Your Contracts​

Let's walk through naming multiple contracts using batch naming.

1. Navigate to Batch Naming​

Head to app.enscribe.xyz and click on "Batch Naming" from the homepage.

2. Choose Your Parent Domain​

Select the parent ENS domain under which all your contracts will be named. You can use:

• Your project's ENS domain (e.g., myproject.eth)
• The default Enscribe parent (deployd.eth)

3. Add Your Contracts​

Enter your contract addresses and their desired names. You can:

• Add contracts one by one using the "Add Entry" button or use Upload CSV to import a CSV file with contract addresses and names.
• You can also download a template CSV file to get started with the format. It has two columns - address and name.
• Use hierarchical names with dots (e.g., vault1.defi, vault2.defi)
• Mix different types of contracts in the same batch

Validation Features:

• Real-time validation of contract addresses
• Duplicate address detection
• Duplicate name detection
• Invalid label format warnings
• Auto-generated parent subdomains highlighted

4. Advanced Options: L2 Chain Selection​

Expand the Advanced Options section to configure L2 primary names.

Click "Choose L2 Chains" to select which Layer 2 networks you want to set up primary names on:

• Optimism
• Arbitrum
• Base
• Scroll
• Linea

The system will add the corresponding coin types and create additional transaction steps to switch to each chain and set primary names.

If you only want to set up L2 primary names without L1 forward/reverse resolution, enable "Skip L1 Naming" in the Advanced Options.

5. Review and Submit​

Once you've added all contracts and configured your options, click "Name Your Contracts". The system will:

• Validate all entries
• Verify contract ownership (for reverse resolution)
• Add steps for naming process

6. Execute Transaction Steps​

A modal will guide you through each step of the process:

Step Progress:

• ✅ Grant operator access
• ✅ Create subnames and set forward resolution (batched)
• ✅ Set reverse records (for owned contracts)
• ✅ Switch to L2 chains and set primary names
• ✅ Revoke operator access

Once all steps complete, you'll see a success screen showing:

• Your parent domain
• An expandable list of all named contracts with their addresses
• Share buttons for X/Twitter and Farcaster
• POAP claiming button (for mainnet deployments)

Limitations and Considerations​

Prerequisites​

• You must connect from an L1 chain (Ethereum mainnet or Sepolia)
• You need to give operator access for the parent domain (granted during the flow)
• For reverse resolution, you must own the contract (also contract must be ownable/ERC173 compatible)

Gas Considerations​

Batch naming is more gas-efficient than individual naming, but naming many contracts still requires significant gas. The transaction cost will depend on:

• Number of contracts in the batch
• Number of L2 chains selected

Maximum recommended batch size: 50 contracts (gas limits may reach for larger batches)

Try Batch Naming Today​

Ready to name multiple contracts? Visit app.enscribe.xyz, connect your wallet to Ethereum mainnet or Sepolia, navigate to "Batch Naming", and start naming.

We'd love to hear about your batch naming experience:

• Share your use cases and suggestions on Discord
• Join the conversation on Telegram
• Follow us on X/Twitter

Happy batch naming! 🚀

Foundry is one of the most popular toolchains for Ethereum smart contract development. Built in Rust, Foundry provides everything needed to build, test, and deploy smart contracts. At the center of this workflow is Forge, Foundry’s scripting and deployment tool. Forge scripts are written in Solidity itself, allowing developers to deploy contracts and interact with them.

However, one key step that developers miss in their workflows is to name their contracts right after the deployment is done. This is where our new Enscribe plugin comes in.

The key idea behind Enscribe is simple: naming should be automated and baked into the deployment scripts. Using Enscribe, a Forge script can register or update an ENS name for a deployed contract, optimally only set forward resolution (ENS → address), and set reverse resolution (address → ENS). Because this logic runs in Solidity, it integrates naturally with Foundry’s scripting environment.

Let’s see how developers can set names for their contract with Enscribe and Forge working together.

1. Create a new project:

   forge init counter
   cd counter
   

2. Install the Enscribe plugin:

   forge install enscribexyz/enscribe
   

3. Install openzeppelin:

   forge install OpenZeppelin/openzeppelin-contracts
   

4. Create remapping.txt in the root dir and add the following to it to simplify imports:

   enscribe/=lib/enscribe/src/
   @openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/
   

5. Make Counter implement Ownable:

   import "@openzeppelin/contracts/access/Ownable.sol";  
   
   contract Counter is Ownable {      
       constructor(uint256 initialCount) Ownable(msg.sender) {
           number = initialCount      
       }
   }
   

6. Edit our deployment script Counter.s.sol to set a primary name for the contract once deployed:

   import {Ens} from "enscribe/Ens.sol";  
   import {Script, console} from "forge-std/Script.sol";
   import {Counter} from "../src/Counter.sol";
   
   contract CounterScript is Script {
       Counter public counter;  
   
       function setUp() public {}
   
       function run() public {
           vm.startBroadcast();  
   
           counter = new Counter(0);
           Ens.setName(block.chainid, address(counter), "v1.counter.abhi.eth");
           
           vm.stopBroadcast();
       }
   }
   

7. Run the script to deploy the contract on Sepolia and set the name at deployment!

   forge script script/Counter.s.sol:CounterScript --chain-id 11155111 --rpc-url $SEPOLIA_RPC_URL --broadcast --private-key $PRIVATE_KEY
   

You can now view the deployed contract in Enscribe app:

This simplification means that teams can use Enscribe to name their releases. For example, we not only named our contract but versioned it too with v1.counter.abhi.eth.

By making contract naming easier and part of the deployment workflow with Foundry, Enscribe encourages better UX and improves safety and usability across the Ethereum ecosystem.

In a world where users increasingly should see human-readable names instead of hex addresses in wallets and explorers, Enscribe helps ensure that smart contracts are just as legible as the accounts that interact with them.

Give it a try.

Happy naming! 🚀