ERC-8004 エージェント死活監視

実際のERC-8004「Trustless Agents」IDレジストリ（Base Sepoliaテストネット）に登録されているエージェントが、単に登録されているだけでなく、今まさに生存しているかをチェックします。NEXUS候補 #10 -- 手動ビルド、FORGE生成ではありません。候補 #3/#4/#6/#8/#9/#13/#16 と同じ手動Cloud Runアセットパターンです。

• POST /verify-registered-agent {"agent_id": 3} -- 1回につき$0.10。

• MCPツール verify_registered_agent（/mcp 内、同パラメータ）-- 現在無料。「既知の制限事項」を参照。

• GET /health、GET /.well-known/agent-card.json、GET /openapi.json（x-payment-info を含む）、 GET /.well-known/402index-verify.txt（402indexクレーム検証ファイル）。

これが何か（そして登録だけでは不十分な理由）

ERC-8004 は、オンチェーンエージェントアイデンティティのための実際に稼働しているEthereum標準規格です。エージェントは IdentityRegistry 内でERC-721トークンをミントし、その tokenURI はオフチェーン登録ファイル（JSON: 名前、説明、宣言されたエンドポイント、active フラグ、サポートされる信頼方式）を指します。この規格は2026-01-29にEthereumメインネットで稼働開始し、BaseメインネットおよびBase/Ethereum/Linea Sepoliaテストネットにリファレンスデプロイがあります。登録は一度きりのオンチェーンアクションです -- 実際に登録されたエージェントは完全に沈黙しても（プロセス停止、ドメイン失効、エンドポイント変更）、オンチェーン記録は永遠に変更されずに残り続けます。このアセットはそのギャップを埋めます：実際のオンチェーン登録を解決し、かつ登録が宣言するエンドポイントに対して、呼び出し時点で実際のMCP initialize ハンドシェイクを実行します -- agent-verification-api（候補 #3）がドメイン主張アイデンティティについてすでに示している死活vs登録の区別を、ここではオンチェーン登録アイデンティティにも適用したものです。

Related MCP server: agent-verification-api

根拠（単一の情報源からの仮定ではなく、今回のセッションでライブ検証済み）

• コントラクトアドレス：当初はサードパーティの要約から取得。信頼する前に https://sepolia.base.org に対する eth_getCode で独立検証済み：IdentityRegistry (0x8004A818BFB912233c491871b3d84c89A494BD9e) と ReputationRegistry (0x8004B663056A597Dffe9eCcC1965A193B7388713) はどちらも実際の非空デプロイ済みバイトコードを持ちます。

• ABI：リファレンス実装（github.com/erc-8004/erc-8004-contracts/abis）から取得し、このアセットで信頼する前に3つの実際の登録エージェント (すべて1〜3) に対してライブテスト済み：

  • エージェント1の tokenURI は data:application/json;base64,... URIに解決されます。

  • エージェント2のは ipfs://bafkreiff... に解決されます。

  • エージェント3のは実際の https://api.snack.money/agent/.../registration.json 以降。 ERC-8004の実際の3つのURIスキームすべてが仕様の例で示されているものだけでなく、ライブで動作確認済みです。

• getSummary は空でない clientAddresses 配列を必要とします -- ライブで確認済み（そうでない場合は "clientAddresses required" でrevert）。このアセットは最初に getClients(agentId) を呼び出し、少なくとも1つのアドレスが返された場合のみ getSummary を呼び出します。フィードバックがゼロのエージェントはRPCエラーなしで正しく feedback_count: 0 を報告します。

• agentId=999999（実際に存在しないトークン） はカスタムエラーで正しくrevertされます。ライブで確認済み -- AGENT_NOT_FOUND にマッピングされ、クラッシュはしません。

MCPハンドシェイクエンジン：再実装ではなく再利用

タスク指示書の明示的な指示に従い、_nexus_validate_public_url、_nexus_no_redirect_mcp_http_client、 および _mcp_handshake_check は manual_assets/agent-verification-api/main.py （候補 #3）から逐語的に移植されています -- 同じSSRF事前チェック、同じなリダイレクト禁止の姿勢（2026-08-22のセキュリティレビューでリダイレクトベースのSSRFバイパスが発見された後に適用された修正とまったく同じ）、同じ制限付きタイムアウト。アセット名の定数以外は変更されていません。このアセット自身の貢献はその上流にあります：ERC-8004登録ファイル（3つのURIスキーム）を解決し、その endpoints 配列から実際のエンドポイントを選んで、そのエンジンに渡すことです。

チェーンスコープ、意図的

Base Sepoliaテストネットのみ -- このコードベース内の他のすべてのx402支払いがすでに使用しているのと同じネットワークです。ERC-8004はBase MainnetとEthereum Mainnetでも稼働しています（今回のセッションでライブ検証済み）が、このアセットは呼び出し側がチェーンを選択できるようにはしていません：7日間の仮採用候補（CLAUDE.md SS3）にメインネットを必要とする買い手がいるという証拠はありません。

デプロイ先: Cloud Run

候補 #4/#3/#8/#9/#13/#16 と同じパイプライン -- 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>

既知の制限事項（意図的に修正しないまま -- CLAUDE.md SS3、必要性の証拠なしに門を付けない）

• MCPツール呼び出しは課金されません。 このコードベースの他のすべての手動アセットと同じインプロセス呼び出しパターンです。

