ERPC、x402 決済対応の Solana RPC を公開 — AI エージェントが必要な API にその場で支払う時代の幕開け

ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）および Validators DAO が運営する ERPC は、本日、x402 決済に対応した Solana mainnet JSON-RPC proxy を公開したことをお知らせいたします。

今回公開したのは、x402.erpc.global で提供される実運用可能な x402 対応 Solana RPC です。利用者、アプリケーション、AI エージェントは、POST https://x402.erpc.global/v1/solana-mainnet に Solana JSON-RPC リクエストを送信し、支払いが必要な場合には HTTP 402 Payment Required と x402 の支払い要求を受け取ります。その後、Solana mainnet 上の USDC ステーブルコイン決済 payload を付与して同じリクエストを再送することで、支払いの検証・決済後に Solana RPC の結果を受け取ることができます。

これまで API の支払いは、人間が先に契約し、API key を発行し、AI や bot はその key を借りて使う形が中心でした。x402 により、AI エージェントやプログラムは、リクエスト時に提示される支払い条件を読み取り、所有者が定めた予算と権限の範囲で支払い、必要な API をその場で利用する設計に近づきます。ERPC は、この流れを Solana RPC という具体的なインフラ用途で実装しました。

x402 とは何か

x402 は、HTTP の 402 Payment Required を現代的に活用し、Web や API のリクエストそのものに支払いを組み込むためのオープンな決済プロトコルです。

従来の API 利用では、サービスごとにアカウントを作成し、支払い方法を登録し、API key を発行し、月額契約やプリペイド残高を管理する必要がありました。この流れは、人間がブラウザで契約して利用する世界には合っていましたが、ソフトウェアや AI エージェントが必要なサービスをその場で選び、必要な分だけ使う世界には重すぎます。

x402 では、クライアントが有料リソースへアクセスすると、サーバーはまず 402 Payment Required を返します。その応答には、いくら、どのネットワークで、どの資産で支払えばよいかという支払い条件が含まれます。クライアントはその条件に従って USDC などのステーブルコインで支払い payload を作成し、同じリクエストを支払い証明付きで再送します。サーバーは支払いを検証・決済し、問題がなければ要求された API やコンテンツを返します。

つまり x402 は、Web API に「この処理にはこの金額が必要です」「支払いました」「では結果を返します」という会話を、HTTP の自然な request / response として組み込む仕組みです。

ERPC が実装したこと

ERPC の x402 対応 Solana RPC は、Cloudflare Workers 上で動作する Solana mainnet JSON-RPC proxy です。支払いの検証と決済には Coinbase CDP x402 facilitator を利用し、Solana mainnet 上の USDC ステーブルコイン決済を扱います。/.well-known/x402 では、x402 version 2、facilitator URL、Solana mainnet、USDC、/v1/solana-mainnet の POST endpoint が公開されています。

最初のリクエストでは、クライアントは通常の Solana JSON-RPC body を送信します。この時点で X-Payment がない場合、ERPC は 402 Payment Required を返し、支払いに必要な x402 challenge、RPC メソッドの weight、USD 建ての価格情報を返します。

クライアントは、その条件に基づいて Solana mainnet 上の USDC ステーブルコイン決済 payload を作成し、同じ JSON-RPC body に X-Payment header を付けて再送します。ERPC は facilitator に支払いの検証と決済を依頼し、決済 receipt を受け取ったうえで、上流の Solana RPC へリクエストを proxy します。最終的に、クライアントには JSON-RPC の結果と X-Payment-Response receipt が返ります。互換性のため、legacy header として Payment-Signature も受け付けます。

二重支払いを防ぐため、同じ署名が再利用された場合は 409 duplicate_payment として扱います。支払いが不正、または金額が不足している場合は、402 payment_invalid や payment_amount_too_low として返します。

価格は ERPC の canonical token model に基づき、メソッドごとの raw weight に 0.000001 USD を掛ける形で計算されます。標準的な JSON-RPC メソッドは 42 tokens、getProgramAccounts は 4200 tokens、getTokenLargestAccounts は 2400 tokens、getMultipleAccounts は pubkey 数に応じて 420 tokens ずつ加算されます。決済には facilitator 側の最小決済額に合わせ、リクエスト全体に対して 0.001 USD の minimum charge が適用されます。たとえば getSlot の raw weight は 42 tokens ですが、実際の請求 weight は minimum charge により 1000 tokens、つまり 0.001 USD になります。

無料で確認できる endpoint として、GET /health、GET /pricing、GET /.well-known/x402 も提供しています。/pricing では各 Solana RPC メソッドの raw weight、minimum charge 適用後の weight、USD 建て価格を確認できます。

マイクロペイメントとしての意味

x402 対応の重要な意味の一つは、API や RPC をマイクロペイメントに近い単位で扱えることです。

これまで RPC のようなインフラは、月額プラン、固定 quota、プリペイド credit、後払い請求で提供されることが一般的でした。この方式では、利用者はあらかじめ多めの枠を確保しがちです。使い切れなかった credit は無駄になり、逆に急に利用量が