8 posts tagged with "perspectives"

Identity is often framed as a feature​

Over the past year working on Enscribe, we have noticed that identity is often discussed as if it were a product capability. A wallet "adds identity support," a protocol "integrates ENS," and an explorer "improves labels." The framing implies that identity is something a single team can implement and ship, like a new dashboard or API endpoint.

The reality is more complicated. Onchain identity is not a feature that one layer can solve in isolation. It is a property that emerges from how protocols, wallets, explorers, naming systems, and users behave collectively.

Without support across those actors, identity weakens.

Protocol teams control the raw material​

Builders of onchain protocols and apps sit closest to the source of identity. They deploy contracts, manage multisigs, upgrade proxies, and control treasury wallets underpinning their project. They are in the best position to provide human-readable names for their addresses, create primary ENS records, and maintain metadata that ties their ENS root to a website or public presence.

An extract of the Uniswap docs showing their hex smart contract addresses

If that work is skipped or treated as optional, wallets cannot reliably compensate for it later without building their own service, or relying on some form of centralized labeling.

Wallets can display what exists, but they cannot invent canonical identity where none has been declared by the team establishing those onchain assets.

In my experience, this is often where the gap begins, not because teams are careless, but because identity is treated as secondary to shipping core functionality.

Wallets decide what users actually see​

Wallets sit at the moment of decision for users. They are used to interact with protocols and perform onchain activity. Wallet interfaces decide whether an address is presented as a hex string, a label, or a canonical name. They translate raw onchain data into human judgment.

Some wallets such as Metamask use labels from Etherscan for smart contract identities

If wallets default to their own heuristics, or treat identity as nice to have rather than authoritative, they dilute whatever discipline a protocol team has applied upstream. In some cases, wallets become the de facto identity layer, which was never the intention.

This is not necessarily a flaw in wallet design. It is often a pragmatic response to low adoption of identity and naming practices by protocol teams. It does, however, highlight the shared nature of the responsibility.

Explorers fill the gaps​

Blockchain explorers often step in to provide additional context for users. Labels are added, sometimes manually and sometimes through internal processes that are opaque to most users. Those labels are helpful, but they are not canonical.

Blockscout shows both ENS names for contracts and labels

Ironically, the more reliable those labels appear, the less pressure there is for protocol and app teams to configure identity properly in the first place. The ecosystem quietly shifts toward soft signals, which in many cases are centralized rather than protocol-level assertions.

Over time, that creates a system where identity feels present, but is not deterministically anchored or guaranteed.

This also keeps the barrier to using onchain applications high. Without intuitive, human-readable identities, onchain systems are harder for new users.

No company would present users with IP addresses to access web applications, yet hexadecimal addresses for wallets and contracts remain common in onchain interfaces.

The coordination problem​

There is a clear technical solution to much of this in ENS. It provides forward resolution, primary names, and metadata that teams can set for protocols.

The Enscribe App provides an aggregated view of smart contract identites using onchain data

Wallets can surface those records. Protocols can declare canonical names. In principle, the pieces fit together.

In practice, each actor optimizes locally. Protocol teams focus on code and audits. Wallet teams focus on interface design. Explorers focus on discoverability. Naming systems provide primitives without enforcing norms.

Each decision is rational in isolation. Collectively, they produce ambiguity for users.

A common response is trying to combine every function into a single application with smooth UX, often at the expense of decentralization.

The internet did not face this exact problem at the same scale with DNS, partly because academic and government institutions collaborated to establish shared infrastructure early. Onchain infrastructure has developed with stronger commercial fragmentation, which makes coordination harder.

Shared responsibility requires norms​

In my view, this is why identity should not be framed as a feature. Features are owned by one team. Shared infrastructure requires widely adopted standards and operating norms.

Protocol teams need to treat naming and metadata as part of deployment. Wallets need to treat canonical identity declarations as authoritative signals rather than optional enhancements.

Explorers need to be explicit about the difference between labels and identity. Naming systems need to reduce friction in establishing primary names.

None of this requires new primitives. It requires alignment.

As systems grow more complex and more actors interact with them, ambiguity compounds. At some point, identity stops being a convenience and becomes a prerequisite for safe coordination.

