ERC-8004 Agent Liveness

Comprueba si un agente registrado en el registro de identidad real de ERC-8004 "Trustless Agents" (testnet de Base Sepolia) está realmente vivo ahora mismo -- no solo que se registró una vez. Candidato #10 de NEXUS -- build manual, no generado por FORGE, mismo patrón de activo manual en Cloud Run que los candidatos #3/#4/#6/#8/#9/#13/#16.

• POST /verify-registered-agent {"agent_id": 3} -- $0.10/llamada.

• Herramienta MCP verify_registered_agent en /mcp, mismos parámetros -- actualmente gratis, ver "Known limitations".

• GET /health, GET /.well-known/agent-card.json, GET /openapi.json (tiene x-payment-info), GET /.well-known/402index-verify.txt (archivo de verificaci\u00f3n de reclamaciones de 402index).

Qu\u00e9 es esto (y por qu\u00e9 el registro por s\u00ed solo no es suficiente)

ERC-8004 es un est\u00e1ndar de Ethereum real y funcional para la identidad de agentes en cadena: un agente acu\u00f1a un token ERC-721 en un IdentityRegistry, cuyo tokenURI apunta a un archivo de registro fuera de la cadena (JSON: nombre, descripci\u00f3n, endpoints declarados, flag active, m\u00e9todos de confianza soportados). Se lanz\u00f3 en Ethereum mainnet el 2026-01-29, con despliegues de referencia en Base mainnet y en las testnets de Base/Ethereum/Linea Sepolia. El registro es una acci\u00f3n \u00fanica en cadena -- un agente real registrado puede desaparecer por completo (proceso muerto, dominio caducado, endpoint cambiado) mientras que su registro en cadena permanece inalterado para siempre. Este activo cierra esa brecha: resuelve el registro en cadena real Y ejecuta un handshake real de MCP initialize contra cualquier endpoint que el registro declare, en el momento de la llamada -- la misma distinci\uf3n liveness-vs-registro que agent-verification-api (candidato #3) en la boleta para identidades reclamadas por dominio, aplicada aqu\u00e9 a las registradas en la cadena.

Fundamentaci\u00f3n (verificado en vivo esta sesi\u00f3n, no probada de una sola fuente)

• Direcciones de contrato, inicialmente de un resumen de terceros, verificadas independientemente mediante eth_getCode contra https://sepolia.base.org antes de confiar en ellas: IdentityRegistry (0x8004A818BFB912233c491871b1d84c1A494BD9e) y ReputationRegistry (0x8004B663056A597Dffe9eCcC1965A193B7388713) ambas tienen c\u00f3digo desplegado real no vac\u00f3.

• ABI, extra\u00f3 de la implementaci\u00f3n de referencia (github.com/erc-8004/erc-8004-contracts/abis), probado en vivo con 3 agentes reales registrados (agentId 1-3) antes de confiar para este activo:

  • El tokenURI del agente 1 resuelve a una URI data:application/json;base64,....

  • Los del agente 2 resuelve a ipfs://bafkreif....

  • El del agente 3 resuelve a una URL real https://api.snack.money/agent/.../registration.json. Los 3 esquemas de URI reales de ERC-8004 se confirmados funcionando en vivo, no solo el que los propios ejemplos del especumentaci\u00f2 muestran.

• getSummary requiere un array clientAddresses no vac\u00f3 -- confirmado en vivo (revierte con "clientAddresses" required`` en caso contrario). Este activo llama primero a getClients(agentId)y solo llama agetSummarysi devuelve al menos una direcci\u00f3nde; los agentes con cero feedback reportan correctamentefeedback_count: 0` sin error RPC.

• agentId=999999 (un token inexistente real) revierte correctamente con un error personalizado, confirmado en vivo -- mapeado a AGENT_NOT_FOUND, no a un fallo.

Motor de handshake de MCP: reutilizado, no redisado

Seg\u00fan la instrucci\u00f3n expl\u00f3 del resumen \u00f3ecta, _nexus_validate_public_url, _nexus_no_redirect_mcp_http_client y _mcp_handshake_check se portan palabra por palabra desde manual_assets/agent-verification-api/main.py (candidato #3) -- misma comprobaci\u00f3n previa de SSRF, misma postura sin redirecciones (la correcci\u00f3n exacta que se aplic\u00f3 all\u00b3despu\u00e9s de que la revisi\u00f3n de seguridad del 2026-08-22 encontrara una bypass SSRF basada en redirecci\u00f3n), mismo timeout acotado. Sin m\u00e1s cambios que la constante del nombre del activo. La propia contribuci\u00f3n de este activo es instream force: resolver un archivo de registro ERC-8004 (3 esquemas de URI) y elegir un endpoint real de su array endpoints para pas\u00e1rselo a ese motor.

Alcance de la cadena, a prop\u00f3sito

Solo Base Sepolia testnet -- la misma red que todos los dem\u00e1rculos de x402 de this codebase ya usan. ERC-8004 tambi\u00e9 live in Base mainnet and Ethereum mainnet (verified in this session), but this asset does not expose a chain you select: no evidence that a buyer needs mainnet for a 7-day probation candidate (CLAUDE.md SS3).

Target de despliegue: Run en Cloud

Ninnes pipeline que los candidatos #4/#3/#6/#8/#9/#13/#16 -- consulta en skills/infra-deploy-ops.

# 1. First deploy -- PUBLIC_DOMAIN not known yet, every real request 421s until step 2.
./scripts/deploy_cloud_run.sh erc8004-agent-liveness manual_assets/erc8004-agent-liveness

# 2. Grab the printed *.run.app URL, then (only if it differs from env-vars.deploy.yaml's guess):
gcloud run services update erc8004-agent-liveness --region us-central1 --project nexus-505016 \
    --update-env-vars PUBLIC_DOMAIN=<the-real-domain>

Limitaciones conocidas (deliberadamente no corregidas para que -- CLAUDE.md secci\u00f3n SS3 --, no hay puerta de calidad sin evidencia)

• MCP tool call no son cargos. Mismo patr\u00f3n de llamada en proceso que todos los activos manuales de este codebase.

• active: false corta circuita a REGISTERED_INACTIVE incluso si el endpoint est\u00e1 realmente vivo. Conf\u00ed en la seva auto-declaraci\u00f3 del registrador en ese \u00fanico caso on una comprobaci\u00f3 independiente de liveness -- un agente que miente y no est\u00e1 activo (incenti inusual) ser\u00ed reportado incorrectamente. Aceptado: active es la propia se\u00f1al del registrante por el dise\u00f1o del est\u00e0ndar; sobreescr\u00edrla ser\u00f3 cuesti\u00f3n desconocer el propio campo del est\u00e0ndar. REGISTERED_UNREACHABLE (la modalidad de fallo contraria -- declarado activo pero no alcanzable) is the real added value of this asset and does NOT have the same short-circuit.

  • La selecci\u00f3 de endpoint es heur\u00edstica, no un requisito del est\u00e0ndar. El array endpoints del est\u00e0d es de forma libre; este activo prefiere mcp/x402/a2a/web (en ese orden) y falls back a "first entry" si no encuentra. Una registrado con un end point único real \u00fanico que funciona via MCP pero con un no listado en name a\u00db seguir\u00eda siendo recogido (combinaci\u00f3n de nombres of de nombres no es la \u00f\u00eau camino -- el fallback por nombres can\u00f3 pour la cubre), pero - en un registro con M\u00faltiples embargo, si ninguno de los nombres preferidos apunta al que est\u0 alarm live, could, un endpoint incorrecta reports REGISTERED_UNREACHABLE in live.

• Redirecci\u00f3n is single IPFS only -- no fallback gateway: a registry whose CID is not anchored/unreachable via that gateway reports REGISTRATION_FETCH_FAILED even if the content exists on IPFS.

• No rate limiter per caller. Fine para una ventana de medici\u00f (desechable de 7 d\u00ed).

• reputation es una se\u00f1al self-reported, sin barreras, sin stake. Cualquier direcci\u00f3n EVM of ReputationRegistry.giveFeedback and agentId -- feedback_count/average_value are real numbers but no one can stop is the agent owner from Sybil-feeding through itself. There is **"in\u00f3falls", treat as una se\u00f1al no verificada, nor como trust score (this caveat also in the reputation field description in the API schema, no solo aqu\u00f3).

Puerta de calidad (2026-08-23, from design, not retro)

Mismo procedimiento de 2 agents que candidates #3/#4/#6/#8/#9/#13/#16 (security lens; functional+quality+buyer-experience lens), went before the first deploy. Hallazgos realas, todos solucionados before production.

• Budget (0 exploitable findings): confirmado que las 3 funciones portadas literal (mismas palabras) de agent-verification-api/main.py (_nexus_validate_public_url, _nexus_no_redirect_mcp_http_client, _mcp_handshake_check) carry el fix SSRF bypass real, byte a byte, and that the new https:///IPFS registration fetch path introduce the same defensive layer one earlier layer -- confirmed NOT reintroduce the same bug type. Two low/informational findings, both addressed as dee-dive in (even if no confirmed exploit): IPFS CID concatenation (confirmed live, no escape from the ipfs.io host, but use urllib.parse.quote only a single path segment anyway) and data: URI base64 decode (checked linear/no ampliation - no fix needed).

• Funcional/calidad/la experiencia del comprador (1 must-fix, 1 medio, que se apply): un archivo de registro whose top-level JSON is not an object (array/string/number -- registrant-controlled) passed through as "ok": True with a no-dict registration, while all downstream consumers (_pick_liveness_endpoint, _classify_verdict, response body) assumed it was a dict - an unhandled AttributeError becomes an unhandled 500 but after x402 payment is already settled. fix: both parseo points in _resolve_registration_file now return registration_not_an_object (rechaza non-dict result) before returning "ok": True. Also proceeded: the known caveat about reputation (see above and in the schema field). Wt - detail "nice-to-have-fix": duplicate-name endpoint shadowing, unverified casing field for 2 keys optional registration) kept as is -- still no evidence that matters to real registry, coincident with CLAUDE.md SS3.

• Verified exit to exit (e2e) with real production data before and after: 4 real ERC-8004 agent IDs in Base Sepolia (1, 2, 3, and real non-existent 999999) each gets the correct irrelevant (NOT "registered" but REGISTERED_UNREACHABLE REGISTERED_UNREACHABLE, REGISTRATION_FETCH_FAILED 2x (a real IPFS gateway timeout, and a real dead https:// URL – both legit, no bug), and AGENT_NOT_FOUND (real on-chain revert) -- plus real reputation data (74 feedback entries from 12 distinct clients on agent 1).

Medici\u00f3n (candidato #10, ventana de 7 d\u00ed)

Ventana de 7 d\u00ede desde 2026-08-23 (real date de despliegue) -> decision el 2026-08-30. True fact \u00fanico: traffic_events/revenue_events/mcp_call_events (asset_name =`` 'erc8004-agent-liveness'), no Cloud Run logs. D\u00eda 7: si no hay tr\u00e1fico real (filtrado crawlers), pause/delete the Cloud Run service (gcloud run services delete erc8004-agent-liveness --region us-central1 --project nexus-505016`).