x402 レシート検証（Receipt Verifier）

NEXUS自身のx402決済ログを、NEXUS自身の配信ログに対して監査し、特定の支払いが実際の成功したサービスコールと対応していることを証明する署名付きレシートを発行します。NEXUS候補 #13 -- 手動ビルド（FORGE生成ではない）。

• POST /verify-payment-receipt {"asset_name": "...", "payer_address": "0x...", "claimed_amount_usd": 0.01, "claimed_at": "2026-08-22T21:31:34Z"} -- x402経由で$0.02が課金されます（Base Sepoliaテストネット）。

• POST /payer-spend-health {"asset_name": "...", "payer_address": "0x..."} -- x402経由で$0.02が課金されます。

• POST /verify-receipt-signature {"receipt": {...}, "signature": "..."} -- 無料。以前に発行されたレシートが真正かつ改変されていないことを確認します。

• MCPツール verify_payment_receipt / payer_spend_health（/mcp内）-- 現在は無料。ただし「既知の制限事項」を参照。

• GET /health, GET /.well-known/agent-card.json, GET /openapi.json（x-payment-infoを含む）。

実際の機能（そしてそれが単なるログダンプではない理由）

revenue_events（x402決済の確定済み記録）とtraffic_events（処理済みHTTPリクエスト）は、それぞれ独立した無相関のテーブルであり、どちらのINSERTも特定の支払いを、それが支払った特定のリクエストに結び付ける共通IDを保存しません。このアセットは、NEXUS自身が他ではどこにも行っていない相関付けを行います：主張された(asset_name, payer_address, claimed_amount_usd, claimed_at)を指定すると、window_seconds以内に一致する実際のrevenue_events行（存在する場合）を検索し、その実在する決済タイムスタンプの直後に、同じアセットへの成功（2xx）traffic_events行が存在するかを確認します。判定結果（VERIFIED_DELIVERY / PAYMENT_NO_DELIVERY / PAYMENT_NOT_FOUND）と署名付きレシートが成果物です -- どちらのテーブルへの生アクセスではありません。両テーブルは、計算済みの判定オブジェクトのみを返し、行ダンプは返さない2つのPostgres SECURITY DEFINER RPC関数（nexus_verify_payment_receipt、nexus_payer_spend_health）を通じて読み取られます -- これは、このコードベースの両テーブルに対する既存のINSERT専用RLSポリシー（CLAUDE.md SS5参照）と整合的です。マイグレーション：add_x402_payment_receipt_verification_rpcs（Supabaseプロジェクトieduhdgfjdeffvzxvihf）。

意図的に設定されたスコープ： NEXUS自身の既にデプロイ済みのx402アセット（私たち自身のrevenue_events/traffic_eventsに実際にあるものだけ）のみを対象としています。第三者の支払い請求を第三者のログに対して監査するというのが元々のより広い構想（機会リスト項目#3、「recibo/prueba de ejecucion verificable para pagos entre agentes」）であり、そこでは二つの他者間の仲裁者として機能することによる法務・紛争賠償責任リスクが明示的に指摘されていました。スコープを自分たち自身の既公開アセットカタログに限定することで、その問題を完全に回避しています -- 一切の仲裁対象となる第三者が存在せず、自らの既に確定済みのデータのみを扱います。

Related MCP server: address-intel-api

既知のasset_nameスペル（これを構築中に見つけた、実データ）

revenue_events.asset_nameは、既存カタログ全体で一貫してケバブケースではありません -- たとえば、類似検索アセットの実際の保存値は"Similarity Search API"（表示ケース）であり、similarity-search-apiではありません。呼び出し元は保存されているとおりの完全な文字列を渡す必要があります。そうしないと、RPCは正しく（バグではなく）PAYMENT_NOT_LOOKUPを返します。本稿執筆時点で実際にrevenue_eventsで見られた値：document-conversion-api, live-entity-verification, agent-verification-api, url-metadata-api, Similarity Search API, ws。

署名付きレシート

signatureは、receiptの正規JSONエンコーディングに対するHMAC-SHA256（16進数）であり、NEXUS_RECEIPT_SIGNING_KEYでキー化されます。これはオフラインで検証可能な署名ではありません（その場合は非対称暗号と公開された公開鍵が必要であり、意図的に除外されています。「既知の制限事項」を参照）。保有者がレシートの真正性を証明するには、このアセット自身の無料のPOST /verify-receipt-signatureを呼び出し、サーバー側でHMACを再計算して確認します。NEXUS_RECEIPT_SIGNING_KEYをローテーションすると、古いキーで発行されたすべてのレシートが無効化されます。

デプロイ先：Cloud Run

候補#4/#3/#6と同じパイプライン -- skills/infra-deploy-opsを参照。

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

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

既知の制限事項（意図的に未修正のまま -- CLAUDE.md SS3、必要性を示す根拠がない限り門前払いなし）

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

• レシート署名はオンラインチェックが必要です。オフラインの非対称検証ではありません -- 上記参照。

