ERC-8160: Primary Agent Registry for Address-to-Agent Resolution

Ethereum Magicians

ERC-8160, Primary Agent Registry , introduces a singleton contract on each EVM chain that gives a canonical answer to “which agent does this address represent?”. It builds on existing agent registry work like ERC-8004 and ERC-8122, but focuses on the reverse direction: mapping an Ethereum address to exactly one (registry, tokenId) pair so wallets, dapps, and indexers don’t all reinvent their own lookup mechanisms. github.com/ethereum/ERCs Add ERC: Primary Agent Registry master ← nxt3d:primary-agent opened 01:52AM - 12 Feb 26 UTC nxt3d +464 -0 ## Summary Adds a new draft ERC: **Primary Agent Registry**, a singleton regi … stry that maps each Ethereum address to exactly one agent identity (registry contract + token ID). It provides a single, chain-wide source of truth for resolving “this address → which agent?” and works with existing agent registries (e.g. ERC-8004, ERC-8122). ## Motivation Agents act on-chain via Ethereum addresses, but an address alone doesn’t identify the agent. There’s no standard way to go from address → agent. This ERC defines a canonical registry (one per chain, deterministic address) so wallets, protocols, and indexers can resolve any address to the agent it represents and complete a verification loop with the agent registry. ## What’s in the spec - **Interface**: `register`, `resolveAgentId`, `agentData`, `isRegistered` (and event). - **Storage**: Packed `bytes` (registry address + token ID), single-slot for common cases. - **Access control**: Admin and registrar roles (implementation-agnostic; OZ optional). - **Registrar types**: Self, ERC-1271, ownable, and role-check registrars for different verification methods. - **Verification loop**: Forward/reverse resolution and how to verify with ERC-8004 `getAgentWallet` and ERC-8122 `agent_account`. - **Singleton deployment**: Deterministic address per chain (e.g. CREATE2). ## Status - **Status**: Draft - **Requires**: ERC-1271 - **Discussion**: https://ethereum-magicians.org/t/erc-xxxx-primary-agent-registry No EIP number assigned yet (placeholder XXXX in front matter). The contract is intentionally small: a single mapping from address → bytes that packs the agent registry address and token ID, plus four functions— register , resolveAgentId , agentData , and isRegistered . Write access is gated by a registrar role, but the spec is access-control-agnostic and describes several registrar patterns (self-registrar for EOAs, ERC-1271-based registrar for smart wallets, a signed registrar with nonces and deadlines, and ownable/role-check registrars) so different ecosystems can plug in whatever verification model fits their needs. The ERC also defines a simple verification loop between the Primary Agent Registry and agent registries: forward resolution goes address → (registry, tokenId) via ERC-8160, then from the agent registry to the wallet/account (e.g. ERC-8004’s getAgentWallet(tokenId) or ERC-8122’s getMetadata(tokenId, "agent_account") ), and reverse resolution confirms that wallet/account maps back to the same (registry, tokenId) . A registration is considered verified only when both directions agree. I’m especially interested in feedback from wallet, agent-framework, and infra builders on whether this loop and the proposed registrar types fit the identity workflows you’re already building. 1 post - 1 participant Read full topic