We’re excited to share a new enhancement in Enscribe's “My Contracts” page that gives users more visibility and confidence around their verification of deployed smart contracts with Contract Verification Badges.

Smart contract verification is essential for transparency. It lets users and developers inspect the exact source code that’s running on-chain. Until now, finding all your deployed contracts and checking whether they were verified required manually opening Etherscan or other block explorers, copying contract addresses, and digging through multiple tabs.

With this update, Enscribe now shows verification badges next to every contract you’ve deployed — across both the Named Contracts and Unnamed Contracts tabs on the "My Contracts" page.

What You’ll See​

For each deployed contract, Enscribe checks whether your contract is verified on the major platforms:

• Etherscan
• Sourcify
• Blockscout

If verified, you’ll see a green-bordered badge labeled "Verified" for that platform. Clicking on this badge will take you directly to the verified record on the respective platform, where you (and your users) can inspect the source code, compiler details, and verification status like “Exact Match” or “Partial Match.”

If the contract isn’t verified yet, you’ll see a “Verify” label instead — which links to the verification page for that platform. This way, users can quickly take action without needing to search for the address manually.

Here’s a quick visual reference:

The Trust Layer: ENS + Verification​

We’ve also introduced a green shield check icon next to any contract that has:

• A Primary ENS name
• And Verified source code on at least one supported platform

This badge signals that the contract is both named and transparent — giving dApps, wallets, and end users a stronger trust signal.

Why This Matters​

Verification builds credibility. Naming adds discoverability. When paired together, they create a safer and more intuitive experience for Web3 users.

With the latest update, Enscribe now helps you:

• Easily confirm if your contracts are verified
• View verified source code with one click
• Quickly navigate to the platform if you still need to verify

It’s all about making security and trust more accessible — without disrupting your workflow.

Try It Out​

Visit the updated My Contracts page and explore the verification status of your deployed contracts. If any of them are missing verification, take a moment to complete it — and get one step closer to making your contracts trusted and verifiable.

As always, we’d love your feedback on this feature. We’re just getting started with trust layers in Enscribe, and your input helps shape what comes next.

For more details, visit our site, and don't hesitate to join our Discord community and Telegram group to share your feedback and experiences.

Happy Naming! 🚀

We’re excited to announce a new update to the “My Contracts” page on Enscribe. If you’ve ever deployed smart contracts and wished for a clearer, more structured way to manage and track them — especially across ENS names — this update is built just for you.

In this release, we’ve reimagined how developers interact with their deployed contracts by dividing the view into two clear categories:

1. Named Contracts - Contracts deployed by the user which have an ENS Primary Name
2. Unnamed Contracts - Contracts deployed by the user which doesn't have ENS Primary name

This makes it easy to monitor which of your contracts have verifiable identities through ENS, and which ones are still waiting to be named.

A Smarter Way to See Your Deployed Contracts​

Historically, developers had to use blockchain explorers such as Etherscan, or keep their own records as which contracts they've deployed. With Enscribe we're changing that.

The “My Contracts” page automatically surfaces all contracts directly deployed by your connected wallet. This includes both contracts deployed through standard Ethereum transactions (where the transaction "to" is null) and contracts deployed using CREATE2 via Enscribe.

One thing to note: we currently do not track indirect deployments — such as contracts created through another factory contract (internal contract creation calls). This is a planned improvement and is on our roadmap for upcoming releases.

Named vs Unnamed​

The page is now split into two tabs:

Named Contracts​

In the Named Contracts tab, you’ll find all contracts that have been deployed by your wallet and already have a Primary ENS Name. Each contract entry displays its ENS name, contract address, the transaction hash for creation, and direct links to tools like Etherscan, Chainlens, and the ENS App. This makes it easy to verify and share your named contracts.

We support Ethereum, Base and Linea mainnets and testnets.

Unnamed Contracts​

