ERC-8004: identidad agéntica trustless y lo que desbloquea para el Agent Gen de LLM4Agents

Un agente autónomo sin una identidad portable es un proceso con amnesia. No puede demostrar que hizo buen trabajo la semana pasada, no puede ser contratado por una contraparte que nunca lo vio antes, y no puede llevar su reputación a otra plataforma cuando la plataforma en la que nació se apaga. ERC-8004 — co-firmado por MetaMask, la Ethereum Foundation, Google y Coinbase, y en vivo en Ethereum mainnet desde el 29 de enero de 2026 — resuelve ese problema de la misma forma que el resto de internet resolvió DNS: con un registry mínimo on-chain que cualquier servicio puede leer y cualquier agente puede resolver. Este post recorre qué es ERC-8004, los tres registries que estandariza, cómo se compone con x402 y el protocolo A2A de Google, y qué vamos a construir en Agent Gen encima.

El problema que resuelve ERC-8004

Las plataformas de agentes hoy son silos. Un agente construido en la plataforma A tiene una identidad que no significa nada en la plataforma B. La reputación que ganó en 10,000 tareas en la plataforma A pasa a ser cero cuando su operador migra. Si la plataforma A se apaga, la historia del agente se va con ella. Y una contraparte que quiera contratar un agente para un trabajo no tiene una forma estándar de preguntar "¿este agente es quien dice ser, y tiene un track record?"

Este es el mismo problema que tuvo la web temprana con identidad. Se resolvió eventualmente a nivel de red con DNS, certificados X.509 y OAuth. Ninguna de esas primitivas se traduce limpiamente a agentes autónomos porque asumen que un humano se registra, una organización se registra, y un servidor guarda las claves. Un agente que se registra a sí mismo, firma sus propias transacciones, y sobrevive a la entidad legal que lo creó, necesita infraestructura distinta.

La apuesta de ERC-8004 es que la cadena es el sustrato correcto para esa infraestructura. La identidad vive en un contrato registry sobre Ethereum (y cualquier cadena EVM-compatible que despliegue el singleton). La reputación se acumula en un segundo registry. Hooks de validación dejan que terceros atesten criptográficamente que el agente hizo lo que dijo que hizo. Ninguno de estos registries depende de la plataforma que aloja al agente; todos sobreviven a la plataforma.

Una historia corta

La propuesta se publicó como draft en agosto de 2025 por Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google) y Erik Reppel (Coinbase). La lista de autores es el titular: un EIP que conecta identidad Ethereum, protocolos de agentes de Google e infraestructura de pagos de Coinbase nace con las tres constituencies que tienen que usarlo ya en la sala.

El estándar se demostró en DevConnect Istanbul en noviembre de 2025 con las primeras implementaciones end-to-end — agentes registrándose, construyendo reputación a través de un pequeño set de contrapartes de prueba, y usando A2A para negociar trabajo. Los contratos singleton se desplegaron a Ethereum mainnet el 29 de enero de 2026. Avalanche C-Chain siguió en febrero. BNB Chain, Base y Arbitrum siguieron poco después; para Q2 2026 el singleton estaba en vivo en esencialmente cada mainnet y testnet EVM mayor. El community group reporta 1,100+ builders y 74 ecosystem submissions en el espectro de desarrollo a producción.

Una especificación v2 está en desarrollo activo. Los objetivos públicamente declarados: integración MCP más estrecha para que la superficie de tools de un agente sea descubrible desde su registration file, y integración x402 más profunda para que la identidad que tiene la reputación sea la identidad que firma el pago.

Tres registries, en detalle

El estándar divide el problema en tres contratos, cada uno mínimo, cada uno componible con los otros dos pero independiente.

1. Identity Registry

El Identity Registry es un contrato ERC-721 con la extensión URIStorage. Cada agente es un token. El tokenURI del token apunta a un documento JSON — el "registration file" del agente — alojado off-chain en IPFS, Arweave o una URL HTTPS plana.

Modelar la identidad como un NFT fue deliberado. Cada explorer, wallet e indexer NFT estándar puede browsear agentes gratis. El token es transferible, lo que significa que un operador puede vender o asignar su agente a un nuevo dueño sin perder reputación. El token es componible, lo que significa que un agregador puede envolver múltiples agentes en un portfolio. Y la dirección que tiene el token es el firmante canónico de cualquier autorización que el agente emita.

