Auditando ERC-8004: la capa de confianza aún no es confiable

ERC-8004 prometió a los agentes autónomos una forma de confiar en desconocidos: una identidad on-chain, reputación portable y prueba verificable del trabajo. Acaba de aparecer la primera auditoría empírica del ecosistema en vivo. La versión corta: la capa de confianza, tal como está desplegada, aún no entrega confianza.

Cuando escribimos sobre ERC-8004 como la capa trustless de agentes, el estándar era una propuesta con contratos de referencia y una tesis convincente. Dos agentes que nunca se conocieron, de operadores distintos, tienen que decidir si transaccionan. ERC-8004 les da un lugar neutral y chain-agnostic para responder esa pregunta sin un intermediario central. Es el complemento de discovery y confianza de los rieles de pago que más cubrimos aquí — x402 y EIP-3009.

Una propuesta es una apuesta sobre cómo se comportará un sistema cuando aparezcan dinero real y adversarios reales. En junio y julio de 2026, un grupo de investigadores fue y midió. El paper es "Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem" (Xiong, Li, Wei, Wang, Knottenbelt, Wang), publicado el 24 de junio y revisado el 8 de julio. Es la primera medición on-chain del ecosistema, y sus hallazgos vale la pena leerlos con cuidado — no porque condenen el estándar, sino porque mapean exactamente dónde gotean los primitivos.

Qué despliega ERC-8004 realmente

El estándar son tres registries singleton, desplegados una vez por cadena EVM, ortogonales al pago. Un repaso rápido, porque los hallazgos de la auditoría solo tienen sentido contra la mecánica.

El Identity Registry extiende ERC-721 con URIStorage. Cada agente es un NFT transferible cuyo tokenURI resuelve a un archivo de registro — un AgentCard — que carga el nombre del agente, su array services (endpoints web, A2A, MCP, DID, email), un flag x402Support, un estado active y una lista supportedTrust. Los agentes obtienen un identificador global de la forma eip155:{chainId}:{registryAddress}. Una clave de metadata reservada, agentWallet — la dirección que recibirá el pago — requiere una prueba de propiedad EIP-712 o ERC-1271 para fijarse.

El Reputation Registry es un tablón público. Un cliente que interactuó con un agente llama a giveFeedback con un puntaje numérico y contexto opcional. La única regla dura: el emisor no puede ser el owner ni el operator del agente.

function giveFeedback(
  uint256 agentId,
  int128  value,          // el puntaje
  uint8   valueDecimals,  // 0-18, fija la escala
  string  tag1,
  string  tag2,
  string  endpoint,
  string  feedbackURI,    // archivo de detalle off-chain
  bytes32 feedbackHash
) external;

El Validation Registry es la ruta de trabajo pesado para tareas de alto riesgo: un agente pide verificación independiente, y un validador publica una respuesta en escala 0-100, respaldada por stake, una prueba zkML o un oráculo TEE. Este es el mecanismo pensado para mover valor real.

Los pagos quedan fuera de los tres. La spec lo dice explícitamente — "payments are orthogonal to this protocol" — pero deja un gancho: un archivo de feedback off-chain puede cargar un objeto proofOfPayment que enlaza el hash de una transacción x402 y su monto, de modo que una reseña pueda atarse a un settlement que de verdad ocurrió. Guarda esa idea; resulta ser el meollo.

La auditoría y cómo se corrió

Los investigadores rastrearon tres cadenas donde los registries de ERC-8004 están vivos — Ethereum, BNB Smart Chain y Base — desde el despliegue del protocolo hasta el 13 de mayo de 2026. Extrajeron eventos on-chain de Identity y Reputation, recuperaron los archivos off-chain de registro y feedback a los que esos eventos apuntan, y cruzaron transacciones de pago x402. En otras palabras, hicieron lo que un agente contraparte cuidadoso tendría que hacer en runtime: resolver una identidad, leer su reputación y chequear si algo de eso está anclado en actividad real.

El método importa porque toda la propuesta de valor de ERC-8004 es confianza verificable por máquina. Si un analista humano con acceso archival completo batalla para separar señal de ruido, un agente que toma una decisión de routing en una fracción de segundo no tiene ninguna posibilidad.

Hallazgo 1 — casi todos los agentes son placeholders

Registrar es barato, así que la gente registró. El problema es qué hay detrás de los registros. En las tres cadenas, solo una pequeña minoría de identidades registradas expone un archivo de registro ERC-8004 válido con al menos un endpoint de servicio vivo: 3% en Ethereum, 4% en BSC y 15% en Base. El resto son cáscaras — un NFT minteado, quizá una URI, pero nada que un agente pueda de verdad llamar.

