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 Clarity​

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

User Assurance​

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

Enscribe’s Role​

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

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

Long-Term Maintainability​

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

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

Name Your Contracts. Strengthen Your Protocol​

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

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

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

Happy naming! 🚀

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

Why Batch Naming?​

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

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

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

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

How Batch Naming Works​

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

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

The Technical Flow​

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

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

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

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

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

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

Parent Subdomains Support​

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

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

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

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

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

1. Navigate to Batch Naming​

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

2. Choose Your Parent Domain​

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

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

3. Add Your Contracts​

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

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

Validation Features:

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

4. Advanced Options: L2 Chain Selection​

Expand the Advanced Options section to configure L2 primary names.

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

• Optimism
• Arbitrum
• Base
• Scroll
• Linea

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

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

5. Review and Submit​

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

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

6. Execute Transaction Steps​

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

Step Progress:

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

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

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

Limitations and Considerations​

Prerequisites​

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

Gas Considerations​

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

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

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

Try Batch Naming Today​

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

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

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

Happy batch naming! 🚀

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

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

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

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

1. Create a new project:

   forge init counter
   cd counter
   

2. Install the Enscribe plugin:

   forge install enscribexyz/enscribe
   

3. Install openzeppelin:

   forge install OpenZeppelin/openzeppelin-contracts
   

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

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

5. Make Counter implement Ownable:

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

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

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

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

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

You can now view the deployed contract in Enscribe app:

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

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

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

Give it a try.

Happy naming! 🚀

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