That shift will not happen because one team ships a feature. It will happen when enough teams decide that identity is not someone else's problem.

When teams talk about shipping securely onchain, audits usually dominate the conversation. Deployment scripts are reviewed carefully, contracts are verified and monitoring is configured.

Naming rarely receives the same attention.

It is often treated as administrative overhead, something to tidy up once the important work is done. A label in a block explorer. An ENS record configured after launch. A task that can wait.

In practice, naming is not decoration, it is crucial operational infrastructure. If someone outside your core engineering team cannot look at your onchain footprint and understand what belongs to your protocol, which version is current, and which addresses control upgrades or funds, identity is not yet doing its job.

Over time, a small set of recurring mistakes appears. They are usually the result of sensible teams focusing on other priorities, but they compound.

Treating naming as an afterthought​

The most common issue is timing. Projects deploy, audit and verify their contracts, but then naming is postponed.

This happens because deployment pipelines are designed around bytecode, not identity. Foundry or Hardhat scripts focus on signing contract bytecode and constructor arguments. There is rarely a step that enforces canonical identity before release.

As a result, naming becomes manual and optional. It depends on someone remembering to configure forward resolution, set primary names where feasible, and update documentation.

If naming is not incorporated into deployment workflows, it drifts. Multiple ENS names may end up pointing to the same address. Primary names may never be set. Version migrations become harder to reason about.

The solution is straightforward, but requires discipline. Naming should be part of the release checklist. If you are using Foundry or Hardhat, identity configuration should sit alongside verification and post-deployment validation. Tooling can help automate this, but the important shift is cultural. Identity must be treated as part of shipping.

No version namespace​

Many protocols deploy successive versions of contracts without creating a clear namespace for each release. Names end up flat and loosely related. Over time, it becomes difficult to see which contracts belong together and which are legacy.

A cleaner pattern is to introduce a version namespace and group contracts beneath it. For example, a protocol might create a root such as v2.protocol.eth and then register contracts under it:

• vault.v2.protocol.eth
• controller.v2.protocol.eth
• timelock-admin.v2.protocol.eth

This structure communicates code hierarchy. It makes migrations clearer and allows older versions to remain visible without confusion. It also makes scanning a set of contracts in a wallet or explorer simpler.

Without a namespace, every contract name competes at the same level. The system may still function correctly, but it becomes harder to reason about, especially for users, researchers, and auditors who are not involved in day-to-day development.

Naming contracts but neglecting identity metadata​

Having an ENS name is not sufficient on its own. The root name must carry context about your project or protocol.

If someone visits your primary ENS name, what do they see? Is there a link to your website? Are social handles present? Is there descriptive text explaining what the name represents? Does it clearly appear to belong to your organisation?

An ENS name without metadata is technically configured, but socially ambiguous.

This becomes especially relevant when the most obvious handle is unavailable. A protocol may not control project.eth and instead use something like project-labs.eth or protocol-xyz.eth. There is nothing wrong with that decision, provided it is clearly established as canonical.

The important question is not whether you own the shortest possible name. It is whether the name you do use is visibly tied to your organisation across surfaces. Some projects reinforce this by linking their ENS name from their website, social profiles, and documentation, creating a coherent identity that connects DNS, ENS, and public presence.

Without those proof points, users are left to infer authenticity. For example, in the case of Enscribe, our DNS name enscribe.xyz on ENS is managed by enscribe.eth demonstrating a relationship between the two records.

Assuming forward resolution is enough​

Forward resolution solves discovery. It allows a name to point to an address. It does not, on its own, eliminate ambiguity unless an address points back to that name via a reverse registry.

If multiple names resolve to the same address and no primary name is declared, interfaces must choose what to display. That choice may rely on heuristics, namespace assumptions, or external labels.

Primary names provide a stronger guarantee because they are unique per address within ENS. Where feasible, setting a primary name establishes a canonical identifier and reduces reliance on interpretation.

Treating forward resolution as sufficient leaves identity partially defined. It increases the likelihood that wallets and explorers rely on inference rather than on explicit declaration.

Forgetting wallets and control surfaces​

Logic contracts tend to receive the most attention because they encode the core behaviour of a protocol. In practice, some of the most sensitive components of a system are not logic contracts at all.

