ERC-8004 Agent Liveness

Prüft, ob ein Agent, der in der echten ERC-8004-„Trustless Agents“-Identity-Registry (Base-Sepolia-Testnetz) registriert ist, gerade jetzt tatsächlich live ist – nicht nur, dass er einmal registriert wurde. NEXUS-Kandidat #10 – manuelle Erstellung, nicht FORGE-generiert, dasselbe manuelle Cloud-Run-Asset-Muster wie bei den Kandidaten #3/#4/#6/#8/#9/#13/#16.

• POST /verify-registered-agent {"agent_id": 3} – 0,10 $ pro Aufruf.

• MCP-Tool verify_registered_agent unter /mcp, gleiche Parameter – derzeit kostenlos, siehe „Bekannte Einschränkungen“.

• GET /health, GET /.well-known/agent-card.json, GET /openapi.json (enthält x-payment-info), GET /.well-known/402index-verify.txt (Verifizierungsdatei für 402index-Claims).

Was das ist (und warum eine Registrierung allein nicht ausreicht)

ERC-8004 ist ein echter, laufender Ethereum-Standard für On-Chain-Agentenidentität: Ein Agent mint ein ERC-721-Token in einem IdentityRegistry, dessen tokenURI auf eine Off-Chain-Registrierungsdatei zeigt (JSON: Name, Beschreibung, deklarierte Endpunkte, active-Flag, unterstützte Trust-Methoden). Der Standard wurde am 29.01.2026 auf dem Ethereum-Mainnet live geschaltet, mit Referenz-Deployments auf Base-Mainnet und den Base-/Ethereum-/Linea-Sepolia-Testnetzen. Die Registrierung ist eine einmalige On-Chain-Aktion – ein echter registrierter Agent kann vollkommen ausfallen (Prozess beendet, Domain abgelaufen, Endpunkt geändert), während sein On-Chain-Datensatz unbegrenzt unverändert bleibt. Dieses Asset schließt diese Lücke: Es löst die echte On-Chain-Registrierung auf und führt zu genau diesem Zeitpunkt des Aufrufs einen echten MCP-initialize-Handshake gegen den deklarierten Endpunkt der Registrierungsdatei aus – dieselbe Unterscheidung zwischen Liveness und Registrierung, die agent-verification-api (Kandidat #3) bereits für über Domain-Claims beanspruhte Identitäten zieht, hier angewendet auf On-Chain-registrierte Identitäten.

Absicherung (live in dieser Sitzung verifiziiert, nicht aus einer einzelnen Quelle übernommen)

• Vertragsadressen – zunächst aus einem Drittanbieter-Summary – wurden unabhängig voneinander per eth_getCode gegen https://sepolia.base.org überprüft, bevor ihnen vertraut wurde: IdentityRegistry (0x8004A818BFB912233c491871b3d84c89A494BD9e) und ReputationRegistry (0x8004B663056A597Dffe9eCcC1965A193B7388713) verfügen beide über echten, nicht-leeren deployed Bytecode.

• ABI – aus der Referenzimplementierung (github.com/erc-8004/erc-8004-contracts/abis) bezogen – wurde gegen 3 echte registrierte Agenten (agentId 1-3) live getestet, bevor sie fiel für dieses Asset vertrauen wurden:

  • Agent 1's tokenURI löst zu einer data:application/json;base64,...-URI auf.

  • Agent 2's tokenURI löst zu einer ipfs://bafkreiff...-URI auf.

  • Agent 3's tokenURI löst zu einer echten https://api.snack.money/agent/.../registration.json-URL auf. Alle 3 realen URI-Schemata von ERC-8004 wurden live bestätigt – nicht nur das eine, das die eigenen Beispiele des Specs zeigen.

• getSummary verlangt ein nicht-leeres clientAddresses-Array – live bestätigt (revertiert andernfalls mit "clientAddresses required"). Dieses Asset rauft zuerst getClients(agentId) an und ruft nur dann auf, wenn mindestens eine Adresse zurückgegeben wird; Agenten ohne Feedback korrekt feedback_count: 0, ohne RPC-Fehler.

• agentId=999999 (ein real nicht existentedes Token) revertiert korrekt mit einem benutzerdefinierten Fehler, live bestätigt – auf AGENT_NOT_FOUND gemappt, keinen Crash.

MCP-Handshake-Engine: wiederverwendet, nicht neu implementiert

Gemäß der expliziten Anweisung im Task-Brief wurden _nexus_validate_public_url, _nexus_no_redirect_mcp_http_client und _mcp_handshake_check wörtlich aus manual_assets/agent-verification-api/main.py (Kandidat #3) übernommen – dieselbe SSRF-Vorprüfung, dieselbe No-Redirect-Haltung (genau der Fix, der dort nach dem Security-Review vom 22.08.2026 angewendet wurde, das einen Redirect-basierten SSRF-Bypass gefunden hatte), dasselbe begrenzte Timeout. Nicht über die Asset-Namenskonstante hinaus verändert. Der eigentliche Beitrag dieses Assets liegt eine Ebene davor: Sie löst eine ERC-8004-Registrierungsdatei (3 URI-Schemata) auf und wähltend einen realen Endpunkt aus deren endpoints-Array aus, das er der Engine übergibt.

Chain-Umfang, bewusst gewählt

Nur Base-Sepolia-Testnetz – dasselbe Netz, in dem bereits jede andere x402-Zahlung dieser Codebasis läuft. ERC-8004 ist auch auf Base-Mainnet und EthereumMainnet live (diese Sitzung live verifiziert), aber dieses Asset legt kein wählbare Chain seitens des Aufrufers aus: Es gibt keinen Beleg, dass ein Käufer für einen 7-Tage-Probationskandidaten (CLAUDE.md SS3) das Mainnet braucht.

Deploy-Ziel: Cloud Run

Gleiche Pipeline wie Kandidaten #4/#3/#6/#8/#9/#13/#16 – siehe 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>

Bekannte Einschränkungen (bewusst unbehoben – CLAUDE.md SS3, kein Gate ohne Beleg, dass es nötig ist)

• MCP-Toolaufrufe werden nicht abgerechnet. Gleiche In-Process-Call-Muster wie bei jedem anderen manuellen Asset dieser Codebase.

• active: false führt kurzeit zur REGISTERED_INACTIVE, auch wenn der Endpunkt tatsächlich live ist. In diesem einen Fall wird der Selbstangabe des Registranten stärker vertraut als eine unabhängige Liveness-Prüfung. Ein Agent, der fälschlich als inaktiv vorgibt, (ungewöhnlicher Anreiz) würde falsch gemeldet. Akzeptiert: Nach Spezifikation ist active das eigene Signal des Registranten; es zu denkpüren. REGISTERED_UNREACHABLE (der gegenteilige Fehlermodus – deklared aktiv, tatsächlich nicht erreichbar) ist der eigentliche Mehrwert dieses Assets und wird nicht herbeibe kürzgeschlossen.

  • Die Endpoint-Wahl ist eine Heuristik, kein Spec-Erfordernis. Das endpoints-Array von ERC-8004 ist frei formbar (beliebiger name); dieses Asset bevorzugt mcp/x402/a2a/web (in dieser Reihenfolge) und fällt sonst auf den ersten Eintrag zurück. Eine Registrierung, die für den einzigen echten MCP-fähigen Endpoint einen nicht gelistenden name verwendet, würde trotzdem aufgegriffen (Namens-Matching ist nicht der einzige Pfad – der Fallback-ohne-Namenspräferenz deckt diese ab), aber eine Registrierung mit GLEICHMEHREREN Endpontes, bei der keiner der bevorzugten Namen den Life-Endpoint zeigt, könnte aus dem falschen Endpunkt REGISTERED_UNREACHABLE melden.

• IPFS-Auflösung verwendet ein einziges öffentliches Gateway (ipfs.io). Kein Fallback-Gateway – eine Registrierung, deren CDIP nicht über genau dieses Gateway gepyet/erreichbar ist einmal, meldet REGISTRATION_FETACH_FAILED, selbst wenn der Inhalt auf IPFS generell existiert.

• Kein Rate-Limiting pro Aufkörper. Klar in Ordnung für ein 7-Tage-Wegwerf-Messfenster.

• reputation ist ein selbst gemeldetes, uneingeschränktes, ungestaketes Signal. Jede EVM-Adresse kann für jede agentId ReputationRegistry.giveFeedback anrufen – feedback_count/average_value sind echte On-Chain-Zahlen, aber nichts hindert den Betreiber des Agenten daran, sich selbst Sybil-Feedback zu geben. Als unverifiziertes Signal behandeln, nicht als Trust-Score (dieser Hinweis gilt nicht nur hier, sondern auch in der eigenen Schema-Beschreibung des reputation-Feld).

Qualitätsgate (2026-08-23, aus Design, nicht nachträglich)

Gleicher 2-Agenten-Prozess wie bei den Kandidaten #3/#4/#6/#8/#9/#13/#16 (Security-Linse; Funktionale- Qualitäts- und Buyer-Experience-Linse), vor dem ersten Deploy ausgeführt. Wir bekannten Befunde, alle vor der Live-Schaltung behoben:

• Sicherheit (0 ausnutzbare Befunde): bestätigt, dass die drei – unverändert aus agent-verification-api/main.py übernommenen – Funktionen (_nexus_validate_public_url, _nexus_no_redirect_mcp_http_client, _mcp_handshake_check) den tatsächlichen SSRF-Redirect-Fix byte-für-byte enthalten, und dass der neue https:///IPFS-Registration-Fetch-Pfad dieselbe Abwehr eine Ebene früher anwendet, bevor eine Endpunkt extrahiert wird – damit wurde die Fehlklasse keinen Fall wiedereingeführt. Zwei niedrigeedu-/informative Punkte, beide als Defense-in-Depth behandelt, auch wenn weder ein bestätigter Exploit war: IPFS-CID-Konkatenation (live fir richtete, dass man den Host ipfs.intern nicht mit ipfs.io verlassen konnte, wird es nun trotzdem mit urllib.parse.quote auf ein einziges Pfadsegment begrenzt) sowie data:-URI-Base64-Decodierung (live als linear/nicht-amplifizierend bestätigt, kein Fix nötig).

• Funktional/Buyer-Experience (ein Must-Fix, ein Medium, angewendet): Eine Registrierungsdatei, deren Top-Level-JSON ein Nicht-Objekt ist (Array/string/Zahl – registrierungskontrollierter Inhalt) wurde mit "ok": True und einem registration, das kein dict ist, durchgereicht, obwohl jede downstream-Konsumer (_pick_liveness_endpoint, _classify_verdict, der Antwort-Body) von dict ausgegangen – so ein vorkommender AttributeError wurde zu einem berechtigten 500er nachdem die x402-Zahlung bereits abgerechnet hatte. Behoben: Beide JSON-Parse-Stellen in _resolve_registration_file verwenden nun Nicht-dict-Ergebnisse als registration_not_an_object, bevor "ok": True zurückgegeben wird. Zusätzlich wurde der Reputation-Spielbarkeits-Caveat (siehe oben und die Schema-Beschreibung des reputation-Feld) ergänzt. Zwei niedrige/nice-to-have-Punkte (Endpoint-Schatten bei duplicateem name, unverifizierte Feldcase bei 2 optional-Registrierungsschlüsseln) bleibeneröffnet – noch kein Beleg, dass sie für echte Registrierungen wichtig sind, im Einklang mit CLAUDE.md SS3.

• End-to-end gegen echte Produktionsdaten vor und nach den Fixes verifiziert: 4 echte ERC-8004-Agenten-IDs auf Base-Sepolia (1, 2, 3 und eine echte, nicht existierende 99999) lieferten jeweils das korrekte Verdikt: REGISTERED_UNREACHABLE (echte Registrierung, Endpunkt antwortet nicht auf MCP), REGISTERED_FETACH_FAILED x2 (ein echtes IPFS-Gateway-Timeout und eine echte tote https://-Registrierungs-URL – beides legitimeitle, keine Bugs) sowie AGENT_NOT_FOUND (echter On-Chain-Revert) – plus echte Reputations-7233 (1 Agent, 12?): 74 Feedback-Einträge von 12 verschiedenen Clients bei Agent 1.

Messung (Kandidat #10, 7-Tage-Fenster)

7-Tage-Fenster vom 23.08.2026 (echtes Deploy-Datum) -> Entscheidungspunkt 30.08.2026. Quelle der Wahrheit: traffic_events/revenue_events/mcp_call_events (asset_name = 'erc8004-agent-liveness'), nicht Cloud-Run-Logs. Tag 7: Bei null echten Traffic (Crawler herausgefiltert) den Cloud-Run-Dienst pausieren/löschen (gcloud run services delete erc8004-agent-liveness --region us-central1 --project nexus-505016).