Abhijeet Bhagat

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

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

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

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

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

Creating a New Subname​

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

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

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

Using an Existing Name​

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

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

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

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

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

Simplifying Naming​

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

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

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

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

Happy Naming! 🚀

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

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

Unpacking the Dashboard​

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

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

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

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

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

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

Making Hex a Relic of the Past​

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

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

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

Happy naming! 🚀

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

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

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

A Friendlier Way to Explore Contracts and Accounts​

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

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

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

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

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

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

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

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

Why This Matters

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

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

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

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

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

Happy Naming! 🚀

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

Spot Your Primary Contracts at a Glance​

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

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

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

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

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

Introducing the “Name It!” Button​

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

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

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

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

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

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

Why These Changes Matter​

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

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

Happy naming! 🚀

We’re excited to announce that Safe smart account wallet support is now live in Enscribe. Whilst Enscribe already has support for commonly used wallets like Metamask and Coinbase, Safe was not fully compatible..

This update enables deploying a new contract and setting an ENS name for it or naming an existing contract with your Safe wallet with full control over transaction approval and execution.

Why Safe Wallet?​

Safe is commonly used as a multi-signature wallet in the Ethereum ecosystem. A Safe wallet account can have multiple Ethereum accounts configured as signers behind it. When a transaction is to be approved and executed, all signers must sign & execute that transaction.

This process can happen asynchronously without waiting for approvals from all the signers. This is unlike executing transactions with a wallet like Metamask where every transaction request will block until it is either approved or rejected.

It’s ideal for workflows where transparency and decentralized control are required.

What You Can Do with Safe in Enscribe​

Enscribe now enables you to:

• Deploy new contracts with ENS names set using your Safe wallet.
• Name existing contracts with ENS names from your Safe address.

Supporting Safe required a different approach from the typical MetaMask-style interactions, where each transaction prompts a popup that demands immediate attention. With Safe, Enscribe queues transactions, so they can be approved via the Safe App.

How to Connect to Safe Wallet in Enscribe​

Connecting to a Safe wallet is slightly different from connecting to Metamask or Coinbaser wallet. To connect to your Safe wallet, click on the Connect button on the top right corner on Enscribe:

On the Connect a Wallet popup, select WalletConnect

Now click on the OPEN button to open the WalletConnect modal

Click on Copy link and go to your Safe wallet app. Click on the WalletConnect icon on the top bar

Now paste the copied link in the Pairing code field in the popup

You should now see Enscribe as connected app

Once connected, you’ll see your Safe wallet account shown as connected in Enscribe as well as in the Safe App.

Kicking off Transactions​

With Safe wallet, our naming-related transactions are sent to the Safe wallet queue without waiting for them to complete. This is because Safe wallet intercepts our Enscribe transactions & executes them in its own multisig transactions. Therefore, Enscribe doesn’t have knowledge of these transactions whilst pending.

Enscribe differentiates between a Safe wallet and a wallet like Metamask and will modify the behavior of waiting for transactions to complete accordingly. This is how pending transactions look like in the Safe wallet:

On executing the above pending transaction to set the primary name of a contract, we can see the contract details in Enscribe:

We can also rename the contract we just deployed. Let’s say we rename it to safewallet13.testapp.eth. Like before, two transactions - setting forward resolution and setting reverse resolution - will be kicked off in the Safe wallet app:

And we see two transactions in the Safe wallet app that we can bulk execute:

We see our contract now has a new name:

Having full support for Safe ensures that teams protecting key contracts with a multisig can properly name their contracts with Enscribe.

If you have Safe controlled contracts you wish to name, you can try naming your contracts with Safe wallet at app.enscribe.xyz!

Happy naming! 🚀

One of the core objectives of Enscribe is to make smart contracts safer for users. Our latest feature builds on that objective by connecting Enscribe contract details with the Open Labels Initiative (OLI), a project focused on providing smart contract labels via attestations.

What Is the Open Labels Initiative?​

The Open Labels Initiative is a standardized framework and data model for address labeling. Think of OLI as a public bulletin board for contract facts — users can attach signed statements, called attestations, to a contract address. These attestations, also referred to as labels, might indicate different bits and pieces of information such as the Owner Project, Category, Subcategory, etc. Here’s a sample of smart contracts and their labels from labels.growthepie.com:

Attestations on OLI are public and verifiable. Anyone can view them, and anyone can contribute new ones enabling community contributions to the initiative. OLI helps surface credible, onchain or offchain information about contracts.

How does this help Enscribe users?​

On every Contract Details page in Enscribe, you’ll now see a new section “Contract Attestations”, under this will be a button ‘Label on OLI’ (or ‘Labelled on OLI’).

In the above image, we see the contract information as usual and the ‘Labelled on OLI’ button since this contract has attestations.

If attestations exist for a contract, clicking the button opens the contract’s attestation page on the OLI website. There, you can review attestations that have been made about the contract such as who made them and time of the attestations.

If no attestations are present, the same button will now say ‘Label on OLI’:

Clicking on the button will take you to the attestation submission form. The contract address and chain is pre-filled, so you just need to add any additional information on the attestation submission form.

Enscribe’s mission is to make Ethereum safer for users by making apps more trustworthy and easier to navigate. Open, permissionless labels help build trust in contract usage and protocol adoption. Integrating with OLI means anyone can check a contract’s reputation or contribute to its public profile.

To try it out, visit any contract details page on Enscribe and click the OLI button to either see the attestations or add one using the attestation submission form.

Happy naming! 🚀

We're pleased to announce a small but powerful enhancement to Enscribe: the Contract Details page now includes a link to its deployer's address, taking you directly to the deployer’s account page within Enscribe. This feature, while subtle, reinforces our mission to make smart contracts more trustworthy, transparent and traceable.

At its core, Enscribe is about increasing trust for users when interacting with smart contracts and making it simple for users to see information about the safety of contracts. It’s not enough to simply display contract metadata — users should also understand where the contract is coming from, which is why we believe ENS names for contracts are so important.

We also believe users should be able to see which account deployed it.

By displaying the deployer address, we provide additional insight into the provenance of a contract. It links the contract back to its deployer, which helps verify authenticity and allows users to view the deployer account details without using block explorers.

Previously, users would have to manually copy the contract address and search for the deployer using a block explorer or a separate tool. With this update, Enscribe removes that friction. Now, you’re just one click away from understanding more about the deployer.

On the Contract Details page, you’ll now see the Contract Deployer field. This contains a hyperlink to either:

• The deployer’s ENS name, if one exists (e.g., app.enscribe.eth) OR
• The raw Ethereum address if no ENS is set (e.g., 0xb21170472acc742d2e788904641c9d4c76261a84)

Clicking the link takes you directly to the Enscribe Account Details view for that address. There, you can explore all contracts deployed by the account, their metadata, and any human-readable labels we've indexed.

In addition, thanks to our recent Ethereum Follow Protocol integration you can also see the social graph and profile associated with the account.

This great new feature is especially helpful for:

• Users who are interested in tracing contract provenance
• Developers tracking deployments across testnets and mainnet using ENS names
• Users verifying that a contract comes from a trusted deployer

This is one of many features we’re rolling out to improve contract legibility on Enscribe.

Happy naming! 🚀