Timelocks, multisigs, upgrade managers, guardians, treasury wallets, fee collectors, and even deployment wallets often carry more operational risk than the contracts they control. They hold authority over upgrades, parameter changes, and funds.

These addresses are frequently left unnamed or inconsistently labelled. A protocol may carefully name its vaults and controllers, while the multisig that can upgrade them remains a bare hexadecimal string in a wallet.

If identity is meant to help users, auditors, and governance participants understand the system, it cannot stop at user-facing contracts. It must cover every address that has meaningful control or financial significance.

Complete coverage is the goal. Naming only the obvious contracts leaves the most powerful components of your protocol opaque.

Naming as operational discipline​

Naming mistakes rarely cause immediate failure, but they do create friction. They make audits harder to interpret. They make migrations more confusing, and make incident response slower. It also compounds over time.

A robust naming strategy is not about naming a few contracts. It is about complete identity coverage. Every contract, every governance address, every multisig, and every deployment or treasury wallet that matters to the system should be legible.

If you had to respond to an incident tomorrow, could an external auditor, integrator, or governance participant look at your onchain footprint and understand:

• Which contracts belong to the current version?
• Which addresses control upgrades?
• Which wallets hold authority or funds?
• Which ENS name is canonical for your organisation?
• How your DNS domain, social presence, and ENS identity connect?

If the answer is unclear, naming is not yet infrastructure, you only have partial coverage.

Audits protect logic, monitoring protects uptime, naming protects users.

Treating identity as part of deployment, and ensuring complete coverage across contracts and wallets, is a small operational shift, but it materially improves how your system is understood, governed, and trusted.

Security audits are an essential part of deploying production-grade smart contracts. They review logic, identify vulnerabilities, and reduce the likelihood of catastrophic exploits. For serious protocols, audits are a core component of their security framework.

What audits do not do, however, is establish identity.

There is a persistent assumption in the ecosystem that an audited contract is, by virtue of being audited, protected from impersonation. That assumption conflates two separate concerns: whether a contract behaves correctly, and whether a user is interacting with the intended contract in the first place.

Audits address the first question, but they do not address the second.

What an audit actually verifies​

A smart contract audit evaluates a specific codebase at a specific address and at a specific point in time. The auditor reviews the source code, analyses potential vulnerabilities, and produces a report documenting risks and remediation steps.

The output of that process increases confidence that the contract, when interacted with, behaves as expected. It reduces the probability of reentrancy bugs, arithmetic errors, or flawed access control logic.

But the scope of an audit is akin to a code review. It does not extend to naming, discoverability, or identity.

If an attacker deploys a separate contract using identical source code at a different address, the original audit does not prevent users from interacting with the impersonator. The code may appear identical. However, the difference is in the deployer and configuration of the contract.

A real-world pattern​

A recurring incident pattern looks like this.

A protocol launches a core contract that has been audited and widely publicized. The address is shared on social media, added to documentation, and integrated into frontends.

Shortly afterwards, a copycat deployment appears.

The malicious contract may:

• Use the same verified source code
• Expose identical function signatures
• Carry a similar or near-identical name
• Be deployed on the same network

To users browsing a block explorer, the contracts can look almost indistinguishable. Both are verified, reference the same code repository, and appear secure.

The only meaningful difference is the address.

From a purely audit perspective, nothing is wrong. The code is safe. The logic is sound.

But if a user interacts with the impersonating contract, perhaps because it was shared in a Telegram group, surfaced in a token list, or appeared in a wallet suggestion, the audit offers no protection.

The risk shows up at signing time: users can approve or send funds to the impersonating address because interface signals look legitimate.

This problem is not unique to onchain systems. There are parallels with phishing on the web, where copies of legitimate websites are spun up with malicious code or software to prey on unsuspecting users.

Code assurance is not identity assurance​

Code assurance answers the question: if I interact with this contract, will it execute safely?

Identity assurance answers a different question: is this the contract I intend to interact with?

Smart contract audits operate almost entirely at the first layer. They provide confidence in execution. They do not create a canonical, onchain assertion that binds a human-readable identity to a specific address.

Without that binding, identity is inferred through softer mechanisms. Explorer labels, verified source files, and social reputation fill the gap. These are useful signals, but they are not protocol-level guarantees.