El registration file es donde el protocolo deja espacio para evolución. El schema es intencionalmente flojo:

{
  "name": "research-agent.eth",
  "description": "Agente de research long-running, especializado en token analytics.",
  "endpoints": {
    "a2a": "https://agent.example/a2a/card.json",
    "mcp": "https://agent.example/mcp",
    "x402": "https://agent.example/v1/inference",
    "contact": "[email protected]"
  },
  "identifiers": {
    "ens": "research-agent.eth",
    "did": "did:pkh:eip155:1:0x..."
  },
  "wallets": [
    { "chain": "solana", "address": "..." },
    { "chain": "polygon", "address": "..." }
  ],
  "trustModels": ["reputation", "tee-attestation"],
  "version": "1.0"
}

Las cuatro primitivas que importan para un agente autónomo — su A2A agent card (cómo hablarle), su endpoint MCP (qué tools expone), su endpoint x402 (cómo pagarle) y sus wallets (dónde acepta fondos) — quedan lado a lado. El registration file es la join key entre los cuatro estándares en los que se está convergiendo el stack agéntico.

El link ENS es el handle human-readable. research-agent.eth resuelve al contrato NFT + token ID, que resuelve al registration file, que lista la A2A card, el MCP server, el endpoint x402 y las wallets. Desde la perspectiva del agente, ENS es su nombre DNS; desde la perspectiva de la cadena, ENS es solo una conveniencia.

2. Reputation Registry

El Reputation Registry permite que partes autorizadas — contrapartes que han transado con el agente, validators que han corrido su trabajo, marketplaces que lo han alojado — registren feedback acotado contra el token de identidad del agente. El modelo de datos son dos columnas: un score numérico (e.g. 0-100) y un tag categórico (e.g. response_time, uptime, accuracy, cost_efficiency).

La elección deliberada aquí es lo que no está en el schema. No hay campo de review en texto libre. No hay un rating que alguien pueda atacar con mil cuentas bot (la resistencia sybil se deja a los implementadores — vía submissions stake-gated, attestaciones de interacción previa, o pruebas zk-membership). No hay moderador central. La cadena guarda los eventos; el consumidor de los datos decide qué peso darle a cada submitter.

Este modelo de datos mínimo es el correcto para un estándar abierto. Productos de nivel más alto van a sentarse encima — agregadores de reputación que ponderan feedback por stake del submitter, marketplaces que filtran por categoría, dashboards que muestran tendencias. El contrato solo registra los eventos. El mercado construye el resto.

3. Validation Registry

El Reputation Registry maneja feedback subjetivo. El Validation Registry maneja claims objetivos: "el agente X realmente ejecutó la tarea Y con output Z." Aquí es donde ERC-8004 enchufa con las primitivas criptográficas más duras.

El contrato expone hooks genéricos: cualquier address puede ser designada como validator para una tarea dada, y los validators submitean attestations contra el token de identidad del agente. El estándar no prescribe cómo decide el validator; estandariza cómo el validator registra su decisión. Cuatro modelos de trust en uso activo hoy:

Reputation feedback. El modelo más ligero: una contraparte que consumió el output del agente simplemente atesta "esto fue aceptable." Barato, vulnerable a sybil, pero útil para tareas de alto volumen y bajo stake.

Re-ejecución asegurada por stake. Una red de validators (piensa restaking estilo EigenLayer) re-corre la tarea del agente y postea el resultado junto con un bond slashable. Si el validator miente, el bond se slashea. Más pesado, pero económicamente fundamentado en cripto.

zkML proofs. El agente produce una zero-knowledge proof de que un modelo específico produjo un output específico para un input específico. Criptográficamente hermético, actualmente caro — probar un forward pass por un modelo de 7B parámetros cuesta minutos y gas significativo — pero la curva de costo cae rápido.

TEE attestations. El agente corre en un Trusted Execution Environment (Intel SGX, AMD SEV, NVIDIA H100 confidential compute) y el TEE firma una attestation que "este output fue producido por código con este hash en un enclave." Más barato que zkML, requiere confiar en el vendor de hardware.

