Nouns DAO has rolled out Enscribe-powered ENS names across its contract ecosystem. This change makes the core Nouns infrastructure easier to understand, integrate with, and safer to interact with.

As Nouns has grown, so has the number of contracts powering auctions, governance, treasury movements, builder deployments, experiments, and extensions. But with growth comes complexity, and raw hex addresses don’t communicate the intent or role of a contract to users.

Naming fixes that.

By giving each Nouns contract a clear, verifiable ENS-based identity, the DAO is making its onchain footprint more accessible to builders, researchers, delegates, and collectors who want clarity with their Nouns interactions.

Why Nouns Are Doing This​

🔍 Transparency for DAO participants​

Delegates and community members shouldn’t have to decode long addresses when evaluating proposals or upgrades. A named contract instantly provides clarification as to which part of the system is being touched.

🛠 Better developer ergonomics​

Projects building on or around Nouns, from auction derivatives to governance tools, can integrate faster and with fewer mistakes when contract roles are obvious from their names.

📜 Improved historical traceability​

Nouns is one of Ethereum’s most studied DAOs. Clear naming makes it easier to follow how the system has evolved, which contracts relate to which modules, and how upgrades have been deployed over time.

🔐 Reducing user risk​

Contract spoofing and lookalike addresses have become more common across the ecosystem. Verified ENS names help users and tools avoid interacting with the wrong address.

How the Naming Works​

Each contract receives a structured ENS name that reflects its purpose within the Nouns architecture. Examples include:

• auction.nouns.eth
• candidates.nouns.eth
• rewards.nouns.eth
• streams.nouns.eth
• proposals.nouns.eth
• delegations.nouns.eth
• traits.nouns.eth

You can read more about them on the contract naming proposal that was executed.

These names form a browsable, consistent directory of the Nouns DAO contract suite. Wallets, explorers, and dashboards that support ENS resolution will automatically display these identities, making interactions clearer everywhere they appear.

What This Means for the Nouns Ecosystem​

For delegates:​

You can verify contract changes in governance proposals without needing to cross-reference addresses manually.

For builders:​

Integrations become safer and less error-prone. Tooling becomes easier to maintain. Dependencies become clearer.

For researchers and historians:​

Tracking protocol evolution becomes significantly more intuitive.

For the community:​

Greater clarity around what powers Nouns under the hood, with greater confidence when interacting with the DAO’s infrastructure.

Name Your Contracts. Strengthen Your Protocol​

Naming isn’t just for 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! 🚀

Since we launched Enscribe, we've collaborated with a number of teams on their contract naming.

Whilst we try to ensure the naming process is as simple as possible in our app. Which is supported by extensive documentation and our guides, it can be non-trivial for teams to get the naming work done. Especially when they have an existing legacy of contracts to name, as well as changes to be made to their deployment habits.

As a result of this, we've decided to launch a new service — the Enscribe Contract Naming Audit, which maps every smart contract in your protocol, designs a complete ENS naming architecture, and delivers a launch-ready rollout plan.

Smart Contract Naming Can't be an Afterthought​

As protocols grow, so does the complexity of the contract surface area: proxies, implementations, admin roles and ownership, cross-chain deployments, and internal tooling assumptions. Development teams should standardize naming, but the real-world gets in the way.

This results in:

• Users don’t know which contracts belong to your protocol
• Wallets and explorers can’t present meaningful context about it
• Admin and ownership is unclear
• Onboarding developers takes longer
• Security reviewers must manually reconstruct your architecture

With ENS now widely integrated across wallets, explorers, and infra providers, naming is no longer “nice to have”, it’s part of your protocol’s identity and trust.

A Naming Audit For Your Contract Ecosystem​

With our Contract Naming Audit service, we provide a structured service designed to help teams map, organize, and publicly name every contract in their protocol using ENS.

The audit includes:

1. Full Smart Contract & Wallet Inventory​

We analyze your entire contracts to build a picture of:

• All deployed contracts across chains
• Ownership, admin and upgrade paths
• Proxy types (EIP-1967, Beacon, Minimal, custom)
• Role/access control patterns
• Any orphaned or legacy deployments

This provides a holistic view of your onchain infrastructure.

2. ENS Naming Architecture & Implementation Guidance​

Working with your team, we design a naming structure that reflects your protocol’s architecture:

• Namespace definition (protocol.eth)
• Subname hierarchy (vaults.protocol.eth, router.v4.protocol.eth, etc.)
• Cross-chain naming strategy
• Reverse resolution setup
• Naming rollout planning
• Technical assistance including code reviews, calldata generation/review for multisigs, updates to deployment pipelines

