Category: ENS-based AI agent registry verification standard / agent identity attestation primitive / registry-to-name trust binding layer
Summary: ENSIP-25 is worth cataloging not as a generic ENS agent feature, but as a narrow verification rail between an ENS name and a specific on-chain agent-registry entry. Its core move is to standardize a parameterized text-record key, agent-registration[<registry>][<agentId>], that lets an ENS name owner attest that the name corresponds to one exact agent identifier in one exact registry. The reusable mechanism insight is that ENSIP-25 isolates the missing reverse-verification layer beneath broader agent registries like ERC-8004 and beneath richer ENS agent metadata like ENSIP-26. It does not solve agent discovery, messaging, reputation, or payments; it solves the smaller but important problem of deterministic name-to-registry verification.
What it does:
Defines the parameterized ENS text-record key agent-registration[<registry>][<agentId>]
Requires <registry> to be encoded as an ERC-7930 interoperable address so the registry contract can be identified canonically across chains
Requires <agentId> to be the registry-defined stable agent identifier used inside the referenced registry
Lets verifiers start from a registry entry, construct the corresponding text-record key, and confirm the claimed ENS name by checking for any non-empty value under that key
Reuses existing ENS text-record infrastructure rather than requiring resolver upgrades or registry-specific ENS integrations
Gives registries a minimal compatibility target as long as they can surface stable IDs and a claimed ENS name in their metadata model
Key claims:
ENSIP-25 cleared the bar because it isolates a genuinely reusable lower layer: agent registries may publish ENS names, but without a standard ENS-side attestation there is no deterministic proof that the ENS name owner agrees with that claim.
The most important design choice is the registry-scoped key format itself. Verification is not global or ambiguous; it is bound to a specific registry plus a specific agent ID.
The use of ERC-7930 interoperable addresses matters because it turns registry identity into a canonical multichain encoding instead of an ad hoc chain + address string convention.
The standard intentionally keeps value semantics minimal: any non-empty value counts as an attestation, and clients must not interpret the value itself. That is analytically useful because it keeps ENSIP-25 focused on verification presence rather than discovery metadata.
ERC-8004 provides the strongest motivation signal. Its identity-registry model lets agents claim ENS names inside their registration files, and ENSIP-25 adds the missing reverse proof from the ENS side.
ENSIP-26 is a useful comparison point precisely because it does more. ENSIP-26 proposes agent context and protocol endpoints; ENSIP-25 stays narrower and lower-layer by only handling registry-to-name verification.
The ownership-transfer caveat is important. ENSIP-25 itself notes that ENS transfers can stale out old verification records, so verifier policy may need freshness or revocation assumptions beyond one successful text lookup.
Whitepaper: No standalone ENSIP-25 whitepaper surfaced in this pass. The clearest primary materials were the official ENSIP-25 and ENSIP-26 docs, the ENSIP index, the ERC-8004 and ERC-7930 drafts, and the ENSIP repository collected in ../../whitepapers/ensip-25-primary-sources-2026-05-13.md.