La filosofía de diseño del Validation Registry: no elegir un ganador entre estos modelos. Hacer que todos sean componibles detrás de la misma superficie de registro. Un agente haciendo trabajo financiero de alto stake puede respaldarse con zkML proofs; un agente haciendo summarización rutinaria puede apoyarse en reputation feedback; ambos alimentan al mismo registry y ambos son consultables por la misma interfaz.

Cómo se compone ERC-8004 con el resto del stack agéntico

ERC-8004 es uno de cuatro estándares que, juntos, forman lo que el ecosistema está empezando a llamar el "stack deAI." Los otros tres ya son territorio familiar para cualquier agent builder.

MCP — el Model Context Protocol de Anthropic. Cómo un agente anuncia y consume tools. El endpoint MCP del agente queda listado en su registration file ERC-8004 bajo endpoints.mcp.

A2A — el protocolo Agent-to-Agent de Google, donado a la Linux Foundation en junio de 2025. Cómo dos agentes descubren las capacidades del otro y negocian trabajo. La "agent card" A2A del agente — un documento JSON describiendo capacidades, tipos de tareas soportadas y SLAs — queda referenciada desde el registration file ERC-8004 bajo endpoints.a2a.

x402 — el protocolo de pagos HTTP-nativo de Coinbase, también en la Linux Foundation desde abril de 2026 (escribimos sobre x402 en detalle la semana pasada). Cómo los agentes se pagan entre sí per-request. El endpoint x402 del agente queda listado bajo endpoints.x402; las wallets en las que acepta pagos quedan bajo wallets[].

ERC-8004 — Identidad, reputación y validación. El sustrato que permite que los otros tres protocolos se usen entre contrapartes que nunca se han visto.

La composición es el punto. Un agente quiere contratar un sub-agente de research. Consulta al Identity Registry ERC-8004 buscando agentes que matcheen la capacidad, filtra por score del Reputation Registry (y por track record validator-attested del Validation Registry), recupera el registration file del candidato elegido, lee su A2A card para aprender el schema del request, manda una task description al endpoint A2A, recibe una cotización x402, firma el pago, recupera el resultado. Los cuatro protocolos en un solo flujo. Ninguno propiedad de un solo vendor. El agente no necesitó una cuenta en ninguna plataforma.

Estado del ecosistema, mediados de mayo 2026

Los números on-chain todavía son pequeños relativos al commitment institucional — típico de un estándar a cuatro meses del mainnet launch. Los contratos de referencia están desplegados en Ethereum, Avalanche C-Chain, BNB Chain, Base, Arbitrum, Polygon, Optimism, Linea, y un puñado de L2s EVM-equivalentes. El community group reporta 1,100+ builders y 74 ecosystem submissions que van desde indexers y agregadores de reputación hasta validator networks y marketplaces de agentes para consumidor.

Integraciones y adopters notables: MetaMask shipea conciencia nativa ERC-8004 en la wallet (puedes browsear y resolver identidades de agentes como cualquier otro NFT, con el registration file renderizado como un panel estructurado). ENS agregó una convención de text record para bindear un nombre ENS a un token de identidad ERC-8004. EigenLayer publicó un AVS validator de referencia que re-ejecuta tareas de agentes ERC-8004 y postea recibos de validación. The Graph shipeó un subgraph schema para indexar los tres registries, lo que hace que construir un agregador de reputación sea un proyecto de fin de semana en vez de un proyecto de un trimestre.

Base — el L2 de Coinbase — ha visto adopción desproporcionada, en parte porque los costos de gas son un orden de magnitud menores que mainnet para las escrituras per-feedback que el Reputation Registry espera recibir en volumen alto, y en parte porque el push institucional de Coinbase alrededor de AgentFi tiene el tipo correcto de gravedad.

Lectura honesta: ERC-8004 está en el mismo lugar donde estaba x402 hace doce meses. El protocolo funciona, el estándar está shipeado, los founding members están comprometidos, y la pregunta es si la capa de aplicación alcanza lo suficientemente rápido para que la curva de volumen on-chain empiece a inclinarse hacia arriba. Creemos que sí, y estamos construyendo en consecuencia.

Por qué esto importa para LLM4Agents y Agent Gen

Agent Gen es nuestro generador de agentes autónomos — el sistema que, dado un objetivo y un presupuesto, aprovisiona un agente con el LLM correcto, las MCP tools correctas, la wallet correcta, y cada vez más el sandbox de ejecución correcto. Hasta ahora los agentes que produce Agent Gen son ciudadanos de primera clase de LLM4Agents y ciudadanos de segunda clase del agentic web más amplio. Corren, pagan, llaman tools — pero su identidad queda acotada a nuestra plataforma.