The Unnamed Contracts tab, helps you track contracts you’ve deployed that haven’t yet been named with ENS. Each entry includes the contract address and creation transaction hash, along with a contextual action button. Depending on the contract’s structure, this button will either prompt you to “Name Contract” (if it supports Primary Name assignment through Ownable/ERC-173/ReverseClaimer) or “Forward Resolve” (if only forward resolution is possible).

We’ve also added smart visual cues to guide you:

• A "yellow exclamation" icon indicates contracts that support only ENS forward resolution.
• A "green info" icon marks contracts that are eligible for full ENS primary name assignment.

Clicking on the action button takes you directly to the naming interface with the contract address pre-filled — allowing you to easily upgrade your unnamed contracts into trusted, named entities.

Fully On-Chain, Fully Trustless​

One of the most powerful aspects of our DApp is that it’s completely trustless. Enscribe doesn’t use a centralized database. All contract discovery, naming info, and status checks are done on-chain, directly from your connected wallet via RPC calls. This means no vendor lock-in, no stale cache, no single point of failure — just accurate, permissionless data every time you load the page.

Because we query the chain live, loading the full list of contracts happens asynchronously and can take a bit of time. While your contracts are being processed, you’ll see a spinner at the bottom of the table. Once loading is complete, the spinner disappears, indicating the tables are now fully up to date. This will be optimised soon.

See It in Action​

We’ve recorded a short walkthrough showing how the updated “My Contracts” page works and how you can use it to name your existing or new contracts instantly.

Watch the demo here.

The Takeaway​

This update turns Enscribe into more than just a naming tool — it’s now your command center for managing smart contract identity across Ethereum and Layer 2s. Whether you’re shipping production contracts or deploying testnet experiments, the new “My Contracts” page gives you a structured, intuitive way to understand what you’ve deployed and what still needs to be named.

Naming your contracts helps users trust them. It makes them recognizable in wallets, block explorers, and dApps. And now, managing that naming process is easier than ever.

For more details, visit our site, and don't hesitate to join our Discord community and Telegram group to share your feedback and experiences.

Happy Naming! 🚀

We’re thrilled to announce that Enscribe is now officially live on mainnet — across Ethereum, Linea, and Base networks.

Enscribe is a smart contract deployment and naming service purpose-built to bring human-readable identity to on-chain contracts. It allows developers to deploy contracts and assign ENS names — including subname creation, forward resolution, and reverse resolution (primary name) — all in a single, atomic transaction.

Until now, naming smart contracts using ENS was a fragmented and manual process that required interacting with multiple ENS contracts post-deployment. Enscribe abstracts that complexity entirely.

And yes — we’ve used Enscribe itself to name our production deployments.

Mainnet Deployments and ENS Names​

Ethereum Mainnet​

• Contract Address: 0xD14360D477EF49182B5141952FE67b007688725A
• ENS Name: v0.app.enscribe.eth
• Verified On:
  • Sourcify
  • Etherscan

Linea Mainnet​

• Contract Address: 0x6d8Ac46BFC1bD0b6022f997108e9800Fd84fdD44
• ENS Name: v0.app.enscribe.linea.eth
• Verified On:
  • Sourcify
  • Etherscan

Base Mainnet​

• Contract Address: 0x8429c428F93754449C4b955F2Ae9fde17eF4e95a
• ENS Name: v0.app.enscribe.base.eth
• Verified On:
  • Sourcify
  • Etherscan

We Enscribed Ourselves — Watch It in Action​

We used Enscribe to name our own mainnet deployments — and captured the entire flow.

Ethereum Mainnet​

Linea Mainnet​

Base Mainnet​

Name Your Contracts — Today​

This is a major step toward bringing trust and transparency to on-chain contracts through meaningful naming and identity. We’re excited to see what you build with it. Enscribe your contracts. Make them recognizable.

For more details, visit our site, and don't hesitate to join our Discord community to share your feedback and experiences.

Happy deploying! 🚀

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

We’re excited to announce a major refresh to the Enscribe Documentation — built to help developers and users better understand how ENS naming works for smart contracts and how Enscribe makes that process seamless.

