Conor Svensson

When ENS Contract Naming Season launched, our goal was simple — to increase trust for users of smart contracts in Ethereum through contract naming with ENS. A few months in, we’re starting to see that shift take shape.

Teams across the ecosystem are naming deployed contracts, integrating ENS into deployment workflows, and treating contract identity as part of core infrastructure rather than an afterthought.

This post is a short update on why Contract Naming Season exists, what has changed so far, and what to expect next.

Why Smart Contracts Need Onchain Identities​

Despite significant progress in Ethereum UX, users still interact with unnamed hex addresses every day across explorers, wallets, governance tools, and DeFi applications.

That has real consequences:

• Security risks, including spoofing and address poisoning
• Poor usability, particularly for non-technical users
• Loss of context, where it’s unclear what a contract actually represents

Contract naming directly addresses these issues. It improves clarity, trust, and interpretability across the stack, while extending ENS usage well beyond EOAs.

Contract Naming Season exists to accelerate this shift through a combination of coordination, incentives, and tooling.

Protocols Are Naming Key Contracts​

One of the most encouraging outcomes so far is that contract naming is already happening in practice.

Multiple protocols have publicly announced contract naming efforts, with others actively in progress. In many cases, naming has been applied across entire contract suites, rather than single deployments.

At the time of publication, we’ve already shared updates about Cork, Liquity and Nouns DAO, with more to follow very soon!

This reflects a growing understanding that contract identity needs to be consistent, hierarchical, and maintainable over time. This is especially important for protocols, applications, and DAOs with long-lived infrastructure.

Contract Naming Takes Time​

It’s also worth noting that contract naming for established protocols is not an instantaneous process. For teams with mature deployments, multiple environments, and governance controls, lead times of two to three months are common.

This includes protocol wallet and contract inventory work, review of naming structures, multisig coordination, and, in some cases, governance approval. As a result, many naming efforts currently underway will surface gradually, and we expect the cadence of public announcements to increase as Contract Naming Season continues.

Tooling Has Caught Up​

Momentum around contract naming has been supported by meaningful improvements in tooling.

Since launch, Enscribe has shipped updates aimed at real-world protocol needs, including:

• Batch contract naming, to support large deployments
• Full Safe support, aligning with standard treasury and admin setups
• Calldata export, enabling review, coordination, and use with custom multisig workflows

On the developer side, we have integrated contract capabilities into Foundry and Hardhat via our developer plugins, reducing friction and making naming easier to adopt as part of standard deployment and maintenance processes.

Naming Audits​

A notable secondary outcome of Contract Naming Season has been the emergence of what teams are calling naming audits.

It can be challenging for teams to know where to start with respect to naming their existing protocol contracts and wallets. When we first speak to projects we often find:

• A lack of good ENS name hygiene
• No standardised approach to contract naming
• Relying on docs and GitHub repos to articulate key project contracts
• No naming of deployment and treasury wallets

With our naming audits, we help teams better understand their on-chain footprint and document it using ENS names. In addition we are using our learnings to help establish better practices about contract naming and versioning with ENS.

You can read more about how we approach them on our dedicated Naming Audits page.

What’s Next​

Contract Naming Season is moving into its next phase.

In the coming weeks, this will include:

• Further protocol announcements and outreach
• The first Contract Naming Season awards, with the first batch of $ENS distributions expected soon
• New category additions the ENS Awards Contract Naming Season leaderboard
• Continued improvements to Enscribe, including hierarchical name browsing and richer metadata support

Together, these steps are intended to reinforce contract naming as a normal and expected part of Ethereum infrastructure.

Looking Ahead​

If you deploy smart contracts, naming is a crucial component of how users understand and trust your protocol.

Contract Naming Season provides a practical opportunity to:

• Improve security and user confidence
• Make contracts legible across wallets, explorers, and applications
• Contribute to how smart contract identity evolves on Ethereum

The groundwork is in place, participation is growing, and the first recognitions are about to be distributed.

The best time to name your contracts was yesterday, the next best time is today.

Happy naming! 🚀

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

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

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