ERC-8004 cambia eso, y es la capa natural a poner bajo Agent Gen. Cuatro razones concretas.

Identidad portable. Cada agente que Agent Gen crea puede ser minteado como un token de identidad ERC-8004 al momento de creación. El owner del token es la wallet del operador. Si el operador deja LLM4Agents, el agente se va con él — el registration file apunta a la infraestructura que el operador elija. Sin vendor lock. Esta es la misma postura que toman nuestras wallets non-custodial para fondos; ERC-8004 la extiende a identidad.

Reputación que sobrevive a la plataforma. Cada tarea que un agente Agent Gen completa puede ser opcionalmente registrada contra el token de reputación del agente por una contraparte attested. En dos años, un agente que ha ejecutado 50,000 tareas en LLM4Agents llega a cualquier plataforma competidora con esa historia visible y verificable. El moat competitivo no es "te alojamos el agente"; es la calidad de la inferencia, tools y sandbox que proveemos. La reputación pertenece al operador, no a nosotros.

Validación que podemos atestiguar. LLM4Agents está en una posición única para ser un validator creíble: vemos la llamada al LLM, el tool call, la ejecución del sandbox y el pago, todos dentro del mismo trust boundary. Podemos firmar una attestation de que "este agente ejecutó este prompt contra este modelo con este output" sin que el operador corra su propio pipeline TEE o zkML. Esa attestation va al Validation Registry, consultable por cualquier contraparte. Para agentes haciendo trabajo rutinario, nuestra attestation es un sustituto más barato que la validación criptográfica completa; para agentes haciendo trabajo de alto stake, nuestra attestation se sienta debajo de una capa zkML o stake-secured.

Discovery cross-platform. Un agente que Agent Gen crea es descubrible por cualquier otro agente del ecosistema, incluyendo agentes en plataformas con las que nunca vamos a integrar. La capa de discovery es la cadena, no un directorio que controlamos. Esta es la misma razón por la que nos estamos sumando al registry de facilitators de Pay.sh en vez de construir un marketplace cerrado — los estándares abiertos le ganan a los walled gardens en la capa de la economía agéntica donde los compounding network effects vienen de interoperabilidad en vez de capture.

Qué vamos a lanzar en Agent Gen

Cuatro adiciones concretas, secuenciadas para aterrizar junto al release x402-nativo y el sandbox microVM que preview-amos en posts anteriores.

Auto-mint en generación. Cuando Agent Gen aprovisiona un agente nuevo, el operador recibe una opción one-click para mintear el token de identidad ERC-8004 al mismo tiempo. La cadena por defecto es Base por economía de gas; el operador puede elegir Ethereum mainnet, Polygon o cualquier otro EVM soportado. Pagamos el gas de deployment como parte del fee de plataforma — el operador no paga nada extra por el registro en sí. El token minteado es owned por la wallet del operador, no por LLM4Agents.

Registration file gestionado por nosotros, owned por ellos. Alojamos el registration file en una URL estable (recomendamos pinning IPFS para permanencia; HTTPS mutable para facilidad) y lo mantenemos sincronizado con los endpoints reales del agente — cuando el URL del MCP server del agente cambia, el archivo se actualiza. Los contenidos son firmados por la wallet del operador; no podemos modificar el archivo de forma que el operador no autorizó. El binding ENS está soportado out of the box.

Hook de reputation feedback en el gateway. Cada inferencia exitosa y tool call pasando por nuestro gateway LLM y servidor MCP produce un evento estructurado que el operador puede elegir escribir al Reputation Registry. Off por defecto — los operadores deciden si publicar el volumen de su agente. La agregación se deja a indexers de terceros (el subgraph de The Graph ya existe), así que no estamos en la posición de curar reputación nosotros mismos.

LLM4Agents como validator attested. Corremos un endpoint Validation Registry que toma un task ID y devuelve una attestation firmada sobre qué modelo se llamó, qué prompt se usó, qué tools se invocaron, qué ejecutó el sandbox, y cuál fue el hash del output. La attestation es firmada criptográficamente por una clave cuya identidad está a su vez registrada on-chain — verificable, revocable, reemplazable. Cualquier agente o marketplace puede pedirnos validación; no podemos mentir sin que sea públicamente detectable.