Whether you’re deploying new contracts or assigning ENS names to existing ones, the updated docs walk you through every part of the experience with clear explanations, examples, and new video walkthroughs.

What's New?​

The updated Enscribe docs are now structured to cover both technical depth and usability, giving you exactly what you need depending on your goal.

The Enscribe docs are now divided into three major sections:

Introduction​

Get oriented. Learn what Enscribe is, why it exists, and how it bridges the gap between ENS and smart contract UX.

• What is Enscribe? - A high-level overview of the problem we’re solving.
• Overview of ENS - Understand how the ENS protocol works: Registry, Resolvers, Reverse Resolution, and more.
• Naming Smart Contracts - Why naming smart contracts is hard, and how Enscribe makes it simple.
• Supported Networks - Live Enscribe contract addresses across L1 and L2 chains like Sepolia, Base, and Linea.

Getting Started​

Everything you need to know to go from “I have a contract” to “My contract has a beautiful ENS name.”

• Contract Deployment Service - Learn how to deploy a contract with ENS naming in a single transaction.
• Naming Existing Contracts - Assign names and reverse resolution to contracts that already exist on-chain.
• Deployment History - Track previous deployments and view assigned names.
• Bytecode and ABIs - Understand how contract bytecode and constructor arguments are handled in Enscribe.
• The Operator Role in ENS, Why and How? - Get clarity on why operator permission is needed and how it’s securely managed by Enscribe.

This section is packed with video walkthroughs, UI screenshots, and interactive examples to help you get hands-on quickly.

Advanced (Coming Soon)​

For those looking to dive deeper into ENS internals, smart contract design, and Layer 2 nuances — the Advanced section will soon include:

• ENS Terminology - A glossary of ENS-specific concepts for developers and power users.
• ENS on L1 vs L2 chains - A detailed breakdown of how ENS behaves differently across Ethereum mainnet, Base, Linea, and other L2s.
• Design and Architecture - A full overview of the Enscribe contract system, including sequence diagrams, CREATE2 deployment flow, and ENS contract interactions.

Learn More & Dive In​

You can explore the updated docs and start deploying contracts with names you can actually remember.

For more details, visit our site, and don't hesitate to join our Discord community to share your feedback and experiences.

Happy deploying! 🚀

Deploying smart contracts with constructor arguments just got a whole lot easier with Enscribe.

Previously, if your contract required constructor arguments, Enscribe expected you to manually encode those arguments, append them to your compiled bytecode using external tools like Remix or Hardhat, and then paste that full bytecode into the UI. This approach was complex, error-prone, and completely unintuitive — especially for contracts with more than a simple string or uint.

We're excited to announce that Enscribe now supports native constructor arguments input in the UI. Now no manual bytecode editing is required.

What's New?​

With the latest update, users can now provide constructor arguments directly within the Enscribe UI.

There are two ways to do this. You can manually enter the argument types and values using a set of dropdowns and input fields, giving you full control over the structure and content. Alternatively, you can provide your contract's ABI. When you do, Enscribe automatically detects the number of constructor arguments, their names, and their types, and then generates the appropriate input fields for you to input the parameter values.

This streamlined experience allows you to focus on your contract logic, while Enscribe handles all the underlying ABI encoding and bytecode composition for deployment.

Manual Mode: Add Any Type, In Any Order​

You can add any number and type of arguments manually. Enscribe provides a dropdown list for all common Solidity types: string, uint8, uint256, address, bool, bytes, bytes32, string[], and uint256[]. Just add the argument, choose its type, and input its value.

For more advanced use cases, select Custom Type from the dropdown. This is where Enscribe really shines — giving you full control for struct-based inputs, tuples, arrays, and combinations of them.

Example: Arrays of Structs (Using Custom Type)

Let's say your constructor looks like this:

struct Person {
  string name;
  uint256 age;
  address wallet;
}

constructor(Person[] memory people)

Here's how you'd fill it out in Enscribe:

• Custom Type: tuple(string,uint256,address)[]
• Value: [["Nick", 30, "0x1bA43Becc3Ea96c37343b7CB18de7386bA29445B"], ["Jane", 25, "0x7cF7816d45398A1b37bBE517ca24d8CdFb8D042D"]]

Enscribe will automatically ABI-encode this value and append it to the deployment bytecode.

ABI Mode: Let Enscribe Do the Work​

If you paste or upload your contract's ABI, Enscribe will:

• Detect the constructor function
• Extract the parameter types and names
• Generate the input form fields automatically, where you just need to input parameter values

This is the recommended path for most users, as it:

• Reduces manual effort
• Prevents input format mistakes
• Makes the argument fields easier to understand

If your contract constructor is: constructor(string memory greet, uint256 initialCount)

Then Enscribe will automatically show two input fields: greet(string) and initialCount (uint256), and you just need to input parameter values.

Under the Hood: ABI Encoding and Bytecode Generation​

When you click Deploy, Enscribe automatically takes care of everything behind the scenes. It ABI-encodes your constructor arguments, appends them to the compiled contract bytecode, and sends the final result to the blockchain as a single atomic transaction. You don't need to worry about encoding formats, data padding, or bytecode structure — Enscribe ensures that everything is correctly formatted and deployment-ready.

Learn More & Get Involved​

Ready to deploy your contract with constructor arguments and assign it a primary ENS name? Try it now in the Enscribe UI and experience seamless contract deployment with human-readable identity.

For more details, visit our documentation, and don't hesitate to join our Discord community to share your feedback and experiences.

Happy deploying! 🚀

Hot of the back of our Linea Sepolia announcement, we're also supporting the Base Sepolia testnet!

Base, developed by Coinbase, is an Ethereum Layer-2 solution built on Optimism’s OP Stack, designed to deliver faster, cheaper, and more scalable transactions while preserving Ethereum’s security guarantees. Our integration with Base Sepolia provides a powerful new way for developers to effortlessly deploy smart contracts and immediately assign them Ethereum Name Service (ENS) names.

It also can be used to easily name existing smart contracts too.

With Enscribe’s new support for Base Sepolia, your smart contracts gain human-readable ENS identities instantly upon deployment, greatly enhancing their discoverability, verifiability, and usability.

How to Get Started​

Getting started with Base Sepolia on Enscribe is simple:

Visit the Enscribe App at app.enscribe.xyz

Connect your Ethereum wallet (Coinbase Wallet recommended for Base).

Select "Base Sepolia" from the available network options.

Deploy your smart contract and assign it a user-friendly ENS subname in just a few clicks.

Benefits of Using Base​

Base offers several key benefits over the Ethereum Mainnet:

Lower Transaction Fees: Benefit from reduced gas costs compared to Ethereum mainnet.

Fast & Efficient Transactions: Deploy and interact with contracts quickly and seamlessly.

Ethereum Compatibility: Deploy your existing Ethereum contracts with minimal changes required.

What's Next for Enscribe?​

With Sepolia, Linea Sepolia and Base Sepolia all supported, we're getting ready for our mainnet deployments for developers to really start battle testing the Enscrbie services.

On top of this we're going to be announcing our first partner integrations which you'll definitely want to watch out for. This will be a bit step forward in establishing greater trust in smart contracts for users.

In the meantime, make sure you have a go with our Base service and let us know what you think!

Learn More & Get Involved​

For more details, visit our documentation, and don't hesitate to join our Discord community to share your feedback and experiences.

Happy deploying! 🚀

We're excited to announce our latest milestone —  Enscribe has officially added support for the Linea Sepolia testnet!

Linea is an innovative Ethereum-equivalent zk-rollup solution developed by ConsenSys, designed to dramatically enhance Ethereum’s scalability. It also happens to be the layer 2 technology that the upcoming ENS Namechain will be built on. This integration brings quicker, cheaper, and more efficient transactions while retaining the strong security guarantees and decentralization of Ethereum.