• active: false は、エンドポイントが実際に稼働していても REGISTERED_INACTIVE にショートサーキットされます。 その単一のケースでは、独立した死活確認よりも登録者自身の申告を信頼します -- 非アクティブ状態であると虚偽申告するエージェント（変則的なインセンティブ）は誤って報告されます。認めます：active は仕様設計上、登録者自身のシグナルであり、それを上書きすることは標準の自己のフィールドに再解釈を加えることになります。 REGISTERED_UNREACHABLE（逆の抑制モード -- アクティブ宣言されたが実際には到達不能）はこのアセットの真の付加価値であり、同様にはショートサーキットされません。

  • エンドポイント選択はヒューリスティックであり、仕様要件ではありません。 ERC-8004の endpoints 配列は自由形式です （任意の name）このアセットは mcp/x402/a2a/web の順に優先し、最初の入力が残ります。 リスト外の name を唯一の実際のMCP対応エンドポイントとして使用する登録でも依然として選択されます（名前マッチングが唯一の経路ではない -- 名前なし優先フォールバックがそれをカバー）、ただし、複数のエンドポイントがあり、推奨名のどれもライブのものを示していない登録では、誤ったエンドポイントに基づいて REGISTERED_UNREACHABLE と報告される可能性があります。

• IPFS解決は単一のパブリックゲートウェイ（ipfs.io）を使用します。 フォールバックゲートウェイはありません -- この特定のゲートウェイ経由でCIDがピン留め/到達可能でない登録は、IPFSにコンテンツが存在する場合でも REGISTRATION_FETCH_FAILED と報告されます。

• 呼び出し元あたりのレート制限はありません。 7日間の使い捨て測定ウィンドウには問題ありません。

• reputation は自己報告型、ゲートなし、ステークなしのシグナルです。 どんなEVMアドレスでも ReputationRegistry.giveFeedback を任意の agentId に対して呼び出すことができます -- feedback_count/average_value は実際のオンチェーン数値ですが、エージェント自身の所有者が自身にSybilフィーディングするのを妨げるものはありません。信頼スコアではなく、未検証のシグナルとして扱ってください（この注意事項はAPIスキーマの reputation フィールド自身の説明にも記載されており、ここだけではなくスキーマにもあります）。

品質ゲート（2026-08-23、事後ではなく設計から）

候補 #3/#4/#6/#8/#9/#13/#16 と同じ2エージェントプロセス（セキュリティレンズ、機能+品質+ベアヤー体験レンズ）を、最初のデプロイ前実行。実際のフィンド..ングスはすべてゴーイングライブ前に修正済み：

• セキュリティ（悪用可能なフィンドは0件）： agent-verification-api/main.py から逐語的にインポートした3つの関数 （_nexus_validate_public_url、_nexus_no_redirect_mcp_http_client、 _mcp_handshake_check）が実際のSSRFリダイレクト修正をバイト単位で伝承していること、そして新しい https:///IPFS登録取得パスが、エンドポイントが抽出される前に、1層早い同種の防御策を適用していることを確認しました -- そのバグのクラスを再導入しないことを確認。低/情報レベルの2項目はどちらも確認可能なエクスプロイトではありませんでしたがディフェンス・イン・デプスとして対応： IPFS CID結合（ライブ確認済みで ipfs.io ホストを逃れることはできないが、より安全に urllib.parse.quote を使って単一パスセグメントに限定）、および data: URIbase64デコード（線形/増幅なしを確認、修正不要）。

• 機能/ベアヤー体験（必須修正1件、中程度1件、適用済み）：トップレベルJSONがオブジェクトでない登録ファイル（配列/文字列/数値 -- 登録者入力コンテンツ）が、registration がディクショナリでないまま "ok": True として通過しました。すべての下流のコンシューマー（_pick_liveness_endpoint、_classify_verdict、応答ボディ）がディクショナリだと仮定していたため、捕捉されていない AttributeError が x402支払いがすでに確定した後 の未処置500エラーとなりました。修正： _resolve_registration_file 内の両方のJSONパース地点で、非ディクショナリ結果を registration_not_an_object として "ok": True を返す前に拒否するようにしました。また、レピュテーションのゲーム性の注意事項を追加しました（上記「既知の制限事項」と reputation フィールドのスキーマ説明を参照）。 低/個別2件（重複 name エンドポイントのシャドーイング、2つのオプション登録キーの未検証フィールドケーシング）はそのまま残しています -- 実際の登録でどちらかが重要という証拠がまだないため、CLAUDE.md SS3 に一致します。

• 修正前後の実本番データに対するエンドツーエンド検証（正しく実施：4つの実際のERC-8004エージェントIDがBase Sepoliaテストネット（1、2、3、実際の存在しない999999）で、それぞれ正しい判定を生成しました -- REGISTERED_UNREACHABLE（実際の登録、エンドポイントがMCPに応答しない）、REGISTRATION_FETCH_FAILED ×2 （実際のIPFSゲートウェイのタイムアウト、そして実際の死んだ https:// 登録URL -- どちらも正当、バグではありません）、 AGENT_NOT_FOUND（実際のオンチェーンリバート）-- さらに実際のレピュテーションデータが含まれます（エージェント1に対する12の異なるクライアントからの74件のフィードバック）。

測定（候補 #10、7日間ウィンドウ）

7日間ウィンドウを2026-08-23（実際のデプロイ日）から開始 → 判定予定日 2026-08-30。真実のソース： traffic_events/revenue_events/mcp_call_events（asset_name = 'erc8004-agent-liveness'）、Cloud Run ログではありません。7日目：実トラフィックがゼロの場合（クローラーを除外した場合）、Cloud Runサービスを一時停止/削除します （gcloud run services delete erc8004-agent-liveness --region us-central1 --project nexus-505016）。