49 posts tagged with "ens"

ENS supports two ways of associating names with addresses.

1. A name can forward resolve to an address (myname.eth -> 0x1234…).
2. An address can declare a primary name which contains a forward resolving address record and a reverse record that points back to the name (0x1234… -> myname.eth).

It’s important to be aware of this distinction between forward resolution and primary names as it defines a security boundary within ENS.

Especially as smart contract identity becomes more visible in wallets and other key infrastructure.

Primary names are definitive​

A primary name is unique per address. An externally owned account or a smart contract can declare exactly one ENS name as its primary identifier.

0x1234… -> myname.eth

When configured correctly, that declaration establishes a canonical mapping from address to name. If a wallet encounters the address and retrieves a valid primary name, there is no ambiguity about which ENS name represents it. The address has explicitly asserted its ENS identity.

This matters because identity is often needed in the reverse direction. Users do not typically begin with a name and look up an address. They encounter an address first in a transaction confirmation screen, governance proposal, or contract interaction. At that moment, the system must decide whether it can replace the hex string with something human-readable.

Forward resolution is not the same thing​

Forward-resolving names work the other way around. A name resolves to an address. If someone types the name into a resolver, they receive the correct destination.

myname.eth -> 0x1234…

This is closer to traditional DNS behaviour. A domain name resolves to an IP address. Reverse DNS exists, but it is inconsistently configured and rarely treated as authoritative identity. Many IP addresses either lack reverse records or have generic ones. As a result, reverse DNS is not widely relied upon as a definitive signal of identity.

In addition, the resources that DNS records point to are ephemeral —  web services come and go, their IP addresses are changing as this happens. Wallet and smart contract addresses are permanent — they exist as long as the blockchain they reside on does.

Forward-only resolution in ENS has a similar limitation. A name resolving to an address does not mean the address stands behind that name as its identity. It simply means the name points there.

Multi-naming systems​

There is an additional subtlety here. Reverse resolution in ENS is specific to ENS itself. If you perform a reverse lookup on an address, you are querying the ENS reverse registry. That lookup assumes ENS is the naming system associated with the address.

In a multi-naming-system world, a reverse record is only authoritative within the scope of the naming service you are querying. This makes the primary name declaration unique to ENS and authoritative within its namespace, but not universally global in the way IP-to-domain relationships are sometimes perceived to be.

That distinction reinforces why primary declaration matters. Within ENS, it provides a canonical answer. Outside of it, identity depends on which naming system an interface chooses to trust.

Ambiguity in forward resolution​

Consider a protocol that deploys a contract at a single address and ends up with several ENS names pointing to it:

• v1.protocol.eth -> 0x456…
• core.protocol.eth -> 0x456…
• vault.anotherprotocol.eth -> 0x456…

All three forward-resolve to the same contract, two are from one ENS namespace, another from an entirely separate one.

From a naming perspective, they could be viewed as labels that cater for different end-users. From a wallet’s perspective, it creates a problem. When the wallet encounters the address first, which name should it display, or even trust?

Without a primary name declaration, there is no protocol-level answer. Interfaces must rely on heuristics. They may look at other names associated with ENS names in the same namespace, or other more sophisticated reasoning models looking at activity of the different domains.

In some cases they may fall back to explorer labels or simply display hex.

None of these approaches are wrong. But none can guarantee a consistent result. This is the fundamental challenge with relying on forward resolution alone.

The ideal expectation​

In a more mature model, every address with an ENS name would also declare a primary name.

Under that expectation, it's very simple for wallets to fully support resolution:

• If the address has a primary name, display it.
• If it does not, display the address.

Forward resolution would continue to support discovery, but identity at the point of interaction would be at the discretion of the wallet.

Alternatively, an external system could issue attestations asserting that a particular forward-resolving name is the authoritative identity for a given address. Wallets could then rely on those attestations when deciding which name to display.