With Enscribe's support for Linea Sepolia, developers can now easily deploy smart contracts directly to the Linea network and assign human-readable Ethereum Name Service (ENS) names at the point of deployment. This makes smart contracts easier to use, manage, and verify, significantly improving the overall user experience for both developers and end-users.

How to Get Started​

Getting started with Linea Sepolia on Enscribe is simple:

Visit the Enscribe App at app.enscribe.xyz

Connect your Ethereum wallet (MetaMask recommended for Linea).

Select "Linea Sepolia" from the available network options.

Deploy your smart contract and assign it a user-friendly ENS subname in just a few clicks.

Benefits of Using Linea​

Linea Sepolia offers several key advantages over the Ethereum mainnet:

Faster Transactions: Experience significantly quicker smart contract deployments and interactions compared to traditional Ethereum networks.

Reduced Costs: Enjoy dramatically lower gas fees, enabling more affordable smart contract development and testing.

Ethereum Compatibility: Effortlessly deploy existing Ethereum-compatible smart contracts without needing code modifications, providing a seamless transition to improved scalability.

Enhanced User Experience: Instantly readable ENS names eliminate confusion associated with cryptic hexadecimal contract addresses, improving clarity, trust, and overall usability.

What's Next for Enscribe?​

This integration with Linea Sepolia is just one step toward our broader vision of enhancing smart contract usability and trust across Ethereum and its vibrant ecosystem of Layer-2 solutions. We remain committed to supporting additional layer 2 network and continually improving our service based on community feedback and innovation.

We warmly invite you to explore Enscribe's Linea Sepolia integration and experience firsthand the future of scalable Ethereum deployments.

Learn More & Get Involved​

For detailed information, comprehensive guides, and further resources, visit our documentation. To join the conversation, share your feedback, or ask questions, connect with our team and community on Discord.

Happy naming! 🚀

This week marks the emergence of Enscribe from stealth. We've been working hard on it this past few months and are pleased to put it out into the wild.

At Enscribe, we're addressing a fundamental problem faced by nearly every Ethereum user: confusing and unreadable smart contract addresses. When initiating transactions, users are typically confronted with cryptic hexadecimal addresses, like this:

If users want to verify the contract they are interacting with (which anyone should), they have to copy the contract address and look at it another service such as Etherscan.

In Etherscan if it's a well known contract, such as the ENS ETH Registry Controller as in our example, it will have a label.

This is far from optimal. Users are relying on a centralised service, to verify the authenticity of a contract.

We believe smart contracts on Ethereum should be not be exposing their hexadecimal addresses to users and instead should be labelled with human readable names via ENS.

With ENS names, smart contracts gain identities similar to domain names, clearly indicating their creators. Imagine knowing at a glance that the contract you're interacting with was created by ens.eth. This simple clarity dramatically boosts trust and confidence during transactions:

Whilst ENS names and subdomains can be used to address smart contracts, this functionality is underutilised due to cumbersome tooling and the additional steps required to setup a primary name for a smart contract.

These hurdles are exactly what inspired the creation of Enscribe.

The Enscribe App​

We have deployed the beta version of our Enscribe App at app.enscribe.xyz which allows developers to deploy smart contracts to the Ethereum Sepolia testnet.

With the app, a user performs a single transaction which performs the following steps:

With Enscribe, naming contracts at deployment via ENS becomes seamless. When they deploy a contract using the app it:

• Creates a new subname such as v1.deployments.myname.eth
• Deploys the contract to Ethereum
• Registers the primary name

All these steps happen in a single transaction, ensuring that from the moment your contract is deployed, it’s immediately discoverable through its ENS name.

You can see it in action in the below video.

In addition to new contract deployment, you can also easily name your existing contracts using Enscribe.

To learn more about using Enscribe, visit our documentation.

Our team is currently hard at work expanding support to Ethereum’s Layer-2 networks and preparing for our upcoming mainnet launch.

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