Web3 Labs

The biggest blocker I hear from organisations on ENS isn’t technical. It’s identity. Teams already have a domain. Their brand, users, and operations are built around it. Adding a separate .eth name can feel like duplication and with it, added complexity and uncertainty. What’s often missed is that ENS doesn’t require that trade-off. You can bring your existing DNS domain onchain and use it as your ENS identity. No new naming surface, no reset of trust, just an extension of what already exists. In the article below, I break down why DNS-on-ENS is often the simplest path for organisations, and why reducing friction is key to broader adoption.

DNS started as a technical convenience. It became organisational infrastructure. Companies didn’t just use domains for websites. They built structured naming systems around them, organising teams, services, environments, and regions. Over time, that structure became invisible because it was foundational. I think ENS is following a similar path. Today, most onchain infrastructure is still identified by hexadecimal addresses. But once teams start naming contracts and wallets, the benefits become obvious, coordination improves, systems become legible, and adding new infrastructure gets easier. In the article below, I explore what DNS can teach us about where ENS is heading, and why structured naming is likely to become standard for onchain organisations.

Most ENS conversations focus on .eth names. But ENS also supports DNS and that changes the picture. Instead of asking organisations to adopt a completely new identity, ENS allows them to bring their existing domain onchain. That means identity doesn’t have to start from zero. It can extend what users already recognise and trust. That flexibility matters more than it might seem. In the article below, I explore why optionality is one of ENS’s most important properties and why bridging DNS and ENS could be a more natural path for organisations coming onchain.

Ethereum still expects users to make trust decisions using hexadecimal addresses. That was never the intention. These identifiers exist for machines, not humans. Yet in many wallets today, users are asked to look at a 42-character string and decide whether something is legitimate. In practice, people fall back on weak signals or stop verifying altogether. That’s where problems like address poisoning come from. In the article below, I explore why hexadecimal addresses are still a security issue, how user behaviour has adapted around them, and why naming isn’t just a UX improvement, it’s a necessary shift in how trust is established onchain.

When we launched Contract Naming Season, the focus was on momentum. Teams were starting to name contracts. Tooling was improving. Early signals were emerging. Now we have something more concrete. The first batch of awards has been distributed — 4,665 ENS across 31 teams and individuals — with nearly two months still to go. What’s been most encouraging isn’t just the number. It’s the spread. Participation is coming from both established protocols and individual builders, which is exactly what needs to happen for naming to become a standard rather than a niche. In the article below, I share what we’re seeing so far, why the work is still uneven, and what comes next as the program continues.

Over the past year working on Enscribe, one pattern has become clear to me. Identity is often treated like a feature. A wallet adds naming support. An explorer improves labels. A protocol integrates ENS. The assumption is that identity can be solved by one team shipping the right capability. In reality, onchain identity only works when multiple actors participate. Protocols declare canonical names. Wallets surface them. Explorers distinguish labels from identity. Naming systems provide the primitives. If any layer skips its part, ambiguity returns. In the article below, I unpack why identity is better understood as shared infrastructure and why treating it as a feature misses the real coordination challenge.

When teams talk about shipping securely onchain, audits dominate the conversation. Naming rarely does. It’s usually treated as administrative overhead, something to configure after deployment. But in practice, naming is operational infrastructure. If someone outside your core 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 doing its job. In this piece, I outline the most common smart contract naming mistakes I see, from skipping version namespaces to assuming forward resolution is enough, and why they compound over time. If you care about shipping securely and being legible onchain, this is worth reading.

When a protocol announces an audit, the assumption is simple: Audited = secure. But audits verify logic. They don’t establish identity. An audit tells you that a specific codebase at a specific address behaves correctly. It does not tell you that the address you’re interacting with is the canonical deployment. If someone redeploys identical code at a different address, the audit doesn’t prevent users from interacting with the impersonator. That’s the gap. In this piece, I unpack why code assurance and identity assurance are separate layers and why audited contracts can still be vulnerable to impersonation if identity isn’t treated as infrastructure. If you care about smart contract security, this distinction matters.

ENS supports two ways of linking names and addresses. A name can point to an address. Or an address can declare a primary name. That distinction defines a real security boundary. If multiple names point to the same contract, wallets are left to infer which identity to display. A primary name removes that ambiguity. The address explicitly asserts who it is. As ENS data becomes more visible in wallets and transaction flows, that difference matters more. In the article below, I unpack why primary names aren’t just a UX detail, they’re foundational to onchain identity.

For a while, it felt like Ethereum was fragmenting. The L2 roadmap worked, we have more throughput and more experimentation than ever. But it also introduced complexity. More chains, more narratives, more places to focus. Lately, refocusing on Ethereum L1 feels right again. This isn’t anti-L2. Some are doing genuinely differentiated work. But when many offer similar benefits, long-term alignment becomes harder for builders and infrastructure teams alike. In the article below, I unpack why anchoring back to L1 simplifies coordination and brings clearer direction to the ecosystem.