The ENS DAO has officially passed a proposal launching ENS Contract Naming Season — a new community initiative to bring names, identity, and trust to smart contracts across Ethereum.

What is Contract Naming Season?​

Contract Naming Season is a collaborative effort between the ENS DAO, Enscribe and others to help projects name their smart contracts using ENS names, turning unreadable hexadecimal addresses into human-readable, trustworthy names.

To encourage adoption, the ENS DAO has created a 10,000 ENS reward pool, offering incentives to teams that name their contracts and help lead others to do the same.

You can read the proposal on Tally for background.

Why it Matters​

Every time users interact with a smart contract, they’re asked to trust a long, meaningless hex address.

Not only does this make Ethereum harder to use, it leaves users exposed to address spoofing and phishing attacks from scammers.

Millions of dollars is lost every year to address spoofing and poisoning attacks on Ethereum.

Enscribe was created to address these issues. It’s a smart contract naming service built on ENS.

It allows developers and projects to easily name their smart contracts with ENS names. This creates human-readable, trustworthy identities for contracts, turning unreadable hexadecimal addresses into meaningful names.

Where it’s Happening​

Enscribe is live on Ethereum and integrates directly with ENS and contract verification platforms like Etherscan, Blockscout and Sourcify.

We've integrated with projects like Safe, Ethereum Follow Protocol and Open Labels Initiative to make contract naming a new standard for increased safety for Ethereum’s users.

Try it now: app.enscribe.xyz

How to Get Involved​

1. Join the conversation in the:

   • Contract Naming Season Telegram
   • Enscribe Discord

2. Check out our Best Practice Guides for:

   • Apps
   • DAOs
   • DeFi and Protocols
   • L2 networks

3. Start naming your contracts:

   • app.enscribe.xyz

When​

Contract Naming Season runs November 2025 → April 2026.

Reward distribution details will be announced soon — stay tuned!

Voices From the Community​

ENS has always been about empowering the Ethereum community to name and own their digital identities. Contract Naming Season continues that mission — helping developers, DAOs, and protocols give their smart contracts names users can trust.

— nick.eth, Creator of ENS

All smart contracts should be named onchain, for security, readability, and transparency. Contract Naming Season with Enscribe is a great opportunity to finally get it done.

— brantly.eth, Executive Director, Ethereum Identity Foundation, ENS DAO Delegate, ex-Director of Operations, ENS

Naming Season captures what makes ENS, DAOs and Ethereum special — community-led initiatives that drive our ecosystem forward! It’s actions like naming contracts that build the culture of safety and transparency we all depend on.

— james.eth, Fire Eyes DAO, ENS DAO Delegate

Named contracts upgrade security and enhance UX. Promoting awareness of contract naming opportunities across protocols, DAOs, and apps through Contract Naming Season is a key step forward for the Ethereum community.

— lightwalker.eth, NameHash Labs

Let’s Make Ethereum Safer​

Contract naming is a simple step every team can take to strengthen Ethereum’s foundation of trust and transparency. Let’s eliminate hex contract addresses and make human-readable contracts the new default.

Join the movement: app.enscribe.xyz

Happy naming! 🚀

Vitalik Buterin recently published an essay on low-risk DeFi, arguing that Ethereum’s long-term strength won’t come from chasing the highest yields or the flashiest innovations. Instead, it will come from protocols that are boring, safe, and dependable, akin to how Google’s simple search box became the foundation of the modern web.

The core idea is straightforward: the future of DeFi depends not on yield farming and perps trading, but on building resilient, accessible financial tools that normal people can actually trust.

At Enscribe, we couldn’t agree more.

Why Low-Risk DeFi Matters​

Most of DeFi today is still intimidating and opaque. Users are faced with hex contract addresses, complex front-ends, and endless warnings about scams or unaudited code. The reality is that even experienced developers struggle to keep track of what’s safe and what isn’t.

This is precisely the problem Vitalik is highlighting. Just as search unlocked the web by making it human-navigable, we need infrastructure that makes DeFi human-readable and transparent. Without it, only degens and developers will ever feel confident participating.

Names Over Hex​

This is why we created Enscribe.