This ensures the foundations are right and the naming can scale with your project.

3. Go-to-market & Messaging​

Naming only makes an impact if users, auditors, and partners see it.

Your contract audit includes:

• Announcement blog post
• Social communications
• Recommended rollout timing
• Additional messaging if required for partners, auditors, and ecosystem integrations

This gives you something to really shout about with your project that is beneficial for your users and Ethereum as a whole.

Why Teams Choose Enscribe​

Enscribe powers ENS naming for protocols who want:

• Clearer user experience across wallets and explorers
• Better auditability through visible ownership and permissioning of onchain contracts
• Reduced operational risk by surfacing deployment patterns
• A unified naming framework across all deployments
• A polished public launch with consistent messaging

We’ve seen repeatedly that naming when done right, becomes part of the developer experience, the security story, and the brand.

Get Your Protocol's Contracts Audited​

If your team is preparing an audit, a major release, or simply wants to improve transparency, we’d love to help.

👉 Explore the Contract Naming Audit Service

🌐 https://enscribe.xyz/audit

Or reach out directly:

📬 hi@enscribe.xyz

Naming Contracts = Responsible Development​

We believe smart contract naming is a key trust layer for web3.

And we’re excited to bring a structured, repeatable audit process to help teams adopt it cleanly, safely, and with confidence.

Happy naming! 🚀

Enscribe is now available as a native Safe app. You can add Enscribe directly to your Safe environment and name contracts using your multisig wallet without leaving the Safe interface.

This update makes it easier for teams and DAOs to manage contract naming through their existing Safe workflows.

Why This Matters​

If you manage contracts through a Safe multisig, you can now:

• Name contracts directly from the Safe interface
• Deploy new contracts with ENS names set using your Safe wallet
• Queue naming transactions for other signers to review
• Execute contract naming once your signing threshold is met
• Keep all contract management in one place

Previously, connecting Enscribe to Safe required WalletConnect, which added friction to the process. With native Safe SDK integration, Enscribe works as a custom Safe app. Add it once, and it's available whenever you need it.

When you use Enscribe inside Safe, the contract naming process creates multiple transactions. These transactions are visible for you to review before signing, added to your Safe's transaction queue, shareable with other signers in your Safe, and executable by any signer once the signing threshold is reached. This workflow matches how Safe handles all multisig operations, making contract naming part of your standard governance process.

Adding Enscribe to Your Safe​

Here's how to add Enscribe as a custom app to your Safe:

Quick Add via Link​

Use this link to add Enscribe directly to your Safe.

If the link doesn't work, follow the manual steps below.

Manual Installation​

Step 1: Open Your Safe​

Navigate to app.safe.global and select the Safe you want to use.

Step 2: Access the Apps Menu​

Click on "Apps" in the left sidebar of your Safe interface.

Step 3: Add Custom App​

1. Click "Add custom app" in the top right
2. Enter the Enscribe app URL: https://app.enscribe.xyz
3. Confirm the app details
4. Click "Add"

Enscribe will now appear in your Safe's app list.

Step 4: Open Enscribe​

Click on Enscribe from your apps list to launch it within Safe.

Naming a Contract from Safe​

Once Enscribe is added to your Safe, you can name contracts using the same interface you're familiar with:

Step 1: Connect to Enscribe​

Open the Enscribe app from your Safe. The app will detect your Safe wallet automatically and connect.

Step 2: Choose Your Chain​

Select the network where your contract is deployed. Enscribe supports Ethereum Mainnet, Base, Linea, Optimism, Arbitrum, Scroll, and their testnets.

Step 3: Enter Contract Details​

Provide the contract address and choose the ENS name you want to assign. Enscribe will guide you through the naming process.

Step 4: Review Transactions​

Enscribe will show you the transactions needed to complete the naming process. This typically includes:

• Creating ENS subname
• Setting forward resolution for your contract
• Setting the primary name

Step 5: Sign and Queue​

When you sign these transactions in Safe:

• They're added to your Safe's transaction queue
• Other signers can review them
• Transactions show up in the "Queue" tab of your Safe
• You can share the queue with your team

Step 6: Execute After Threshold​

