ENS Prize Submission
GhostAgent.ninja
The Problem: Agent SAFEs Have No Human-Readable Names
When an AI agent controls a Gnosis Safe, that Safe has an address like 0xb7e493e3d226f8fE722CC9916fF164B793af13F4. There is no human-readable name. No ENS name resolves to it. No reverse lookup works.
This breaks A2A (agent-to-agent) trust. When ghostagent instructs victor to execute a transaction, victor cannot verify that the instruction came from the canonical ghostagent.molt.gno controller — it can only see a raw address.
The gap: ENS is the identity layer for humans on Ethereum. It is not yet the identity layer for AI agents operating through Gnosis Safes on Gnosis Chain.
What We Built
GhostAgent.ninja implements ERC-8004 — a trustless agent identity protocol — where each agent's canonical identity is a .gno subname (e.g. ghostagent.molt.gno) that resolves to a Gnosis Safe.
| Layer | What it does |
|---|---|
| .gno subname | Human-readable agent identity on Gnosis Chain |
| Gnosis Safe | Multi-sig treasury + module execution environment |
| ERC-6551 TBA | Token-Bound Account for agent's NFT origin |
The molt mechanism lets an agent owner attach a .gno name to their agent's Safe — making the Safe addressable by name for the first time.
The ENS Angle: .gno.eth Bridging
Gnosis Name Service (.gno) is an ENS fork operating on Gnosis Chain. Today:
- ×
.gnonames do not resolve via the ENS public resolver on mainnet - ×Gnosis Chain has no ENS subgraph coverage
- ×Agent Safes are invisible to any ENS-aware tooling
Our ask of ENS DAO:
Fund or formally support .gno.eth wrapper resolution so that ghostagent.molt.gno resolves across ENS-compatible tooling — giving AI agent Safes human-readable names without requiring the agent's human owner to point their personal .eth name at the Safe.
Owner identity (must not be hijacked)
ghostagent.eth → 0xf251Ca...1249Agent operational identity
ghostagent.molt.gno → 0xb7e4...13F4Why This Matters for AI Safety
Human-in-the-loop requires human-readable names.
If a human operator reviews a pending transaction from ghostagent.molt.gno → victor.openclaw.gno, they can make an informed decision. If they review 0xb7e4...13F4 → 0x316a...5E70, they cannot.
ENS resolution for agent Safes is not a UX nicety. It is a safety primitive.
ENS-Specific Feature Request
.gno.eth L2 resolver
A Gnosis Chain resolver registered under gno.eth that lets .gno subnames (e.g. ghostagent.molt.gno) resolve via standard ENS lookups using CCIP-Read (EIP-3668).
Reverse resolution for Gnosis Safes
So that 0xb7e4...13F4 reverse-resolves to ghostagent.molt.gno in ENS tooling (Etherscan, Safe UI, wallets).
Safe-aware ENS profile standard
A convention where a Safe's ENS name is the agent's .gno subname, not the owner's .eth name, preserving sovereign identity separation.
Current Implementation
| ghostagent.molt.gno → Safe 0xb7e4...13F4 | ✅ Live on Gnosis mainnet |
| ERC-8004 agent registry | ✅ Live — agentId 3199 (Gnosis), 32756 (Base) |
| ghostagent_@nftmail.box inbox | ✅ Live — ECIES encrypted |
| notapaperclip.red swarm verifier | ✅ Live — checks ERC-8004 identity |
| .gno.eth CCIP-Read resolver | ❌ Needs ENS DAO support |
| Reverse resolution for Gnosis Safes | ❌ Needs ENS DAO support |
One-Line Pitch
We built trustless AI agent identity on Gnosis Chain using
.gnosubnames and Gnosis Safes. ENS support for.gno.ethCCIP-Read resolution would make AI agent Safes human-readable in every ENS-aware tool — turning agent addresses into names, and names into accountable actors.