erc8004-agent-liveness

ERC-8004 エージェントの稼働確認

実際の ERC-8004「Trustless Agents」Identity Registry（Base メインネット――支払いとレジストリの読み取りの両方。詳しくは以下の「対象チェーン」を参照）に登録されたエージェントが、登録されたことがあるだけでなく、現在実際に稼働しているかを確認します。NEXUS 候補 #10――手動ビルドであり、FORGE による生成ではありません。候補 #3/#4/#6/#8/#9/#13/#16 と同じ、手動で Cloud Run アセットを作成するパターンです。

• POST /verify-registered-agent {"agent_id": 3} -- 1 回あたり $0.10。
• /mcp の MCP ツール verify_registered_agent（同じパラメーター）――現在は無料です。詳しくは「既知の制限事項」を参照してください。
• GET /health、GET /.well-known/agent-card.json、GET /openapi.json（x-payment-info を含む）、 GET /.well-known/402index-verify.txt（402index のクレーム検証ファイル）。

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

ERC-8004 は、オンチェーンのエージェント ID を定める実際に稼働中の Ethereum 標準です。エージェントは IdentityRegistry で ERC-721 トークンをミントし、その tokenURI がオフチェーンの登録ファイル（名前、説明、宣言されたエンドポイント、active フラグ、サポートする信頼方式を含む JSON）を指します。2026-01-29 に Ethereum メインネットで稼働を開始し、Base メインネットと Base/Ethereum/Linea の Sepolia テストネットにリファレンス実装がデプロイされています。登録は一度きりのオンチェーン操作です。実際に登録されたエージェントでも、プロセスの停止、ドメインの期限切れ、エンドポイントの変更などにより完全に応答しなくなる一方、オンチェーンの記録は変更されずに永久に残ります。このアセットはこの隔たりを埋めます。実際のオンチェーン登録を解決し、登録で宣言されているエンドポイントに対して、呼び出し時点で実際の MCP initialize ハンドシェイクを実行します。これは、agent-verification-api（候補 #3）がドメインの所有権を主張する ID について示す、稼働状況と登録状況の違いを、オンチェーン登録されたエージェントに適用したものです。

根拠（単一の情報源を前提とせず、このセッションで実際に検証済み）

• コントラクトアドレスは当初、サードパーティーの概要から取得し、信頼する前に https://sepolia.base.org に対する eth_getCode で個別に検証しました。IdentityRegistry （0x8004A818BFB912233c491871b3d84c89A494BD9e）と ReputationRegistry （0x8004B663056A597Dffe9eCcC1965A193B7388713）のどちらも、実際にデプロイされた空ではないバイトコードを持っています。
• ABIはリファレンス実装（github.com/erc-8004/erc-8004-contracts/abis）から取得し、このアセットで使う前に、実際に登録された 3 つのエージェント（agentId 1～3）に対してライブでテストしました。
  • エージェント 1 の tokenURI は data:application/json;base64,... URI に解決されます。
  • エージェント 2 のものは ipfs://bafkreiff... に解決されます。
  • エージェント 3 のものは実際の https://api.snack.money/agent/.../registration.json URL に解決されます。 ERC-8004 の実際の URI 形式 3 種すべてが、仕様書の例に記載された形式だけでなく、ライブ環境で機能することを確認しました。
• getSummary には空でない clientAddresses 配列が必要です――ライブで確認済みです（それ以外の場合は "clientAddresses required" でリバートします）。このアセットは最初に getClients(agentId) を呼び出し、アドレスが 1 つ以上返された場合にのみ getSummary を呼び出します。フィードバックが 0 件のエージェントは、RPC エラーを起こさず feedback_count: 0 として正しく報告されます。
• **agentId=999999（実在しないトークン）**はカスタムエラーで正しくリバートすることをライブで確認済みです。クラッシュではなく 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 配列から実際のエンドポイントを選んで、このエンジンに渡します。

チェーンの範囲

2026-09-04 時点で統一済みです。 x402 の決済は Base メインネット 上で、実際の USDC を使って確定します。オンチェーンの IdentityRegistry の読み取り、つまり実際のアイデンティティ／稼働状況の確認も、検証済みの IdentityRegistryUpgradeable のデプロイ先（0x8004A169FB4a3325136EB29fA0ceB6D2e539a432）を対象に、Base メインネット 上で行うようになりました。詳しくは下記の「メインネットのレジストリを修正」を参照してください。ReputationRegistry の読み取りには引き続き、以前の（Sepolia で検証済みの）アドレスを使用しています。実際のメインネット上の対応先は今回のセッションでは検証していません。詳しくは「保留中」を参照してください。このアセットでは、呼び出し元がチェーンを選択する機能は引き続き提供していません。いずれの決済経路でも購入者にその機能が必要だという根拠はありません。

メインネットのレジストリを修正（2026-09-04）