Once enough signers approve the transactions (based on your Safe's signing threshold), any signer can execute them. The contract naming completes when all transactions are confirmed onchain.

Managing Multiple Contracts​

If you're naming multiple contracts, you can queue all the transactions before executing any of them. This gives your team time to review everything together.

Each contract naming operation creates its own set of transactions in the queue. Signers can approve them individually or in batches, depending on your workflow.

Once all the transactions are approved or signed by the required number of signers, you can execute them all at once in a batched transaction, this will save you gas and time.

Feedback and Community​

Enscribe makes smart contracts easier to identify by giving them human-readable names. With native Safe support, teams can now manage contract naming through their existing multisig workflows.

If you have feedback or feature requests for the Safe app experience, reach out through our socials - X, Discord and Telegram

Happy naming! 🚀

Basenames are growing in popularity. Users set them for their EOA accounts so that they don’t have to use hex addresses when interacting on Base. Basenames use the solid ENS infra underneath and are fully ENSIP-19 compliant.

Since Enscribe is on a mission to eradicate hex addresses from Web3 UX and contract naming is overlooked, we wanted to enable users to set Basenames for deployed contracts as well. We are excited to announce support for naming your contracts using Basenames.

ENSIP-19 in short​

ENSIP-19 is an ENS Standardization Proposal that standardizes reverse and primary name resolution for all coin types, and defines how this resolution process operates across the multichain Ethereum ecosystem.

This is done by deploying an L2-specific Reverse Registrar contract that takes care of setting reverse records.

For example, suppose we want to set a Basename v1app.alice.base.eth. Then, we first create a subname on L2 ENS Registry by calling setSubnodeRecord:

setSubnodeRecord(namehash(alice.base.eth), labelhas(v1app), deployerAddress, resolverAddress, 0)

Then we can set a forward resolution that maps the name to address with:

setAddr(namehash(v1app.alice.base.eth), BASE_COIN_TYPE, contractAddress)

Finally, set the reverse record with the L2 Reverse Registrar:

setNameForAddr(contractAddress, v1app.alice.base.eth)

How to set a Basename for your contract?​

Navigate to the Name Contract page & connect your wallet if you haven’t already. From the chain dropdown, select Base/Base Sepolia i.e. the chain you want to set the Basename on.

Enter your contract’s address in the Contract Address field and it should automatically detect the chain like shown above.

Click on Create New Name button and enter the new contract name you want to register and the parent domain under which you want to register the subname:

Note: the parent domain entered should already be registered. If you want to register a new parent domain, then use https://www.base.org/names to do so.

Click on Name Your Contract button & you’ll see all the transactions executing successfully:

And just like that, we have successfully set a Basename for our deployed Ownable contract!

Here's a video tutorial on how to set a Basename for your contract:

What This Means for the Ecosystem​

We’re excited to see how the community puts this to use. As always, feedback is welcome—we’re continuing to refine our ENSIP-19 aligned features and would love to hear what you think.

Head over to Enscribe and use a Basename to name your contract!

Happy naming! 🚀

Enscribe V2 is now deployed on Ethereum mainnet. This upgrade brings batch operations, multi-chain support, and gas optimizations that make naming large numbers of contracts practical.

Contract Addresses​

Ethereum Mainnet:

• Enscribe V2: 0x9B95a964DB0ab154A587cC667b4964BD5dD8dE81
• ENS Name: v2.app.enscribe.eth

Testnet (Sepolia):

• Enscribe V2: 0xeA80b94a8B339c592c4F08bcCC87De7b57384BDD
• ENS Name: v2.enscribe.named.eth

The Problem: Naming Contracts at Scale​

Projects deploying multiple smart contracts face a challenge: each contract needs a separate ENS transaction to get a human-readable name. For a project with 10, 20, or 100+ contracts, this means:

• Dozens of individual transactions
• High cumulative gas costs
• Hours of manual execution
• Complex workflow coordination

A DAO deploying governance contracts, treasury modules, and token contracts previously needed separate ENS transactions for each — monitoring every transaction and managing a complex deployment process.

Enscribe V2 solves this.

What's New​

Batch Contract Naming​

Name multiple existing contracts in a single transaction.

// Name 10 contracts at once
address[] memory contracts = [
    0x1234..., // governance.dao.eth
    0x5678..., // treasury.dao.eth
    0x9abc..., // token.dao.eth
    0x0000.... // 0x0 address to reserve the subname
];

string[] memory labels = ["governance", "treasury", "token", "reserve"];

enscribeV2.setNameBatch(
    contracts,
    labels,
    "dao.eth",
    [60, 2147492101] // Ethereum and Base cointypes
);

Note: The reserve subname is created with the address(0) address. This is useful when you just want to create the subname but not set an address yet.

ENSIP-19 Multi-Chain Support​

Set forward resolution for multiple chains at once:

uint256[] memory coinTypes = [
    60,    // Ethereum
    2147492101,   // Base
    42161, // Arbitrum
    10     // Optimism
];

enscribeV2.setName(
    contractAddress,
    "bridge",
    "protocol.eth",
    coinTypes
);

This matters for cross-chain protocols and multi-chain deployments where the same contract needs to resolve on different networks.

Simpler API​

Before V2:

bytes32 parentNode = namehash("myproject.eth"); // Manual computation
enscribe.setName(addr, "app", "myproject.eth", parentNode);

With V2:

enscribe.setName(addr, "app", "myproject.eth"); // Computed automatically

The contract now computes parent nodes using ENS's NameCoder library.

Reserve Names Without Addresses​

Create subnames without setting an address:

address[] memory contracts = [
    0x1234...,    // Active contract
    address(0),   // Reserve "staging", 0x0000000000000000000000000000000000000000 address
    0x5678...     // Active contract
];

enscribeV2.setNameBatch(
    contracts,
    ["prod", "staging", "analytics"],
    "myproject.eth"
);

As demontrated in Batch Contract Naming section also, using address(0) creates the subname but skips forward resolution — useful for just creating the subname.

Projects can now:

• Name dozens of contracts in one transaction
• Save gas through batch operations and new gas optimizations
• Can name contracts on multiple chains at once
• Fully ENSIP-19 compatible

Technical Improvements​

V2 includes several optimizations:

• ENS NameCoder Integration: Uses official ENS library gas savings per operation
• OpenZeppelin Create2: Deterministic contract deployment with industry-standard implementation
• Custom Errors and Events: ~50% gas savings on reverts compared to string messages
• Internal Optimizations: Automatic subname existence checking and address validation

What's Next​

Enscribe V2 contracts are live and ready to use via web3 libraries or transaction builders like Gnosis Safe.

Coming Soon:

• UI updates for batch operations and multi-chain support on Enscribe app
• EnscribeV2 integration to our Enscribe library
• EnscribeV2 for Basenames

Building Contract Identity​

Enscribe makes smart contracts easier to trust by giving them human-readable names. Earlier this year, we proposed an ENSIP for contract metadata standards. V2's batch capabilities and multi-chain support lay the groundwork for that vision — making it practical for projects to build complete, discoverable contract identities.

Whether you're deploying a DeFi protocol, launching a DAO, or building any multi-contract system, Enscribe V2 helps you establish clear contract identity from day one.

Questions? Join our Discord, Telegram or reach out on X.

Happy naming! 🚀

The ENS DAO has officially passed a proposal launching ENS Contract Naming Season — a new community initiative to bring names, identity, and trust to smart contracts across Ethereum.

What is Contract Naming Season?​

Contract Naming Season is a collaborative effort between the ENS DAO, Enscribe and others to help projects name their smart contracts using ENS names, turning unreadable hexadecimal addresses into human-readable, trustworthy names.

To encourage adoption, the ENS DAO has created a 10,000 ENS reward pool, offering incentives to teams that name their contracts and help lead others to do the same.

You can read the proposal on Tally for background.

Why it Matters​

Every time users interact with a smart contract, they’re asked to trust a long, meaningless hex address.

Not only does this make Ethereum harder to use, it leaves users exposed to address spoofing and phishing attacks from scammers.

Millions of dollars is lost every year to address spoofing and poisoning attacks on Ethereum.

Enscribe was created to address these issues. It’s a smart contract naming service built on ENS.

It allows developers and projects to easily name their smart contracts with ENS names. This creates human-readable, trustworthy identities for contracts, turning unreadable hexadecimal addresses into meaningful names.

Where it’s Happening​

Enscribe is live on Ethereum and integrates directly with ENS and contract verification platforms like Etherscan, Blockscout and Sourcify.

We've integrated with projects like Safe, Ethereum Follow Protocol and Open Labels Initiative to make contract naming a new standard for increased safety for Ethereum’s users.

Try it now: app.enscribe.xyz

How to Get Involved​

1. Join the conversation in the:

   • Contract Naming Season Telegram
   • Enscribe Discord

2. Check out our Best Practice Guides for:

   • Apps
   • DAOs
   • DeFi and Protocols
   • L2 networks

3. Start naming your contracts:

   • app.enscribe.xyz

When​

Contract Naming Season runs November 2025 → April 2026.

Reward distribution details will be announced soon — stay tuned!

Voices From the Community​

ENS has always been about empowering the Ethereum community to name and own their digital identities. Contract Naming Season continues that mission — helping developers, DAOs, and protocols give their smart contracts names users can trust.

— nick.eth, Creator of ENS

All smart contracts should be named onchain, for security, readability, and transparency. Contract Naming Season with Enscribe is a great opportunity to finally get it done.

— brantly.eth, Executive Director, Ethereum Identity Foundation, ENS DAO Delegate, ex-Director of Operations, ENS

Naming Season captures what makes ENS, DAOs and Ethereum special — community-led initiatives that drive our ecosystem forward! It’s actions like naming contracts that build the culture of safety and transparency we all depend on.

— james.eth, Fire Eyes DAO, ENS DAO Delegate

Named contracts upgrade security and enhance UX. Promoting awareness of contract naming opportunities across protocols, DAOs, and apps through Contract Naming Season is a key step forward for the Ethereum community.

— lightwalker.eth, NameHash Labs

Let’s Make Ethereum Safer​

Contract naming is a simple step every team can take to strengthen Ethereum’s foundation of trust and transparency. Let’s eliminate hex contract addresses and make human-readable contracts the new default.

Join the movement: app.enscribe.xyz

Happy naming! 🚀

We created the Enscribe App to make it as simple as possible for teams to name their smart contracts. However, this approach is not always compatible with naming DAO contracts.

What we’ve noticed is that DAOs often use a high-level function wrapper that needs to call multiple transactions required to name a contract.

This requires multi-sig high level transaction calling a method such as execute() or executeTransactions() which wraps over executing multiple transactions, each represented by a calldata – an encoded form of a function call along with its arguments.

To make this kind of name setting easy, we’ve shipped a small feature in Enscribe that enables displaying call-data previews.

How to View Calldata?​

In the Enscribe App, there is now a new collapsable Advanced Options section. Open it and you’ll see a calldata section that shows a list of the transactions Enscribe will execute for your naming flow — including items such as subname creation, forward resolution, and reverse resolution.

To try this out yourself, when you paste a contract address, pick a parent (e.g. myapp.eth), and type a name, Enscribe now shows the exact encoded function calls of the transactions that will be sent on-chain as individual transactions.

Each entry shows the target, selector, and ABI-encoded calldata:

You can copy the individual calldata using the copy button displayed against it or you can also copy the entire calldata list in different forms by clicking on the Copy All button at the top of the list on the right side.

Realtime Updates​

This isn’t a static blob. Change any of the inputs — address, label, or parent, and the calldata recomputes instantly. If you switch from router.myapp.eth to vault.myapp.eth, you’ll watch the encoded arguments update in place.

L2 Calldata​

We also moved the Choose L2 Chains button into the Advanced Options section. L2 forward/reverse steps sometimes add extra calls (or different targets), and keeping them alongside the call-data preview makes it obvious what will happen. The calldata displayed also includes transactions that will execute on the L2 chain.

TLDR;​

• Enter your contract address.
• Pick a parent (e.g., myapp.eth) and type a label (e.g., router).
• Expand the Advanced Options section
• Expand the Call data section
• Copy the calldata

So head over to the Enscribe App, enter the details about the contract you want to name and inspect the calldata generated in the Advanced Options section.

Happy naming! 🚀

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

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

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

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

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

Using the Library​

Start by installing the library:

pnpm install @enscribe/enscribe  

Once installed, import the nameContract function:

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

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

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

We now create a wallet client object with wagmi:

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

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

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

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

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

• createSubname
• setForwardResolution
• setReverseResolution

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

Get started​

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

Happy naming! 🚀

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

Naming your contract from the CLI​

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

• subname creation
• forward resolution and
• reverse resolution

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

pnpm install @enscribe/hardhat-enscribe  

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

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

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

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

We can build our project with the following command:

npx hardhat build

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

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

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

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

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

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

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

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

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

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

This is what you’ll see in the output –

normalized name is mycontract.app.eth

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

Naming your contract from a Hardhat deployment script​

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

First, connect to the network and deploy the CounterModule:

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


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

Next, get the walletClient –

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

Now create a normalized name –

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

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

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

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

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

Parting Thoughts​

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

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

Happy naming! 🚀

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

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

At Enscribe, we couldn’t agree more.

Why Low-Risk DeFi Matters​

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

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

Names Over Hex​

This is why we created Enscribe.

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

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

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

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

Aligning With Vitalik’s Vision​

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

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

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

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

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

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

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

The Road Ahead​

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

Imagine a future where:

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

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

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

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

Happy naming! 🚀