Skip to main content

8 posts tagged with "smart-contract-identity"

View All Tags

Why hexadecimal addresses are still a security problem

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

Confused person cover image

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.

Contract Metadata: Rich onchain identity for smart contracts

· 4 min read
Nischal Sharma
Co-Founder and Lead Engineer at Enscribe

Contract metadata cover

Smart contracts are the backbone of onchain applications, but discovering information about them has always been fragmented. Contract metadata lives across multiple platforms — documentation on one site, audits on another like github, social links scattered everywhere. Basic information like "what does this contract actually do?" is often nowhere to be found.

Enscribe brings contract metadata onchain through ENS text records.

Why identity is a shared responsibility, not a feature

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

Why identity is a shared responsibility, not a feature, cover image

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.

Why primary vs forward-resolving names is a security boundary

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

Forward versus primary names visual

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.