下記の2026-09-03の部分的な差し戻しでは、誤ったコントラクトを調査していました。0x8004A818BFB912233c491871b3d84c89A494BD9e は、erc-8004/erc-8004-contracts のバニティアドレスを使ったデプロイパターンにおける、Base SEPOLIA の決定論的な IdentityRegistry アドレスそのものです。ネットワークごとに異なる決定論的アドレスが使われるため、実際の Base メインネットのデプロイ先ではありません。実際の Base メインネットの IdentityRegistry は 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 です。実装の 0x7274e874ca62410a93bd8bf61c69d8045e399c02 は Etherscan 上で IdentityRegistryUpgradeable として検証済みです（参照リポジトリと名前が完全に一致し、コンパイラーは v0.8.24+commit.e11b9ed9）。ownerOf の読み取りも成功し、Basescan のエクスポートには、このアドレスに対する Base メインネット上の実際のトランザクションが25件記録されています（2026-09-04 09:02～10:06 UTC、25件すべて成功：register が5件、setMetadata が20件）。一方、旧アドレスに対する過去のトランザクションは19件（2026-01-31～2026-04-20）で、そのうち17件はリバートしていました。検証の全記録は scripts/verify_mainnet_registry_candidate.py、ブランチは claude/erc8004-registry-address-verify-u2db8u にあります。ReputationRegistry の実際のメインネットアドレスは今回のセッションでは検証していないため、変更していません。詳しくは「保留中」を参照してください。

メインネットへの切り替え（2026-09-03）と同日中の一部差し戻し

当初は Base Sepolia テストネット上で構築・計測していました（x402 決済とレジストリ読み取りの両方）。同じ作業セッション中に Base メインネットへ切り替えました。x402 の決済先は CDP ファシリテーターに変更し（create_facilitator_config()。ws／live-entity-verification にも同じ変更を適用済み）、決済用ウォレットを NEXUS_X402_PAYTO_ADDRESS に変更し（環境変数が未設定なら即時失敗し、デフォルトのプレースホルダーはなし）、レジストリの RPC も Base メインネットに変更しました。コントラクトアドレスは同じものを使っています。このアドレスがチェーン間で共通であることは、切り替え前に運用担当者が Basescan で直接確認しましたが、コード変更を行ったセッションでは独自に再確認していません（その環境から mainnet.base.org への外部ネットワークアクセスがなかったためです）。

数時間後、レジストリ読み取り側のみを差し戻しました。 独立した 2 つの情報源（ライブの eth_call と、Basescan 独自の「Read as Proxy」タブ）により、Base メインネット上の IdentityRegistry プロキシ（0x8004A818BFB912233c491871b3d84c89A494BD9e）に対する ownerOf／balanceOf がどちらも「execution reverted, no data」で失敗することを確認しました。一方、同じプロキシに対する register() は正常に動作することが実証されています（実際に確定したミント取引が 19 件）。メインネット上のプロキシ背後にある実装コントラクト（0xd53dE688e0b0ad436FBdbDa00036832FF6499234。Basescan のプロキシ実装スロットで確認済み）には、Etherscan／Basescan のどこにも検証済みのソースコードや ABI がありません。そのため、Sepolia デプロイのバイトコードを当初確認したとき（上記の「Grounding」を参照）のように、デプロイ済みのメインネットのバイトコードが github.com/erc-8004/erc-8004-contracts（コミット b9e466c）と一致することを確認する方法がありません。未検証のメインネットのバイトコードに対して ownerOf／tokenURI／getClients／getSummary を名前で呼び出し続けると、このアセットが検出するために存在するまさにその問題を、今度は購入者自身に向けて引き起こすリスクがありました。つまり、実在するエージェントに対して、もっともらしい誤回答（AGENT_NOT_FOUND）を返し、正しい回答であるかのように料金を請求するリスクです。

BASE_RPC_URL（デフォルトは https://mainnet.base.org）と _IDENTITY_REGISTRY_ADDRESS （0x8004A169FB4a3325136EB29fA0ceB6D2e539a432）は現在、どちらも実際の検証済み Base メインネット IdentityRegistry を参照しています。上記の「Mainnet registry corrected」を参照してください。このコードベースの他の場所には再利用できる CDP RPC ノードのパターンがありません（onchain-activity-index、x402-receipt-verifier、new-x402-listings-feed を確認済み。いずれも RPC 経由でオンチェーンデータを読み取らず、CDP を経由していたのは x402 決済のみでした）。そのため、2026-09-03 の当初の切り替え時に一度使用した公開エンドポイントと環境変数名を再利用しています。購入者向けのすべての表示箇所（エージェントカード、OpenAPI の説明、この README）は、決済とレジストリ読み取りの両方が Base メインネットで行われることを示すように更新済みです。

保留中

2026-09-04 に解決済み：このセクションで以前、メインネットへの切り替えを妨げていると記載していたのは、0xd53dE688e0b0ad436FBdbDa00036832FF6499234 の逆コンパイルでしたが、その必要はありませんでした。このアドレスは実際のメインネットの IdentityRegistry 実装ではありませんでした。実際の実装（0x7274e874ca62410a93bd8bf61c69d8045e399c02）は、Etherscan 上で IdentityRegistryUpgradeable として個別に検証されており、切り替えは完了しています（上記の「メインネットレジストリを修正」を参照）。

