Abhijeet Bhagat

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

Foundry and Alloy are foundational tools in the smart contract development stack, and we want smart contract naming to be integrated into all core developer workflows.

Foundry is referred to as the smart contract development toolchain while Alloy, used by Foundry as a dependency, provides a range of functionality for interfacing with any Ethereum-based blockchain.

Before Alloy, there was ethers-rs, which became deprecated in favour of Alloy. It had a small ENS utility crate support that was added in Foundry. The Enscribe team recently migrated this ENS crate over to Alloy from Foundry.

By extending Alloy and Foundry with ENS-focused tools, we're making it easier for developers to use these tools and enabling them to easily name their smart contracts. With the recent merge of PR #2676 in the Alloy codebase, reverse resolution, a critical part of smart contracts naming, just got simpler.

This update introduces support for retrieving the ENS Reverse Registrar address using the ENS Registry. That’s the key contract responsible for mapping an Ethereum hex address back to a name like v0.app.enscribe.xyz.

Why Reverse Resolution Matters​

Forward resolution (e.g., alice.eth → 0xabc...) is familiar. But reverse resolution (0xabc... → alice.eth) is what allows user-interfaces to show names instead of raw addresses.

Under the hood, reverse resolution works by:

• namehashing the address (as addr.reverse),
• querying the ENS registry for the resolver, and then
• calling name(node) on the resolver.

This PR makes that logic easily accessible via the EnsRegistry::owner method, allowing you to fetch the reverse registrar address directly using the ENS registry..

Simple Integration​

With this change, any Alloy-based app or library can now perform Reverse Registrar discovery. Here’s the high-level call pattern in Rust:

let provider = ProviderBuilder::new()
    .connect_http("https://reth-ethereum.ithaca.xyz/rpc".parse().unwrap());

let rr = provider.get_reverse_registrar().await?;
assert_eq!(rr.address(), address!("0xa58E81fe9b61B5c3fE2AFD33CF304c454AbFc7Cb"));

Once you have that address, you can construct a ReverseRegistrarInstance and query names from addresses or just interact with the ReverseRegistrar contract however you like.

On the Road to Contract Naming Support in Foundry​

This PR is a small but crucial step toward full ENS tooling support in the Alloy and Foundry ecosystem. By baking in access to one of the core ENS smart contracts like the Reverse Registrar, we make it one step closer to naming your smart contracts with Foundry.

Happy naming! 🚀

We believe naming a smart contract is vital for improving the UX and security for users of Ethereum apps.

At Enscribe, to reward our early users, we’ve created our first POAP drop! Now, every time you successfully name a smart contract using Enscribe, you can mint an exclusive, limited-edition POAP to show you’re one of the early namers of smart contracts.

Here’s a video tutorial demonstrating how you can claim your POAP:

You can also easily announce your contract name on X and Farcaster via our brand new sharing buttons.

POAPs are unique, verifiable badges that live onchain, just like the contracts you’re naming. Now, each naming via Enscribe can be marked with a minted POAP, serving as both a personal achievement and a public badge of your contributions to the Ethereum ecosystem.

But hurry, this POAP drop is limited and won’t be available forever.

To access the POAP, head to the contract naming page in the Enscribe App.

Once you complete the naming process for a contract on Enscribe, you’ll see the completion dialogue showing details such as the transactions performed, contract address, ENS name and our new buttons!

Simply click the Claim my POAP to mint your POAP. This will take you to the POAP App where you can mint the POAP by putting your email address or Ethereum address for free.

If you fancy sharing that you named your contract using Enscribe App on X or Farcaster, that would be massively appreciated too. We need our users to spread our message throughout the Ethereum ecosystem.

In the meantime, head to the Enscribe App to name your contract and claim your POAP to show you were there in the beginning!

Happy naming 🚀.

In Enscribe, we want to improve and simplify the user experience for contract naming. That includes how users view the ENS names associated with their own wallets.

We’ve introduced a great new update to the Enscribe app: the My Account view, accessible directly from the left-hand navigation menu. With this feature, users can now easily see the ENS names linked to their wallet address in a single click, without having to search manually.

Previously, if you wanted to check which ENS names your wallet address owned—or what contracts had been named using your account—you had to:

• Manually copy your wallet address
• Paste it into the Enscribe search bar
• Click the result to open your wallet address view

Now, that entire flow has been replaced by a simple, direct entry point: My Account menu option.

With this you can quickly see which ENS names your account owns as well as any associated ENS names:

1. Open the Enscribe app
2. Log in to your wallet and select a chain
3. Find My Account in the left-hand navigation bar
4. Click to view all the ENS names associated with the wallet data

You no longer need to copy and paste your address in the Search bar, just click on My Account and it automatically all your associated ENS names based on the connected address and active chain.

Head over to https://app.enscribe.xyz to easily see which ENS names your wallet address owns!

Happy naming 🚀.

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