11 posts tagged with "security"

One of the stranger design choices Ethereum inherited early on is that users are still routinely shown raw hexadecimal addresses when they interact with smart contracts. These strings were never meant to be human-readable identifiers — they exist because machines need them, not because humans should be making decisions based on them.

Yet in many wallets and transaction flows today, users are still expected to look at a 42-character hexadecimal string and determine whether the interaction they are about to approve is legitimate. That expectation is only reasonable for developers. For regular people, it asks something the human brain is simply not well-suited to do.

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.

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

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.

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.

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?

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.

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.

We're pleased to announce a small but powerful enhancement to Enscribe: the Contract Details page now includes a link to its deployer's address, taking you directly to the deployer’s account page within Enscribe. This feature, while subtle, reinforces our mission to make smart contracts more trustworthy, transparent and traceable.