Instead of interacting with 0x5c63…ef7a or some random string of characters, users should see names like the following when they use Uniswap or Aave:

• router.uniswap.eth
• eth-staking.aave.eth

Names build trust. They create clarity that hex addresses cannot. A simple ENS-based naming layer makes it obvious what you’re interacting with, reducing the cognitive load and risk of mistakes for users.

When contracts are named, the experience of DeFi starts, users begin to feel they have greater agency over what they’re doing and

Aligning With Vitalik’s Vision​

In response to our post on this very idea, Vitalik added an important companion point:

https://x.com/VitalikButerin/status/1970820664853741959

“This, and use fixed html page UIs on IPFS with onchain version control.”

That’s the other half of the equation. If contracts have an identity and aren’t simply hex addresses, we start building a DeFi ecosystem where trust can be earned through simplicity and durability.

Low-risk DeFi is about eliminating uncertainty at every layer:

• Names instead of hex addresses.
• Fixed, verifiable front-ends instead of mutable websites.
• Contracts with clear provenance and open verification.

Put together, this isn’t just “lower risk.” It’s a pathway to mainstream adoption.

The Road Ahead​

Enscribe isn’t about creating yet another shiny DeFi product. It’s about providing the naming and verification layer that lets the entire ecosystem evolve into something usable and trustworthy.

Imagine a future where:

• Every DeFi protocol publishes named, verified contracts.
• UIs are simple, consistent, and immutable.
• Audits and provenance records are tied to contract names.

That’s the infrastructure Ethereum needs to onboard not just the next million, but the next hundred million users.

Vitalik’s essay was a reminder that chasing complexity isn’t the winning strategy. The winners will be the builders who make DeFi boring, reliable, and safe.

At Enscribe, we’re betting that naming is a critical step in that journey.

Happy naming! 🚀

The Enscribe team is committed to finding value adding integrations for our users. We’re pleased to announce our latest significant integrations to the Enscribe app — support for the Ethereum Follow Protocol (EFP).

The Ethereum Follow Protocol (EFP) is a decentralized social graph protocol built on the Ethereum blockchain. 🤝

With its support in Enscribe, whenever you search for an account, for instance, vitalik.eth, you’ll now see their follower and following counts directly in the Account Details view.

You’ll also see EFP badges where available, along with links to their connected profiles on Farcaster, Lens, and other social platforms.

This gives every ENS-powered profile in Enscribe a richer, more human feel, and helps builders and users quickly understand how an account fits into the social graph of Ethereum.

The information is still supported by data about the ENS names associated with the account, so you now get the best of the ENS app and EFP in one place using Enscribe!

Why it matters​

Ethereum’s social layer is growing fast. But most wallets and explorers still treat onchain identities as flat and contextless. Enscribe already helps solve that by showing verified contract data and ENS names, rather than raw hex addresses.

Now with EFP, we go a step further with support for accounts, connecting the ENS names you see with meaningful signals of reputation and relationships.

You can now:

• See at a glance if an account is widely followed or active in the EFP ecosystem
• Discover who’s connected to who, all within the Enscribe UI
• Build trust faster when evaluating Ethereum addresses or ENS names

It’s a lightweight but powerful addition to the way we browse onchain identities.

What is EFP?​

EFP is an open, composable protocol for following Ethereum accounts. You can follow an ENS name, and see who they follow back, all onchain. It’s designed to be interoperable with wallets, dapps, and any app that wants to make identity portable and human-readable.

We believe this fits naturally with Enscribe’s mission to bring better UX, context, and trust to contract interactions.

What’s next​

With the EFP integration, we are surfacing useful account information for our users. With Enscribe’s mission to make smart contracts safer for users, it was important to find complementary teams focussed on providing similar services for accounts. This is why the EFP integration is so powerful.

In the coming weeks, we’ll be announcing some great new features for smart contracts, which help make services safer for users.

Until then, try it out by searching any account at app.enscribe.xyz. ENS names just got more social.

Happy naming! 🚀

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:

• Etherscan
• Blockscout
• Sourcify

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.

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.

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!

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