However, this introduces an additional trust layer. An attestation requires an issuer. That issuer becomes a trusted authority within the identity model. The security boundary shifts outward, from protocol guarantees to the credibility of whoever is signing the assertion.

This may be appropriate in some contexts. But it is fundamentally different from an address declaring its own primary name onchain.

The mechanical constraint​

As highlighted in our recent article, setting a primary name for a smart contract is not always straightforward. While externally owned accounts can configure a primary name easily, smart contracts depend on ownership semantics set by the ENS protocol.

Not all projects are willing to make the requisite changes to their smart contracts code to support this.

As a result, teams may stop after configuring forward resolution. The name resolves correctly, but the contract does not assert itself as having a primary name.

Why this is a security boundary​

A security boundary lies at the point where guarantees end and we rely instead on assumptions.

Primary name declaration provides a guarantee. The address has a single, unique identity.

Forward resolution alone provides a somewhat ambiguous mapping. When wallets must choose between multiple forward-resolving names, or infer identity based on context. They are operating beyond guarantees of the naming service.

As ENS data becomes more visible in transaction flows and contract interactions, the distinction between asserted and inferred identity becomes more important.

If smart contract identity is to serve as serious infrastructure, forward resolution alone cannot be treated as sufficient. Primary names must become normalised.

The difference between a name that points somewhere and an address that declares who it is is subtle in implementation. In practice, it is the boundary between a loose versus definitive identity.

Based Nouns has adopted ENS-based naming across its smart contract infrastructure, using Enscribe to assign clear, human-readable identities to the contracts that power the DAO.

As a Nouns Builder–based DAO deployed on Base, Based Nouns operates with a faster iteration cycle and a more experimental governance environment than mainnet Nouns. Clear contract naming helps ensure that this agility does not come at the cost of safety.

A different kind of Nouns DAO​

Based Nouns is not a fork of Nouns DAO — it’s an independent DAO built using the Nouns Builder framework and deployed on Base.

This means:

• a modular contract architecture
• more frequent experimentation and upgrades
• a broader set of contributors interacting directly with the protocol

In this environment, relying on raw contract addresses quickly becomes a bottleneck for understanding, reviewing, and integrating DAO infrastructure.

ENS-based naming makes contract intent explicit.

How naming helps Based Nouns​

Using Enscribe, Based Nouns has assigned structured ENS names to its core contracts, reflecting their roles within the DAO’s governance, auction, and treasury systems.

View Based Nouns contracts in the Enscribe App

These names form a coherent onchain directory that mirrors the DAO’s architecture. ENS reverse resolution cryptographically links each name to its deployed address, allowing wallets, explorers, and dashboards to surface trusted identities automatically.

This is particularly valuable for DAOs like Based Nouns, where contributors, builders, and delegates may be onboarding continuously.

Benefits for the Based Nouns ecosystem​

Faster governance review

Delegates can more easily understand which contracts are referenced in proposals and upgrades.

Safer tooling and integrations

Builders working with Based Nouns can integrate against named contracts rather than manually tracking addresses.

Lower cognitive overhead

Community members and researchers can reason about the DAO’s infrastructure without needing deep address-level context.

Future-proofing experimentation

As the DAO evolves, naming helps preserve clarity even as contracts change.

Enscribe’s role​

Enscribe provides the infrastructure that enables DAOs to manage structured, verifiable ENS names for smart contracts.

For Based Nouns, this ensures that contract identities remain consistent, resolvable, and compatible across ENS-enabled tooling, regardless of deployment cadence or network.

Naming for the next generation of DAOs​

ENS-based contract naming is not just for long-lived mainnet protocols. It is equally important for newer, faster-moving DAOs building on L2s.

Based Nouns’ adoption reflects a growing norm: if a contract matters, it should have a name that clearly communicates what it does.

Name your contracts. Strengthen your protocol​

Naming isn’t just for Based Nouns, it’s for anyone 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! 🚀

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! 🚀