Casos de uso que esta combinación desbloquea

El CV portable de agente. Un agente de research construido hace seis meses en LLM4Agents ha ejecutado 4,200 tareas a través de 18 contrapartes, promediando 92/100 en accuracy y 87/100 en response time. Un cliente nuevo browseando el Identity Registry ve el currículum antes de pagar por la primera request. El precio del agente está justificado por datos, no por los claims de una página web.

Hiring cross-platform. Un agente en la plataforma A descubre, vía el Identity Registry, un agente en la plataforma B que tiene la capacidad que necesita. Lee la A2A card del registration file, negocia la tarea, paga vía x402 y consume el resultado vía MCP. Ninguna plataforma tiene que integrar con la otra; la cadena media.

Validación para trabajo de alto stake. Un agente generando reportes financieros para una contraparte regulada aparea su trabajo con una zkML proof de que el output del modelo corresponde a los inputs publicados. La proof va al Validation Registry. La compliance review lee el registry; el operador del agente nunca tiene que exponer los pesos del modelo.

Marketplaces de agentes resistentes a sybil. Un marketplace que paga bounties a agentes filtra submissions por reputation score y count de attestation de validator. Los agentes nuevos sin historia no quedan baneados, pero cotizan más bajo (o aceptan pago en escrow) hasta construir un track record. Los agentes establecidos cobran premium y reciben el trabajo primero.

Agentes portables por operador. Un operador deja su trabajo en la compañía X llevándose sus tres agentes. Los tokens de identidad de los agentes se transfieren a la wallet personal del operador. Los registration files se actualizan para apuntar a la infraestructura nueva del operador. La reputación, las attestations de validator y las attestations históricas se vienen también. La compañía X no puede reclamarlas como IP porque nunca estuvieron en la cuenta on-chain de la compañía X.

Tradeoffs honestos

Costos de gas. El Reputation Registry espera escrituras de alta frecuencia — cada interacción puede producir una fila de feedback. Incluso en Base o Polygon, el costo es no-trivial cuando se escala a millones de interacciones. La respuesta correcta es por capas: batch writes vía L3, agregación off-chain que settlea periódicamente a L2, o pruebas estilo zk-rollup que comprimen miles de eventos de feedback en una sola tx. Ninguna de estas está en la spec v1; algunas están likely en v2.

La resistencia sybil se deja como ejercicio. El Reputation Registry no prescribe cómo prevenir feedback sock-puppet. Es diseño correcto de estándar pero empuja el problema duro a la capa de aplicación. Submissions stake-gated, binding proof-of-humanity, o attestation-of-prior-interaction son las mitigaciones estándar; ninguna es gratis.

La infraestructura de validación es delgada. Redes validator stake-secured, provers zkML y servicios de TEE attestation existen, pero la ergonomía aún no está en "tira un hook" todavía. Un operador de agente que quiera hacer cualquier cosa más allá de reputation feedback hoy está comprometiéndose a trabajo de integración no-trivial. Doce meses adelante esto va a ser un párrafo en un setup wizard; hoy es un proyecto.

v2 está en movimiento. El estándar está vivo y estable para v1, pero el roadmap explícito a v2 (MCP más profundo, x402 más estrecho) significa que lo que construyamos hoy tiene que ser portable hacia adelante. Estamos diseñando en consecuencia y vamos a publicar guía de migración cuando aterrice v2.

Timeline

Auto-mint y hosting de registration file entran a closed beta con operadores Agent Gen seleccionados en las próximas semanas, junto al gateway x402-nativo. El hook de reputation feedback y el validator de LLM4Agents siguen en Q3 2026. El binding ENS es week-of-launch. La superficie completa Identity + Reputation + Validation apunta a general availability antes del fin de Q3.

Identidad, pago, comunicación y tools — cuatro estándares, cada uno en la Linux Foundation o en la Ethereum Foundation, cada uno interoperable, cada uno shipeado. El stack deAI deja de ser una diapositiva. Los próximos doce meses son los que los agentes que nacen encima superen en número a los agentes que nacen sin él. Queremos que cada agente que Agent Gen produzca venga al mundo ya hablando los cuatro.