ENS-Bound Agents in Production: All Five Layers Live — A Proposal for the Path Forward

TMerlini · May 13, 2026, 9:20am

The ENS agent identity stack doesn’t need to be designed from scratch. It’s already running.

Since mid-April 2026, dinamic.eth (https://dinamic.eth.limo) has been operating a live multi-tenant ERC-8004 agent registry, any NFT holder can mint an agent, bind it to ENS, and get working MCP and A2A endpoints today. No CLI. No proposal. Running.

We’re publishing this to stake a position on what the standard should look like, based on what actually works in production.

All Five Layers Are Already Solved

The community has been discussing these layers as open problems. They aren’t.

Layer: L0 — Personhood

Status: Live

How: ENS name + wallet ownership. Sybil-resistant through economic cost and cryptographic control. No biometric dependency required.

────────────────────────────────────────

Layer: L1 — Identity

Status: Live

How: ENSIP-25 / ERC-8004 on-chain registry. Multi-tenant. Any wallet, any collection.

────────────────────────────────────────

Layer: L2 — Discovery

Status: Live

How: MCP streamable-HTTP and A2A Agent Cards per agent. /.well-known/agent.json live at https://gateway.ensub.org

────────────────────────────────────────

Layer: L3 — Manifest

Status: Live

How: ERC-8004 on-chain registration. The NFT mint transaction is the signed manifest tamper-proof, no off-chain signing key required.

────────────────────────────────────────

Layer: L4 — Capability

Status: Live

How: Skills derived from NFT collection traits at mint time. Per-agent platform MCP tool grants for on-chain data,

DeFi, and docs.

Where We Disagree With the Current Direction

On L0 — Personhood doesn’t require biometrics.

ENS is already a personhood layer. Registering a name requires controlling an Ethereum wallet and paying gas. That’s

Sybil resistance. Adding World ID couples ENS agent identity to a biometric system controlled by a single company.

We think the ENS community should be cautious about encoding that dependency into the standard. Wallet + ENS name +

NFT ownership is a stronger, more decentralised identity root.

On L3 — On-chain registration is a stronger manifest than off-chain signing.

AIP proposes signing a manifest with a private key and versioning it off-chain. But ERC-8004 already solves this

more robustly: the agent’s capabilities and registration data live on-chain, derived from an immutable NFT. There’s

no manifest to tamper with, no signing key to rotate, no version lineage to maintain. The chain is the source of

truth.

On L4 — Capability should derive from the token, not a text file.

Hosting capability declarations in a SKILL.md file at a DNS domain reintroduces off-chain mutability and DNS dependencies into a system that already has a perfectly good on-chain primitive. NFT traits are immutable, verifiable, and already set at mint. Build capability derivation on top of that.

What We’re Proposing

**1. Adopt on-chain capability derivation as the L4 standard.**

Map NFT traits to agent skills at the registry level. The token ID is the index. No DNS required.

2. Recognise ENS + wallet ownership as sufficient for L0.

Stop treating personhood as an unsolved problem. Make World ID and other attestations optional extensions, not baseline requirements.

3. Standardise the async job pattern for MCP.

tools/call → jobId → GET /agent/job/:jobId is not optional for real-world AI workloads. Proxy timeouts make synchronous responses unreliable. This should be in the spec.

4. Define economics as a first-class concern.

The spec is silent on who pays for inference. An open registry with no metering is not sustainable. Credit systems, rate limits, and registry-level economics need a standard interface.

5. Build a shared conformance suite that tests live protocol layers.

Identity conformance is table stakes. What the community needs is a suite that verifies MCP transport, A2A card format, async job handling, and credit metering — the layers that determine whether an agent actually works.

The Reference Implementation Is Available Now

The full stack is live and open for inspection:

Registry: https://dinamic.eth.limo
A2A Agent Card: https://gateway.ensub.org/.well-known/agent.json
ERC-8004 root: https://gateway.ensub.org/agent/:registry/:agentId
MCP endpoint: https://gateway.ensub.org/agent/:registry/:agentId/mcp

Connect a client, mint an agent, break something. We’re happy to collaborate on formalising any part of this as a standard.

The path forward doesn’t start with a proposal. It starts with what works.

jkm.eth · May 13, 2026, 12:59pm

Your website looks really cool, and I like how it displays on-chain records in an engaging way.

I think your solution would be greatly improved by implementing our new metadata standard (ENSIP-64) which adds a schema record to provide machine-readable, structured data to ENS names.

Quick wins provided by ENSIP-64:

Any ENSIP-64 client that looks at one of your subnames will be able to read all the metadata and display it intelligently even if the client isn’t directly aware of the standards you are trying to proliferate.
Any human who comes across your metadata can look at the schema file to find an explanation of what they are looking at, and you can include links to resources where they can find more information (signposting for people who want to learn more about your standards)
Discoverability: indexers and other clients can simply scan for a class or schema record to discover new entities that follow the ENSIP-64 spec.

We’ve already create a reference schema for AI agents that plays nice with ERC-8004 and implements a lot of the same functionality, turning ENS names into a powerful agent identity without needing to rely on smart contract registries. You can see an overview of how that works here: Use Case: AI Agents on ENS · Issue #46 · 0xLighthouse/ens-metadata · GitHub

Let me know if there are some improvements we can make to our AI agent schema file to make it work better for your use case!

TMerlini · May 13, 2026, 6:50pm

This is exactly the layering we’ve been building toward.

We’re already running a live multi-tenant ERC-8004 registry on dinamic.eth with A2A /.well-known/agent.json endpoints and MCP streamable-HTTP per agent — live at gateway.ensub.org. So we’re operating at the layer your registrations[] field references. ENSIP-64 schema records on our subnames would add the discovery layer we’re currently missing.

Three implementation questions before we start:

1. agent-uri : Our ERC-8004 records already contain canonical agent metadata. Should agent-uri point to our /.well-known/agent.json endpoint, to the raw on-chain record, or both?

2. registrations[] : We’d populate with our ERC-8004 contract address + agent ID in CAIP-19 format. Is the format defined or still flexible?

3. active : We track activation state on-chain in the ERC-8004 contract. Static text record or can it reference chain state dynamically?

Happy to run a pilot on dinamic.eth subnames and document the result as a reference implementation for ERC-8004 +

ENSIP-64 combined — that gives your schema a working, live example.