5 posts tagged with "enscribe"

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

With Enscribe, our mission has always been simple yet ambitious — to eliminate hex contract addresses from the Ethereum user experience. Hex strings like 0x123abc… are cryptic, intimidating and unfriendly to users.

ENS transforms these meaningless identifiers into human-readable names like vitalik.eth just like DNS resolves domain names on the internet to IP addresses.

With our latest update, we’re eliminating these annoying hex addresses from URLs, further enhancing Enscribe’s UX.

A Friendlier Way to Explore Contracts and Accounts​

Previously, if you wanted to explore details about an account or contract on Enscribe, you had to navigate using its hexadecimal address:

https://app.enscribe.xyz/explore/1/0xd8da6bf26964af9d7eed9e03e53415d37aa96045

Where 1 is the chain-id (Ethereum) and 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 is an EOA on Ethereum.

Now, we’ve enhanced the experience so you can simply use ENS names instead:

https://app.enscribe.xyz/explore/1/vitalik.eth

Whether it’s an EOA (Externally Owned Account) or a smart contract, Enscribe will resolve the ENS name and fetch its details.

This doesn’t just work for the mainnet. Thanks to the support for resolving names on Layer 2 chains, we can also use a Layer 2 chain-id and the name with it, such as

https://app.enscribe.xyz/explore/8453/greg.base.eth

Why This Matters

Ethereum’s UX still leans heavily on raw addresses, making the ecosystem less approachable for everyday users. Our goal at Enscribe is to flip that narrative, to make names the default, and hex addresses optional. By supporting ENS names everywhere we display or consume on-chain data, we’re moving toward an Ethereum experience that’s:

• Human-friendly → Users interact with alice.eth, not 0x4b2...9f7.
• Consistent → Works across EOAs and contracts alike.
• Aligned with ENS adoption → Encouraging the ecosystem to name their contracts and improve discoverability.

Enscribe isn’t just about contract naming — we’re helping reshape Ethereum’s UX around names, not hex.

You can try it out now in the Enscribe app, check out vitalik.eth at

https://app.enscribe.xyz/explore/1/vitalik.eth

Happy Naming! 🚀

With Enscribe, we’re always looking for ways to make viewing smart contracts details simpler and safer for users. Our latest update to the Contract Details page introduces two subtle yet impactful changes designed to improve clarity and usability for our users.

Spot Your Primary Contracts at a Glance​

When looking at contract information, it can be a little overwhelming when trying to identify what the primary name of the contract is. To simplify this, we’ve introduced a blue tick next to primary contract names.

Now, when you view the Contract Details page for a particular contract, you can easily see if a primary name is set for the contract.

We’ve also shown a tooltip that tells you you are looking at a primary name:

For contracts that have no primary name set but do have at least one forward resolution name set, we now also show that name:

However, to make sure that we differentiate between primary and forward resolution names, we show the usual cautionary warning sign as well as explain it in the tooltip:

Introducing the “Name It!” Button​

Contracts without names can make browsing blockchain data cumbersome. That’s why we’ve added the Name It! button next to contract addresses that:

• Don’t yet have a primary name set, or
• Have at least one forward resolution name available.

Here’s a proxy contract that has no name set:

Here’s a contract that doesn’t have a primary name set but has a forward resolution name set:

Clicking the button takes you straight to the Name Contract page on Enscribe, with the contract address pre-filled. This saves you time, reduces manual input and ensures you can seamlessly add meaningful, human-readable names to your contracts.

By making it easier to name your contracts, we’re helping you keep your on-chain activity clear and structured.

Why These Changes Matter​

With these enhancements, we’re continuing our mission to make on-chain data more accessible and user-friendly. Whether you’re a developer, an ENS enthusiast, or just someone managing multiple contracts for a project, these updates simplify contract name identification and improve overall interaction experience on Enscribe

Go check your contract on the Contract Details page today and let us know what you think about them on our X/Telegram/Discord channels.

Happy naming! 🚀

We’re excited to announce that Safe smart account wallet support is now live in Enscribe. Whilst Enscribe already has support for commonly used wallets like Metamask and Coinbase, Safe was not fully compatible..

This update enables deploying a new contract and setting an ENS name for it or naming an existing contract with your Safe wallet with full control over transaction approval and execution.

Why Safe Wallet?​

