Coinbase x402 対 Google A2A: エージェント間決済における二つの相反する支払い順序

調査エージェントを開発している開発者が、3つのエージェント（検索、要約、翻訳）に作業を委託する際に、サブセント単位のマシン間決済が必要だった。Stripeの最低手数料0.30ドルは0.001ドルの呼び出しに対して300倍のオーバーヘッド、オンチェーンL1ガスも同様、サブスクリプションは人間による事前交渉が必要。彼らはx402、CoinbaseによるHTTP 402「Payment Required」の実装を発見した。これはBase上のサブセント決済のためのステートレスなファシリテーターで、EIP-3009の事前署名認証をヘッダーとして渡すことで約2秒、約0.0001ドルで決済する。

核心の問題：支払い順序

検証（高速、オフチェーン）、決済（低速、オンチェーン）、実際の作業（LLM呼び出し）の3つがある場合、3つの順序が考えられる：

• A： 検証 → 実行 → 決済
• B： 検証 → 決済 → 実行
• C： 検証 → 予約 → 実行 → キャプチャ（クレジットカードのホールドパターン。EIP-3009のワンショット設計では不可）

CoinbaseのミドルウェアはAを使用、GoogleのA2A x402拡張はBを使用。違いは作業時間に依存する：Coinbaseの呼び出し元は高速なAPIエンドポイント（500ms未満）なので、検証-決済のギャップは無視できる。しかしエージェントが他のエージェントを呼び出す場合、そのウィンドウは数秒から数分に伸びる。この間に支払い元が検証後、決済前にウォレットを空にしてしまい、無料の計算リソースを得ることが可能になる。

エージェント型ワークロードでは決済先行が有利

開発者はB（検証 → 決済 → 実行）を選択した。エージェントの作業には実際のコスト（1回0.30ドル以上）がかかり、低速だからだ。決済先行なら、支払いが失敗した場合にLLMが実行されることはない。彼らは4つのシナリオをストレステストした：

• 有効な署名、決済完了前にウォレットが空になる → 決済はリバート、計算リソースの無駄なし（損失0ドル）。
• 同一ウォレットから異なるnonceで2つの並行リクエスト、同じ残高 → 一方の決済は成功、他方はチェーン競争に敗れ、モデルに到達せず。
• 支払いヘッダーのリプレイ → 検証前のnonceチェックで捕捉、402を返す。
• ファシリテーターが10秒でタイムアウト、チェーン確認が25秒で完了 → 孤立した支払い（支払い元は引き落とし、タスクは失敗）。これはチェーンの負荷による特性で、順序では解決不可。

決済先行の失敗モード：支払いは成立したが、作業が失敗（500エラー、バグ）。プロバイダーは永続化されたnonce/認証メタデータと手動返金で対応する。

完全なフローはオープンソースで、4つのシナリオすべてをノートPC上で実行するe2eテストを含む。github.com/GetBindu/Bindu