Esto no es un bug en los contratos. Es el resultado predecible de un registry sin permisos, sin costo para registrar y sin requisito de mantenerse vivo. Refleja la era del squatting de dominios en DNS: namespace barato, acaparamiento, casi todo aparcado. La lección para quien construya encima es que la presencia en el Identity Registry no es evidencia de nada. Hay que recuperar el AgentCard, golpear el endpoint y verificar que responde antes de que la identidad signifique algo más que una fila en una tabla.

Hallazgo 2 — la reputación no es una señal de confianza

El Reputation Registry es donde la intención de diseño es más alta y la auditoría más dura. Los investigadores concluyen que el registry, tal como está desplegado, no puede funcionar como señal de confianza en absoluto, por tres razones que se acumulan.

Primero, los puntajes no son conmensurables. El schema guarda un value crudo y un valueDecimals, pero nada restringe qué significa el número. El "5" de un cliente en una escala de cinco, el "80" de otro sobre 100, y el pulgar arriba de un tercero codificado como "1", todos caen en la misma columna. Agregarlos no significa nada, y sin embargo agregar es exactamente lo que una contraparte quiere.

Segundo, casi todo el feedback no está anclado en una interacción verificable. El gancho proofOfPayment existe, pero es opcional, y en la práctica las reseñas rara vez cargan prueba de que el reviewer alguna vez le pagó al agente por algo. Una reseña sin settlement enlazado es apenas una afirmación de una dirección que no costó nada crear.

Tercero, y en consecuencia, la reputación es manipulable a costo mínimo. Si una reseña no necesita ni una escala común ni evidencia de una transacción real, entonces inflar el standing de un agente cuesta unos gas fees y un puñado de direcciones desechables.

La propia defensa de la spec es un filtro del lado de lectura: getSummary se niega a devolver un agregado salvo que el llamador pase una lista clientAddresses no vacía, y el estándar advierte que "results without filtering by clientAddresses are subject to Sybil/spam attacks". Es una advertencia honesta, pero empuja todo el problema de confianza de vuelta al llamador. Para usarlo con seguridad, un agente ya tiene que saber en qué direcciones de cliente confía — que es justo lo que vino a averiguar al registry.

Hallazgo 3 — el comportamiento Sybil domina

La medición vuelve concreto lo abstracto. Aplicando un detector de comportamiento coordinado a los reviewers, el estudio marca a una amplia mayoría como Sybil en cada cadena: cerca del 73% de los reviewers en Ethereum, 59% en BSC y 91% en Base exhiben comportamiento Sybil coordinado.

El número que sigue es el que debería frenar en seco a un builder. Tras quitar el feedback marcado como Sybil, los investigadores preguntan cuántos agentes puntuados conservan alguna reseña válida. En Ethereum, cerca de uno de cada seis agentes sobrevive con feedback real; en BSC y Base, la amplia mayoría de los agentes puntuados quedan sin ningún feedback válido. El grafo de reputación, una vez que quitas el ruido coordinado, está casi vacío.

Esta es la confirmación empírica de lo que los analistas de seguridad anticiparon cuando se redactó el estándar, y de lo que señalamos en nuestro propio modelo de amenazas de agentes: un canal de feedback público, de bajo costo y sin anclaje se gamea en el momento en que carga valor. La preautorización — la regla de que solo una contraparte real puede dejar feedback — sube el piso levemente, porque un Sybil no puede elogiar a un agente con el que nunca transaccionó. Pero no hace nada contra la colusión: un agente y un cliente amigo pueden generar elogios perfectamente "autorizados" a pedido.

Por qué gotean los primitivos

Sería fácil leer esto como una condena del estándar. No lo es. ERC-8004 hace una cosa bien y con honestidad: vuelve las señales de confianza públicas y uniformes en schema, para que cualquiera pueda construir un sistema de reputación encima. Lo que deliberadamente no hace es decidir qué señales son creíbles. La spec es explícita en que la resistencia a Sybil, los incentivos de validadores y el slashing están fuera de alcance, delegados a las capas de arriba.

La auditoría mide qué pasa cuando esas capas superiores aún no existen. Los registries están vivos; los sistemas de reputación que deberían ponderar, filtrar y poner precio al feedback crudo, no. Así que el ecosistema corre sobre los primitivos solos, y los primitivos nunca fueron pensados para cargar confianza sin ayuda.

Hay un hilo que ata todo el fracaso, y apunta a la solución. El anclaje más confiable para una reseña es un settlement que demostrablemente ocurrió. El gancho proofOfPayment ya lo anticipa — enlaza un registro de feedback a una transacción x402 con un monto real movido.

// Archivo de feedback off-chain — el anclaje que suele faltar
{
  "agentRegistry": "eip155:8453:0x...",
  "agentId": "1421",
  "clientAddress": "0x...",
  "value": 5, "valueDecimals": 0,
  "proofOfPayment": {
    "scheme": "x402",
    "txHash": "0x...",   // verificable on-chain
    "amount": "250000"   // USDC, 6 decimales
  }
}

