Abhijeet Bhagat

At Enscribe, our mission is to make naming smart contracts with ENS as easy as possible.

Giving your contracts clear ENS names like alpha-vault.mainnet.eth or governance-proxy-123.mainnet.eth makes things easier to follow and remember.

However, there are times where you may want to do the naming yourself. Especially when you’re in the earlier phases of development. When you're deploying a bunch of contracts, the last thing you want is to pause and think of a unique name for each one.

That’s why we’ve added a fun new feature where Enscribe suggests a unique name for your smart contract for you.

Why Auto-Generated Names?​

Some of the older team members remember the first time they used Heroku to deploy web applications (remember them?). In Heroku, once your web application was live, it would give you a randomly generated DNS name for your app.

For the nostalgic among us, we thought it would be fun to do this in Enscribe!

Of course a lot has changed since Heroku, especially in today’s world of generative AI, which we could have used for name generation. However, we like the simplicity of mirroring the Heroku approach. After all, we’re here to simplify naming smart contracts for our users, and this fits nicely with that goal.

With our new auto name generation feature, Enscribe can create ENS-compatible names for your contracts on the fly. These names are:

• Unique (per deployment context)
• Memorable (generated from a curated dictionary of words)
• Compliant with ENS standards
• Directly assignable in one click during contract deployment or naming an already deployed contract

Best of all, you don’t even need an ENS name of your own to name your contract. If you don’t have one, Enscribe can name your contract with a unique name under deploy.eth on Ethereum, Base (deployd.base.eth) or Linea (deployd.linea.eth)!

How It Works​

On the Deploy Contract page, you’ll now see that a name has been auto-generated for your contract.

Next to it, you have a refresh button which you can use to generate a new name. Alternatively, you can simply put your own one in there.

If you do click on the name generation button it will propose a name such as:

• arrogant-baseball-6055
• weekly-heart-7993
• linear-garden-3758

You can then assign this name to your deployed contract immediately.

We’ve also enabled this feature on the Name Contract page so that you can set a name for your deployed contract.

Don’t Know What to Call It? Let Enscribe Help​

Whilst this is a small new feature, we believe it's important that we make it as easy as possible for our users to name their contracts. This now extends to supporting them with generating names and providing an ENS name if they don’t have one already.

You can try out the name generator by heading to the Enscribe App.

We'd love to hear your feedback on this feature — join our Discord community or Telegram communities and let’s eliminate hex smart contract addresses for users.

Happy naming! 🚀

Ethereum contracts are powerful — but to most users, they’re still just anonymous strings of hex. With Enscribe, we’re changing that. Today, we’re adding support for ReverseClaimable and ReverseSetter contracts, making it easier than ever to give your smart contracts a name that users and apps can actually recognise.

Whether you’re building a dapp, deploying infrastructure, or simply want your contracts to show up in wallets and explorers with real names instead of 0x addresses, Enscribe now supports flows that integrate reverse name claiming directly into your deployments.

This post walks you through both approaches — what they are, how they work, and how to use them in Enscribe today.

ReverseClaimable Contract​

When this contract is deployed, the account that is deploying this contract will be given the ownership of the reverse node for that contract address. For e.g., if the address is 0x123, then a reverse node is the name-hash of 0x123.addr.reverse. This will give you the authorization to set the name of the reverse node via a call to setName(reverseNode, name) method on the public resolver contract.

How to deploy a contract that implements ReverseClaimer​

Let's create a sample contract that implements ReverseClaimable:

import "@ensdomains/ens-contracts/contracts/registry/ENS.sol";
import "@ensdomains/ens-contracts/contracts/reverseRegistrar/ReverseClaimer.sol";

contract MyContract is ReverseClaimer {
	constructor (
    	ENS ens
	) ReverseClaimer(ens, msg.sender) {}
}

This contract requires the ENS registry address as the constructor parameter. You can find registry addresses for different chains here. After we compile the contract & paste its ABI on the Enscribe UI, we can enter the value of the parameter, label value as usual & select the ENS parent type:

Final step is to hit the Deploy button and complete the single step shown:

This will delegate the contract deployment & setting of primary name to the Enscribe contract. After the deployment & naming is successful, we see a dialog showing us the transaction details:

If a step fails after deploying the contract, instead of redeploying the contract (which will need eth), we can simply go to the Name Existing Contract page and change the name.

ReverseSetter Contract​

A ReverseSetter contract allows the name to be set only once - during its deployment. This is done by passing the name to the constructor of the contract:

contract ReverseSetter {
        /// @dev The ENS registry
        ENS private constant ens = ENS(0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e);

        /// @dev Output of namehash("addr.reverse")
        bytes32 private constant ADDR_REVERSE_NODE =
            0x91d1777781884d03a6757a803996e38de2a42967fb37eeaca72729271025a9e2;

        /// @param name The reverse name to set for this contract's address.
        constructor(string memory name) {
            IReverseRegistrar reverseRegistrar = IReverseRegistrar(
                ens.owner(ADDR_REVERSE_NODE)
            );
            reverseRegistrar.setName(name);
        }
}

How to deploy a ReverseSetter Contract​

As before, let's compile the above contract, copy & paste the bytecode, ABI values in the respective fields. We’ll also tick the box to tell Enscribe that our contract is a ReverseSetter.

The reason why we need to tick this box when deploying & naming a ReverseSetter contract is because there’s no way to differentiate the bytecode of a ReverseClaimable contract from that of a Reversetter contract. So, the onus lies on the deployer of the contract to tell Enscribe what kind of a contract they are deploying. Ticking this box will tell Enscribe to perform a different set of steps than the ReverseClaimable flow above to deploy & set the primary name.

Now, enter the full name of the contract in the constructor argument field. Let's also put the same label value in the label field & select the appropriate parent. Remember, the ‘name’ arg value should match the label & parent values.

At last, we hit the Deploy button & complete the single step shown:

In this case too, contract deployment & setting of primary name is delegated to the Enscribe contract. After the steps are completed, we see our success dialog:

If the deployment of the contract succeeds but naming fails, we can simply set the name of the deployed contract instead of redeploying it through the Name Existing Contract page.

With support for ReverseClaimable and ReverSetter contracts now live, Enscribe keeps pushing the smart contract experience closer to something that actually feels user-friendly. Whether you’re deep in the weeds of dapp development or just want your contracts to show up with proper names, there’s never been a better time to give it a spin. Try it out, see what sticks—and maybe finally retire that long string of 0x gibberish.

To learn more about using Enscribe, visit our documentation.

We'd love to hear your feedback and collaborate — join our Discord community and let’s build a clearer, safer Ethereum together.

Happy deploying! 🚀