• 相関付けは時間ウィンドウによるヒューリスティックであり、ハードなリンクではありません。 revenue_eventsもtraffic_eventsも、INSERT時に共通の相関IDを保存しないため、VERIFIED_DELIVERYは「この支払いの後に、このアセットへの成功したリクエストがウィンドウ内に到着した」ことを意味し、「この正確なリクエストがこの正確なトランザクションによって支払われた」ことを意味するわけではありません。トラフィックが少ないアセットでは実質的に完全ですが、同時に多くの呼び出し元がいる多トラフィックの仮想的なアセットでは曖昧になります -- その場合、candidate_successful_calls（レシートに直接公開されます。main.py内のPaymentReceiptを参照）は1より大きい値を表示します。2026-08-23時点で、対象の6つのアセットのどこにも、これが問題になるほどの同時トラフィック密度はありませんでした。

• Supabase RPCの実行前に決済が確定します -- 支払い後のインフラ障害は、実際の「支払いが無駄になる」ギャップであり、この行まで開示されていませんでした（2026-08-23の品質ゲート、機能性/購入者体験レンズで検出）。 nexus_verify_payment_receipt/nexus_payer_spend_health自体が失敗した場合（Supabaseダウン、RPCタイムアウト、不正な上流レスポンス -- _nexus_supabase_rpcの502/503/504パスを参照）、購入者はPaymentMiddlewareASGIによってすでに支払いを完了しており、回答ではなくエラーを受け取り、返金手段もありません。これがBase Sepolia テストネットであることだけを理由に現時点では受理されています -- 実資金のリスクはありません。この同じ支払い後RPC執行順序をメインネットアセットに再利用する前に、支払い前のSupabase到達可能性チェックを追加するか、ハンドラーが成功した後のみに決済を確定する方式に変更してください。

• アノンキーRPCバイパス。 2つのPostgres RPC関数はanonに付与されています（PostgRESTがそれらを公開するために必須） -- 漏洩したSUPABASE_ANON_KEYがあれば、/rest/v1/rpc/nexus_verify_payment_receiptで直接呼び出し、このアセットのx402課金をバイパスできます。受理要素：RPCはNEXUS自身の既に公開されているアセットカタログに関する相関判定のみを返し、バイパス自体によって機密情報が漏れることはなく、単にペイウォールが回避されるだけです。このコードベースでの他のすべてのSupabaseアノンキー使用と同じリスクカテゴリです。

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

品質ゲート（2026-08-22デプロイ、ゲートは支出上限による中断を経て2026-08-23に完了）

候補#3/#4/#6と同じ2エージェントプロセス（セキュリティレンズ；機能性+品質+購入者体験レンズ）で、今回はデプロイ後に実行されました -- レビュー進行中にアカウントの月次支出上限によってセッションが中断され、翌セッションで再開して完了しました。実証された調査結果を適用済み：

• セキュリティ（1件、低）： POST /verify-receipt-signatureにはx402ゲートもサイズ/深さ制限もなかったため、任意の呼び出し者が提供したreceipt辞書を無料でハッシュ化できました -- これは軽微な費用の開示/可用性の迷惑であり、深刻な脆弱性ではありません。修正済み：ハッシュ化前に、4097バイト以上またはレベル深さ10を超えるボディを400/413で拒否します（main.pyの_validate_receipt_shape, _MAX_RECEIPT_BYTES/_MAX_RECEIPT_DEPTH）。

• 機能面/購入者体験（1件、中程度）： RPCが実行される前に決済が確定するため、支払い後のSupabaseインフラ障害が発生すると、購入者は回答も返金手段もなく課金されたままになります -- 開示されていません。修正済み：上記「既知の制限事項」に文書化（コード変更なし；テストネットでは承認され、このパターンをメインネットで再利用する前に必ず再検討する必要があります）。

• その他のすべての確認項目（候補#3のSSRFクラス、候補#6のzip爆弾/スレッド漏洩クラス、アノンキーRPCの過剰返却、HMACの権限、候補#4の自己支払いpayToクラス、IPアドレスのトランケーション、インジェクション表面）はクリーンであることが確認されました -- 単なる主張ではなく、関連コードベースを再読して確認済みです。

• 非常に低優先度の二つのコスメティック項目は意図的にそのままにしました：未使用のctx: Context = None MCPツールパラメータ（agent-verification-api/main.pyにすでに存在する同じ未使用パラメータ規則に一致し、ここで修正する価値のある逸脱ではない）と、MCPパスでのみwindow_seconds/lookback_daysを黙示的にクランプ（RESTはPydanticによって範囲外をすでに拒否；MCPパスは置き換えられた値をレシートにテスト出力するため、発見可能ではあるが、明示的なエラーではない -- このためにゲートが必要となる根拠はまだない）。

計測（候補 #13、7日ウィンドウ）

最初の本番デプロイ（2026-08-23 → 決定ポイント2026-08-30）からの7日ウィンドウ。情報源はtraffic_events/revenue_events/mcp_call_events（asset_name = 'x402-receipt-verifier'）であり、Cloud Runログではありません。7日目：実トラフィックがゼロの場合（クローラー除外後）、Cloud Runサービスを一時停止/削除します。gcloud run services delete x402-receipt-verifier --region us-central1 --project nexus-505016）。