The result is a subtle but important security gap. A contract can be fully audited and yet remain vulnerable to impersonation if users cannot reliably distinguish its address from lookalikes.

Where identity infrastructure fits​

This is where identity infrastructure becomes relevant.

If a contract declares a primary ENS name, that declaration provides an explicit, onchain assertion of identity within the ENS namespace. Wallets and interfaces can use that signal to replace hexadecimal addresses with canonical names at the point of interaction.

An impersonating contract cannot legitimately assert the same primary name unless it controls the underlying ENS record. The security model shifts from "which address looks familiar" to "which address has formally declared this identity."

Identity controls therefore complement audits by covering a separate failure mode: impersonation at the point of interaction.

Why the misconception persists​

The confusion persists because "audited" has become shorthand for "secure." In practice, that shorthand collapses multiple dimensions of security into one label.

Protocols announce audit completions as milestones, and rightly so. But over time, audit status becomes conflated with overall trustworthiness. The nuance that audits do not address identity is rarely emphasized.

As long as identity remains discoverable only through heuristics or offchain labeling, audited contracts can be mimicked convincingly enough to mislead inattentive users.

A more complete security model​

As the ecosystem matures, it becomes useful to think of smart contract security as layered:

1. Code correctness and exploit resistance
2. Operational governance and key management
3. Identity and discoverability

Audits focus on the first, but do not solve the third.

If identity remains weak, the overall system remains fragile at the interface layer, regardless of how robust the underlying logic is. This is especially problematic for end users.

Audits test execution correctness. Identity controls reduce impersonation risk by helping users verify they are interacting with the canonical deployment.

For production contracts, publish audit reports and attach them to ENS names so users can validate both code quality and contract identity in one place.

This workflow is now live in Enscribe, including support for attaching audit reports to ENS names for smart contracts. If you head to our Name Explorer you can see more.

ENS supports two ways of associating names with addresses.

1. A name can forward resolve to an address (myname.eth -> 0x1234…).
2. An address can declare a primary name which contains a forward resolving address record and a reverse record that points back to the name (0x1234… -> myname.eth).

It’s important to be aware of this distinction between forward resolution and primary names as it defines a security boundary within ENS.

Especially as smart contract identity becomes more visible in wallets and other key infrastructure.

Primary names are definitive​

A primary name is unique per address. An externally owned account or a smart contract can declare exactly one ENS name as its primary identifier.

0x1234… -> myname.eth

When configured correctly, that declaration establishes a canonical mapping from address to name. If a wallet encounters the address and retrieves a valid primary name, there is no ambiguity about which ENS name represents it. The address has explicitly asserted its ENS identity.

This matters because identity is often needed in the reverse direction. Users do not typically begin with a name and look up an address. They encounter an address first in a transaction confirmation screen, governance proposal, or contract interaction. At that moment, the system must decide whether it can replace the hex string with something human-readable.

Forward resolution is not the same thing​

Forward-resolving names work the other way around. A name resolves to an address. If someone types the name into a resolver, they receive the correct destination.

myname.eth -> 0x1234…

This is closer to traditional DNS behaviour. A domain name resolves to an IP address. Reverse DNS exists, but it is inconsistently configured and rarely treated as authoritative identity. Many IP addresses either lack reverse records or have generic ones. As a result, reverse DNS is not widely relied upon as a definitive signal of identity.

In addition, the resources that DNS records point to are ephemeral —  web services come and go, their IP addresses are changing as this happens. Wallet and smart contract addresses are permanent — they exist as long as the blockchain they reside on does.

Forward-only resolution in ENS has a similar limitation. A name resolving to an address does not mean the address stands behind that name as its identity. It simply means the name points there.

Multi-naming systems​

There is an additional subtlety here. Reverse resolution in ENS is specific to ENS itself. If you perform a reverse lookup on an address, you are querying the ENS reverse registry. That lookup assumes ENS is the naming system associated with the address.

In a multi-naming-system world, a reverse record is only authoritative within the scope of the naming service you are querying. This makes the primary name declaration unique to ENS and authoritative within its namespace, but not universally global in the way IP-to-domain relationships are sometimes perceived to be.

