Skip to main content

Easily Find Your ENS Names for Naming Smart Contracts

· 2 min read
Nischal Sharma
Enscribe Lead Engineer

We've rolled out a great new feature in Enscribe — the ability to easily choose your owned or managed ENS domains when deploying or naming smart contracts. This makes it straightforward to find the right ENS parent name you want to name your contract with.

Thanks to the integration with ENS Subgraph , Enscribe can now fetch all ENS names that your connected wallet owns or manages and show them to you.

How It Works

When a user connects their wallet, Enscribe queries the ENS subgraph and retrieves a complete list of ENS domains owned or managed by that wallet. These names are then:

  • Grouped by second-level domain (2LD)
  • Sorted alphabetically
  • Displayed in a modal

Demo

Check out the below video to see it in action:

Demo Video

Here’s how it looks in Enscribe:

Dropdown view inside Deploy form:

Dropdown Field

Choosing ENS Parent (modal):

ENS Domain Picker

Deploy Contract Form with ENS selection:

Deploy Form

Why It Matters

Before this update, users had to remember and manually type their ENS parent name — introducing user error.

This feature is currently supported on:

  • Ethereum Mainnet & Sepolia — via the official ENS subgraph
  • Linea Mainnet & Linea Sepolia — via ENS Linea subgraph
  • Base Mainnet — via ENS Node by namehash

Note: Support for Base Sepolia testnet is pending because no ENS subgraph exists yet. We're actively working with Namehash to add support — see GitHub issue #768.

Try It Out

Visit enscribe.xyz and try the new ENS parent selection workflow in both the Deploy and Name Contract flows. Let us know what you think — your feedback helps us shape a smoother, safer, and more trusted smart contract experience.

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

Be like Heroku - Introducing Auto-Generated ENS Names for Your Smart Contracts in Enscribe

· 3 min read
Abhijeet Bhagat
Enscribe Senior Engineer

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.

Label

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.

Deploy_contract

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.

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

Beyond Naming Smart Contracts

· 3 min read
Conor Svensson
Founder of Enscribe and Web3 Labs

What's Next After Naming Smart Contracts?

Over the past few months, we've been working hard to make it as easy as possible for developers to name their smart contracts using ENS. With support now live on Ethereum, Base, and Linea, we're starting to see steady adoption through the Enscribe app. But naming is just the first step in improving Ethereum's user experience.

Trust Through Transparency: Contract Verification

Once developers start giving their smart contracts ENS names, the next logical move is to help users assess how trustworthy a contract is. Our first focus here is verification.

We're surfacing contract verification data directly in the Enscribe app by pulling it from trusted sources like:

These verifications don't guarantee a contract is safe — after all, anyone can verify code—but they do indicate a baseline level of developer diligence. They also enable wallets and explorers to decode method signatures and provide users with more context about their transactions.

My Contracts view in Enscribe App

We've launched our initial support for verifications already. Here's a quick overview of the release, and you can see it live in the Enscribe App's "My Contracts" view.

On the Horizon: Audit Support

We're also turning our attention to audits. Smart contract audits are a key signal of trust, but surfacing audit data in a decentralised and verifiable way is still an open problem.

We're exploring how Enscribe can support this through:

  • Structured attestations for on-chain audit claims (e.g. EIP-7512)
  • Aggregation of verification and audit signals into a public API
  • Visual indicators in the Enscribe UI to make trust cues clearer

Imagine something like a TLS padlock for Web3 — a visual cue that gives users confidence they’re interacting with a verified, trustworthy contract, performed in a way that doesn’t require trusting any single service provider, including ourselves.

TLS padlock for enscribe.xyz site

A Trust Score for Contracts?

We're thinking through what a decentralized trust framework might look like. Some early metrics we're exploring include:

  1. ENS name assigned (via Enscribe or manually)
  2. Contract verified (Sourcify, Etherscan, Blockscout)
  3. Audits available (verifiable, on-chain attestations)

What else should be on that list? We're keen to hear your suggestions.

Beyond Devtool Integrations

You may have seen our recent updates on ecosystem calls with ENS DAO—we're making great progress toward integrating Enscribe directly into dev workflows (like Foundry). This will let developers name contracts automatically at deploy time, with zero extra steps.

But we're not stopping there.

We know many developers will continue using the Enscribe app directly to name existing contracts. So we're investing heavily in improving that experience too. Our aim is to reduce friction even further and make it delightful to manage your named contracts with Enscribe.

We'll be sharing more UX improvements and feature ideas very soon. In the meantime, if you're using Enscribe and have thoughts on what would make your experience better, drop into our Discord or tag us @enscribe_ on X.

We're just getting started.

In the meantime, keep naming those contracts!

Integration of Contracts Verification in Enscribe

· 3 min read
Nischal Sharma
Enscribe Lead Engineer

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:

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:

Verification badges in Named Contracts
Verification badges in Unnamed Contracts

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

How To Easily Name Your Existing Smart Contracts

· 4 min read
Nischal Sharma
Enscribe Lead Engineer

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.

Named Contracts Tab

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.

Unnamed Contracts Tab

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.

Loading Contracts

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

Enscribe Now Live on Ethereum, Linea, and Base Mainnets

· 2 min read
Nischal Sharma
Enscribe Lead Engineer

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

Linea Mainnet

Base Mainnet

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

ReverseClaimable and ReverseSetter Support for Naming Contracts with Enscribe

· 4 min read
Abhijeet Bhagat
Enscribe Senior Engineer

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:

ReverseClaimable deploy form

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

ReverseClaimable steps

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:

ReverseClaimable success

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.

ReverseSetter deploy

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

ReverseSetter steps

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:

ReverseSetter success

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

The New Enscribe Docs Are Live

· 3 min read
Nischal Sharma
Enscribe Lead Engineer

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

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

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

Easily encode Solidity constructor arguments with Enscribe

· 3 min read
Nischal Sharma
Enscribe Lead Engineer

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.

Enscribe Form

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 Form without ABI

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.

Enscribe Form with ABI

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

Enscribe Now Supports Base Sepolia Testnet

· 2 min read
Conor Svensson
Founder of Enscribe and Web3 Labs

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

Enscribe Base app

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.

Enscribe deployed smart contract on Base

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