推測で埋めず、明示的に未解決のまま残している項目：

• ReputationRegistry の Base メインネットにおける実際のアドレスは、今回検証できませんでした。レピュテーションの読み取りでは、現在メインネットの RPC に対して Sepolia で決定論的に算出されたアドレスを使っているため、誤っている可能性があります。信頼して使う前に、IdentityRegistry に対して行ったのと同じバイトコード／実装検証が必要です。
• _BASE_RPC は無料のパブリック https://mainnet.base.org を使用しており、SLA はありません。CDP 独自の SDK（すでにこのプロジェクトの依存関係に含まれています）には、x402 ファシリテーター用にすでに設定済みの CDP 認証情報を再利用する「Base Node」RPC エンドポイントがあります（実際の cdp-sdk ソースを読んで cdp.base_node_rpc_url.get_base_node_rpc_url を確認済み）。ただし、これに切り替えるには非同期起動への再構成が必要です（現在の RPC クライアントはモジュールのインポート時に同期的に構築されます）。また、利用プランの対象かどうかも確認できていません。具体的な信頼性またはコスト上の理由が生じるまで保留します。main.py の _BASE_RPC の上にあるコメントを参照してください。

デプロイ先：Cloud Run

候補 #4/#3/#6/#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（この順）を優先し、それ以外の場合は最初のエントリーを選びます。唯一の実際に MCP 対応可能なエンドポイントに、リストにない name を使った登録でも選択されます（名前の一致だけに頼っているわけではなく、名前がない場合の優先フォールバックで対応します）。ただし、複数のエンドポイントがあり、優先名のどれも稼働中のエンドポイントを指していない場合は、誤ったエンドポイントを基に REGISTERED_UNREACHABLE と報告される可能性があります。
• IPFS の解決には、単一のパブリックゲートウェイ（ipfs.io）を使います。 フォールバックゲートウェイはありません。CID がその特定のゲートウェイ経由でピン留めされていない、または到達できない登録は、コンテンツが IPFS 上に存在していても REGISTRATION_FETCH_FAILED と報告されます。
• 呼び出し元ごとのレート制限はありません。 7 日間の使い捨て測定期間には問題ありません。
• reputation は、自己申告による、ゲートもステーキングもないシグナルです。 任意の EVM アドレスが、任意の agentId に対して ReputationRegistry.giveFeedback を呼び出せます。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: URI の Base64 デコードについては、処理が線形で増幅も起きないことを確認したため、修正は不要でした。
• 機能性・購入者体験（必須修正 1 件、中程度 1 件、適用済み）： トップレベルの JSON がオブジェクトではない登録ファイル（配列、文字列、数値など。登録者が制御するコンテンツ）が、"ok": True と非 dict の registration を伴ってそのまま返されていました。下流のすべての処理（_pick_liveness_endpoint、_classify_verdict、レスポンス本文）はこれを dict と想定していたため、捕捉されない AttributeError が、x402 の支払い確定後に未処理の 500 エラーを引き起こす可能性がありました。修正として、_resolve_registration_file 内の両方の JSON 解析箇所で、非 dict の結果を registration_not_an_object として拒否してから "ok": True を返すようにしました。また、レピュテーションの操作可能性に関する注意事項を追加しました（上記「既知の制限事項」と reputation フィールド自体のスキーマ説明を参照）。重大度が低く、対応が望ましい項目 2 件（重複する name によるエンドポイントのシャドーイング、任意の登録キー 2 件におけるフィールドの大文字・小文字の未検証）は、そのままにしました。実際の登録でどちらかが問題になるという証拠はまだなく、これは CLAUDE.md SS3 に沿った判断です。
• 修正前と修正後の両方で、実際の本番データを使ったエンドツーエンド検証を実施しました。Base Sepolia 上の実在する ERC-8004 エージェント ID 4 件（1、2、3、および実在しない 999999）それぞれで、正しい判定が得られました。REGISTERED_UNREACHABLE（実在する登録情報があり、エンドポイントは MCP に応答しない）、REGISTRATION_FETCH_FAILED が 2 件（実際の IPFS ゲートウェイのタイムアウト、および実際に停止している https:// 登録 URL。どちらも正当な結果で、バグではありません）、そして AGENT_NOT_FOUND（実際のオンチェーンリバート）です。さらに、実際のレピュテーションデータも確認しました（エージェント 1 に対する、12 の異なるクライアントからのフィードバック 74 件）。

測定（候補 #10、7 日間の測定期間）

2026-08-23（実際のデプロイ日）から 7 日間を測定し、2026-08-30 を判断日とします。信頼できる情報源は Cloud Run のログではなく、traffic_events/revenue_events/mcp_call_events（asset_name = 'erc8004-agent-liveness'）です。7 日目に、クローラーを除外した実トラフィックがゼロの場合は、Cloud Run サービスを一時停止または削除します（gcloud run services delete erc8004-agent-liveness --region us-central1 --project nexus-505016）。