That distinction reinforces why primary declaration matters. Within ENS, it provides a canonical answer. Outside of it, identity depends on which naming system an interface chooses to trust.

Ambiguity in forward resolution​

Consider a protocol that deploys a contract at a single address and ends up with several ENS names pointing to it:

• v1.protocol.eth -> 0x456…
• core.protocol.eth -> 0x456…
• vault.anotherprotocol.eth -> 0x456…

All three forward-resolve to the same contract, two are from one ENS namespace, another from an entirely separate one.

From a naming perspective, they could be viewed as labels that cater for different end-users. From a wallet’s perspective, it creates a problem. When the wallet encounters the address first, which name should it display, or even trust?

Without a primary name declaration, there is no protocol-level answer. Interfaces must rely on heuristics. They may look at other names associated with ENS names in the same namespace, or other more sophisticated reasoning models looking at activity of the different domains.

In some cases they may fall back to explorer labels or simply display hex.

None of these approaches are wrong. But none can guarantee a consistent result. This is the fundamental challenge with relying on forward resolution alone.

The ideal expectation​

In a more mature model, every address with an ENS name would also declare a primary name.

Under that expectation, it's very simple for wallets to fully support resolution:

• If the address has a primary name, display it.
• If it does not, display the address.

Forward resolution would continue to support discovery, but identity at the point of interaction would be at the discretion of the wallet.

Alternatively, an external system could issue attestations asserting that a particular forward-resolving name is the authoritative identity for a given address. Wallets could then rely on those attestations when deciding which name to display.

However, this introduces an additional trust layer. An attestation requires an issuer. That issuer becomes a trusted authority within the identity model. The security boundary shifts outward, from protocol guarantees to the credibility of whoever is signing the assertion.

This may be appropriate in some contexts. But it is fundamentally different from an address declaring its own primary name onchain.

The mechanical constraint​

As highlighted in our recent article, setting a primary name for a smart contract is not always straightforward. While externally owned accounts can configure a primary name easily, smart contracts depend on ownership semantics set by the ENS protocol.

Not all projects are willing to make the requisite changes to their smart contracts code to support this.

As a result, teams may stop after configuring forward resolution. The name resolves correctly, but the contract does not assert itself as having a primary name.

Why this is a security boundary​

A security boundary lies at the point where guarantees end and we rely instead on assumptions.

Primary name declaration provides a guarantee. The address has a single, unique identity.

Forward resolution alone provides a somewhat ambiguous mapping. When wallets must choose between multiple forward-resolving names, or infer identity based on context. They are operating beyond guarantees of the naming service.

As ENS data becomes more visible in transaction flows and contract interactions, the distinction between asserted and inferred identity becomes more important.

If smart contract identity is to serve as serious infrastructure, forward resolution alone cannot be treated as sufficient. Primary names must become normalised.

The difference between a name that points somewhere and an address that declares who it is is subtle in implementation. In practice, it is the boundary between a loose versus definitive identity.

If you have spent any time using Ethereum wallets or block explorers, have you ever questioned why smart contracts are still referred to via their hexadecimal addresses?

You don’t have to enter numeric digits to visit websites. Why can’t you refer to smart contracts by name?

Smart contracts can have human-readable names. The Ethereum Name Service (ENS) has existed for almost 9 years which solves this problem. Some protocols already use human-readable names for their smart contracts. And yet, for most users, smart contracts still appear as long hexadecimal strings that are opaque, hard to distinguish, and easy to confuse.

This is not an accident, and it is not because naming does not work. It is the result of several structural choices in how Ethereum infrastructure evolved. Understanding those choices matters, because the lack of discoverable contract identity is not just a UX issue. It has real security and trust implications for users.

So why, in practice, are contract names not discoverable by default?

1. Wallets and infrastructure do not surface primary names​

The most immediate reason is simple. Many wallets do not show ENS primary names for smart contracts, even when they exist.

Take MetaMask as a common example. When interacting with a contract, MetaMask may display:

• An Etherscan label, if one exists
• A Solidity file name, if the contract is verified

Coinbase’s Base wallet, on the other hand, simply shows a hexadecimal contract address.

What neither wallet reliably displays is the ENS primary name associated with that contract address.