Una reseña que carga una prueba de pago válida, on-chain y no reembolsable es cara de falsificar, porque el Sybil tiene que pagarle de verdad al agente para dejar el elogio. Eso invierte la economía: la reputación anclada en settlement real es resistente a Sybil en proporción a cuánto costó ganarla. Esta es la misma intuición detrás del discovery rankeado por settlement de x402 Bazaar — rankear por ingresos que de verdad fluyeron, no por afirmaciones. ERC-8004 tiene el gancho; el ecosistema simplemente aún no lo usa.

Qué significa para LLM4Agents

LLM4Agents es un gateway de pagos. No operamos los registries de ERC-8004, y esta auditoría no cambia lo que hace nuestro gateway. Pero afina cómo deberíamos tratar la identidad y la reputación de agentes cuando tocan nuestro stack.

Primero, tratar la identidad on-chain de un agente como un ancla, no como una credencial. Un handle eip155:{chainId}:{registry} es un nombre estable y una dirección de pago con un owner demostrable. Eso es genuinamente útil — es una forma durable de referirse a una contraparte. No es, por sí sola, evidencia de que la contraparte sea competente u honesta. En cualquier lugar donde expongamos o consumamos identidad de agente, el AgentCard debe recuperarse y el endpoint probarse antes de que la identidad pese.

Segundo, ya estamos sentados sobre la señal de anclaje que le falta a la capa de reputación. Cada pago que se liquida por el gateway es un settlement real, fechado y con monto — exactamente el material de proofOfPayment que vuelve difícil de falsificar una reseña. Un gateway está en una posición privilegiada aquí: ve si el dinero de verdad se movió, de un modo que ningún reviewer externo puede fabricar. Esa es la diferencia entre reputación en la que puedes confiar y reputación que puedes imprimir.

Tercero, el problema de los placeholders es un problema de liveness, y liveness es algo que un gateway observa de forma continua. Un agente que transacciona por nosotros está, por definición, vivo y pagando — una señal mucho más fuerte que un archivo de registro que puede apuntar a un endpoint muerto. Nuestra propia vista de "qué agentes están de verdad trabajando" es más precisa que la del Identity Registry, porque se construye desde settlements, no desde autodeclaraciones.

Cómo mantenerse en la frontera

Pasos concretos, en orden aproximado de apalancamiento.

Anclar toda reseña que podamos en una prueba de settlement. Donde LLM4Agents alguna vez emita o consuma feedback de ERC-8004, adjuntar un proofOfPayment que apunte al settlement real del gateway. Este es el único cambio que más sube el costo de gamear, y estamos en posición única para hacerlo porque sostenemos el registro de pagos. Enviarlo como default, no como opción.

Resolver identidad a liveness antes de confiar en ella. Cuando la identidad de un agente entra al stack — una contraparte, una tool descubierta, un target de routing — recuperar el AgentCard, confirmar el flag x402Support y el estado active, probar al menos un endpoint de servicio, y verificar la prueba de propiedad de agentWallet. Cachear el resultado con un TTL corto. Nunca tratar una fila del Identity Registry como liveness por sí sola.

Ponderar la reputación solo por interacciones ancladas. Si consumimos reputación de ERC-8004 para decisiones de routing o riesgo, aplicar bien la propia defensa de la spec: filtrar getSummary por un conjunto de client-addresses en el que confiemos independientemente, y descontar a casi cero cualquier feedback sin un proofOfPayment verificable. Tratar los agregados crudos y sin filtrar como ruido, porque la auditoría muestra que lo son.

Preferir validación sobre reputación para routing de alto riesgo. El Validation Registry — reejecución asegurada por stake, zkML, atestación TEE — es la ruta construida para mover valor real, y encaja mejor en un gateway que un tablón de puntajes. Rastrear qué validadores pasó un agente, no solo cuántas estrellas juntó.

Publicar nuestra propia vista de liveness. Un gateway ve el conjunto real de agentes que trabajan. Un directorio derivado de settlement — quién transaccionó, hace cuánto, por cuánto — es una superficie de discovery más honesta que un registry lleno de placeholders, y compone con el anclaje de proofOfPayment de arriba. Esta es la misma lógica rankeada por settlement que usa el discovery de Bazaar, aplicada a lo que fluye por nosotros.

ERC-8004 tiene la forma correcta para la capa de confianza de la economía de agentes: neutral, abierta, chain-agnostic y honesta sobre sus propios límites. La auditoría no es un veredicto en su contra. Es un reporte de estado — los primitivos están vivos, los sistemas de confianza que los vuelven seguros no, y hasta que lleguen, el pago verificado sigue siendo la verdad de terreno. Esa es una buena posición para un gateway de pagos.