Safe is commonly used as a multi-signature wallet in the Ethereum ecosystem. A Safe wallet account can have multiple Ethereum accounts configured as signers behind it. When a transaction is to be approved and executed, all signers must sign & execute that transaction.

This process can happen asynchronously without waiting for approvals from all the signers. This is unlike executing transactions with a wallet like Metamask where every transaction request will block until it is either approved or rejected.

It’s ideal for workflows where transparency and decentralized control are required.

What You Can Do with Safe in Enscribe​

Enscribe now enables you to:

• Deploy new contracts with ENS names set using your Safe wallet.
• Name existing contracts with ENS names from your Safe address.

Supporting Safe required a different approach from the typical MetaMask-style interactions, where each transaction prompts a popup that demands immediate attention. With Safe, Enscribe queues transactions, so they can be approved via the Safe App.

How to Connect to Safe Wallet in Enscribe​

Connecting to a Safe wallet is slightly different from connecting to Metamask or Coinbaser wallet. To connect to your Safe wallet, click on the Connect button on the top right corner on Enscribe:

On the Connect a Wallet popup, select WalletConnect

Now click on the OPEN button to open the WalletConnect modal

Click on Copy link and go to your Safe wallet app. Click on the WalletConnect icon on the top bar

Now paste the copied link in the Pairing code field in the popup

You should now see Enscribe as connected app

Once connected, you’ll see your Safe wallet account shown as connected in Enscribe as well as in the Safe App.

Kicking off Transactions​

With Safe wallet, our naming-related transactions are sent to the Safe wallet queue without waiting for them to complete. This is because Safe wallet intercepts our Enscribe transactions & executes them in its own multisig transactions. Therefore, Enscribe doesn’t have knowledge of these transactions whilst pending.

Enscribe differentiates between a Safe wallet and a wallet like Metamask and will modify the behavior of waiting for transactions to complete accordingly. This is how pending transactions look like in the Safe wallet:

On executing the above pending transaction to set the primary name of a contract, we can see the contract details in Enscribe:

We can also rename the contract we just deployed. Let’s say we rename it to safewallet13.testapp.eth. Like before, two transactions - setting forward resolution and setting reverse resolution - will be kicked off in the Safe wallet app:

And we see two transactions in the Safe wallet app that we can bulk execute:

We see our contract now has a new name:

Having full support for Safe ensures that teams protecting key contracts with a multisig can properly name their contracts with Enscribe.

If you have Safe controlled contracts you wish to name, you can try naming your contracts with Safe wallet at app.enscribe.xyz!

Happy naming! 🚀

One of the core objectives of Enscribe is to make smart contracts safer for users. Our latest feature builds on that objective by connecting Enscribe contract details with the Open Labels Initiative (OLI), a project focused on providing smart contract labels via attestations.

What Is the Open Labels Initiative?​

The Open Labels Initiative is a standardized framework and data model for address labeling. Think of OLI as a public bulletin board for contract facts — users can attach signed statements, called attestations, to a contract address. These attestations, also referred to as labels, might indicate different bits and pieces of information such as the Owner Project, Category, Subcategory, etc. Here’s a sample of smart contracts and their labels from labels.growthepie.com:

Attestations on OLI are public and verifiable. Anyone can view them, and anyone can contribute new ones enabling community contributions to the initiative. OLI helps surface credible, onchain or offchain information about contracts.

How does this help Enscribe users?​

On every Contract Details page in Enscribe, you’ll now see a new section “Contract Attestations”, under this will be a button ‘Label on OLI’ (or ‘Labelled on OLI’).

In the above image, we see the contract information as usual and the ‘Labelled on OLI’ button since this contract has attestations.

If attestations exist for a contract, clicking the button opens the contract’s attestation page on the OLI website. There, you can review attestations that have been made about the contract such as who made them and time of the attestations.

If no attestations are present, the same button will now say ‘Label on OLI’:

Clicking on the button will take you to the attestation submission form. The contract address and chain is pre-filled, so you just need to add any additional information on the attestation submission form.

Enscribe’s mission is to make Ethereum safer for users by making apps more trustworthy and easier to navigate. Open, permissionless labels help build trust in contract usage and protocol adoption. Integrating with OLI means anyone can check a contract’s reputation or contribute to its public profile.

To try it out, visit any contract details page on Enscribe and click the OLI button to either see the attestations or add one using the attestation submission form.

Happy naming! 🚀