Other wallets are experimenting in this direction. Ambire, for example, has started to surface ENS names more prominently in contract interactions, showing that better visibility is possible today.

The result is that a contract can be correctly named in ENS and the user still only sees a hex address in their wallet.

From a user’s perspective, the name effectively does not exist. From a protocol’s perspective, the effort spent naming contracts has limited downstream impact unless wallets and explorers choose to surface that information.

This is a visibility problem at the infrastructure layer. The data exists, but the most important interfaces do not yet treat it as first-class.

2. ENS identity has historically focused on wallets, not contracts​

ENS identities have typically been associated with wallet identities for individuals and projects. ENS names became a way to represent people, DAOs, and accounts, rather than deployed infrastructure.

There has never been a coordinated push to establish smart contract identities as a first-class concern. As a result, naming contracts was not treated as a default expectation, either socially or technically.

This shaped how tooling, documentation, and mental models evolved. ENS was widely understood as an account naming system, not as a layer for organisational or protocol infrastructure.

This gap is a large part of why Enscribe exists. The goal is not to replace ENS, but to extend it into the domain it has historically underserved — smart contracts.

3. Developers historically have not named contracts​

This wallet-centric framing was reinforced by developer practice.

For most of Ethereum’s history, developers simply did not name their smart contracts once they were deployed. Contracts were deployed and verified at best. Then identified primarily by addresses listed on docs portals or in GitHub repos.

This made sense in a smaller, highly technical ecosystem. Developers knew which address was which. Users were expected to rely on audits, documentation, or social context rather than any notion of onchain identity.

But Ethereum has changed. Smart contracts are now interacted with by:

• End users
• DAOs and governance systems
• Wallet interfaces
• Agentic systems

At this scale, it’s embarrassing to have unnamed infrastructure.

Compounding this, many of the largest and most respected protocols in the ecosystem, including Uniswap and Aave, have historically not named the majority of their deployed contracts. When leading protocols do not treat contract naming as important, there is less incentive for others to do so.

One of the goals of Enscribe is to change this default. That means making it straightforward to name existing deployed contracts, and making it easy to name new contracts at deployment time.

Crucially, this has to fit into existing developer workflows. That is why Enscribe focuses on developer tooling that integrates directly with environments developers already use, such as Foundry and Hardhat, rather than introducing entirely new processes.

Naming needs to become something developers do by default, not something that feels optional.

4. Users have been conditioned to accept hex as normal​

The combination of wallet behaviour and developer practice has had a direct effect on user expectations.

Because ENS identities were primarily associated with wallets, and because most smart contracts were never named in the first place, users have spent years interacting with contracts that had no visible identity at all. Over time, this conditioned users to accept hexadecimal addresses as normal.

Ethereum users, even non-developers, scroll past hex strings, copy them, and compare the first and last few characters almost instinctively. What began as a technical necessity gradually became a learned behaviour.

This conditioning hides how problematic hex addresses really are:

• They are visually noisy

• They take up a disproportionate amount of space in wallet interfaces

• They are almost impossible to distinguish reliably at a glance

In most other computing contexts, this would be unacceptable. We do not identify websites, applications, or organisations by raw identifiers. We use names.

But because smart contract identity was never treated as a first-class concern, users were never given a viable alternative. Wallets did not surface names, protocols did not consistently set them, and expectations adjusted accordingly.

The absence of pushback is not evidence that this model works. It is evidence that users have adapted to a system that offers very little transparency at the moment when trust decisions matter most.

5. Primary name mechanics are still constrained​

Even when teams want to do everything correctly, there are real mechanical limitations today.

Setting an ENS primary name for an address typically requires the address to the ERC-173 Ownable standard. This works well for some contracts, but not all smart contracts fit neatly into that model.

As a result:

• Some contracts can have forward-resolving names but no primary name
• Some naming setups are technically correct but invisible to wallets
• Some teams simply give up because the rules are unclear or restrictive

There are ongoing discussions within the ENS ecosystem about expanding the scope of what can set and manage primary names, particularly for contracts. These discussions are important, but changes at this level take time.

In the meantime, the ecosystem lives with a fragmented approach to contract identity.

Why this matters​

When contract names are not discoverable by default, there is a real cost to users.

They experience:

• Confusion during transactions
• Difficulty distinguishing real contracts from impostors
• Increased susceptibility to spoofing and address poisoning
• Over-reliance on off-chain, often centralised labels

This doesn’t need to be the case. The pieces for a better system already exist. What is missing is alignment between naming practices, infrastructure support, and user expectations.

Contract identity should not be a nice-to-have. It is foundational infrastructure for transparency and trust at scale.

If Ethereum is going to support millions of users interacting with thousands of contracts per protocol, then human-readable, discoverable identity needs to stop being optional and start being treated as essential.

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

Smart contracts power the onchain economy, but they lack proper identity infrastructure. When users encounter a contract address like 0x742d35cc567890c000c000c07c81c25d7df34793, they can't easily verify what it does, who built it, or whether it's safe to use.

Enscribe has been working to solve this through contract naming. Now we're taking the next step by proposing a new ENS Improvement Proposal that establishes a comprehensive metadata standard for smart contracts.

The Problem with Contract Identity​

Smart contracts face several identity challenges:

• Trust Issues: Users can't easily verify if a contract is legitimate or malicious
• Missing Documentation: No standard way to find a contract's docs, source code, or audit reports
• Inconsistent Information: Wallets and dApps show different (or no) contract details
• Poor Developer Experience: No standard API for contract discovery and metadata

While ENS enables human-readable contract names, the ecosystem lacks standardized metadata storage. Projects create custom solutions, users rely on centralized services, and critical information gets scattered across different platforms.

Our Proposed Solution​

We've submitted an ENSIP that extends ENSIP-5 (Text Records) with standardized metadata fields for smart contracts. This creates one source of truth for contract information, stored directly in ENS records.

Imagine if instead of simply seeing a hex contract address you had a rich view of the contract such as this:

Our proposed standard would serve as a foundation to make such information available for smart contracts across Ethereum.

New Text Record Fields​

Contract Classification:

• category: Contract type (defi, dao, utility, gaming)
• license: Software license (MIT, Apache-2.0)
• docs: Official documentation links

Security Information:

• audits: Structured audit report data with auditor names and report links
• proxy: Proxy contract details and implementation addresses

Compiled Metadata Resolver​

The proposal introduces a new resolver profile for complete compiler-generated metadata. Building on ENSIP-4's (Support for contract ABIs) multi-encoding approach, it supports:

• JSON formats: Uncompressed and compressed
• CBOR encoding: For onchain parsing
• URI storage: IPFS, Arweave for large files

This metadata contains everything needed for contract verification: ABI definitions, compiler settings, source code hashes, and NatSpec documentation.

Real Impact​

This standard solves concrete problems:

• Users can verify contract authenticity before signing transactions
• Developers get standard APIs for contract metadata across all applications
• Projects build professional contract identity that increases user trust
• Ecosystem reduces dependence on centralized services

Contract Metadata in Action​

We've implemented this metadata standard for our own contract as a demonstration. You can see v0.enscribe.named.eth on ENS Manager with all the proposed metadata fields populated (some values are placeholder for now).

Since the ENS manager app doesn't yet render contract metadata optimally (it's designed for user profiles), here's how we envision displaying contract metadata in applications built for contracts:

Current ENS Manager view - shows metadata but not optimized for contracts

Enscribe's contract-focused interface - Technical details, security audits, and expanded metadata view

The difference is clear: contract-specific interfaces can organize and display metadata in ways that help developers and users understand what they're interacting with.

We Need Your Input​

The proposal draws from our experience building contract naming tools, but community feedback shapes the final standard.

Help us refine:

• Technical implementation approach
• Additional metadata fields
• Wallet and dApp integration needs
• Use cases we should address

Review and Feedback​

Enscribe makes smart contracts easier to trust by giving them human-readable names. This ENSIP extends that mission — moving from basic naming to complete contract identity infrastructure.

Read the full proposal: ENSIP: Contract Metadata Standard and Text Records

The proposal includes technical specifications, implementation examples, and design rationale. Whether you build protocols, develop wallets, or use onchain applications, your input helps create better infrastructure.

Join the discussion and help us build standardized, discoverable contract identity for the onchain world. You can also share your thoughts, suggestions, and any issues you encounter through our Discord community, Telegram, or X.

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!