x402-api

x402

x402 は、インターネットネイティブな決済のためのオープンスタンダードです。すべてのネットワーク（暗号資産と法定通貨の両方）と価値の形態（ステーブルコイン、トークン、法定通貨）に対応することを目指しています。

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [...],                 // As many networks / schemes as you want to support
        description: "Weather data",    // what your endpoint does
      },
    },
  ),
);
// That's it! See examples/ for full details

# All available reference sdks
npm install @x402/core @x402/evm @x402/svm @x402/axios @x402/fetch @x402/express @x402/hono @x402/next @x402/paywall @x402/extensions

# Minimal Fetch client
npm install @x402/core @x402/evm @x402/svm @x402/fetch

# Minimal express Server
npm install @x402/core @x402/evm @x402/svm @x402/express

pip install x402

go get github.com/x402-foundation/x402/go

原則

• オープンスタンダード： x402 はオープンスタンダードであり、誰でも自由にアクセスして利用できます。特定の単一の組織への依存を強制することはありません。
• HTTP／トランスポートネイティブ： x402 は、既存のデータ転送をシームレスに補完することを目的としています。可能な限り、一般的なクライアント／サーバーのフローの範囲外で追加のリクエストを要求しないようにします。
• ネットワーク、トークン、通貨に依存しない： CONTRIBUTING.md に定められた受け入れ基準を満たす限り、新しいネットワーク（暗号資産と法定通貨の両方）、署名規格、またはスキームへの対応を追加する貢献を歓迎します。x402 は法定通貨ベースのネットワークへの対応を拡張する場合がありますが、法定通貨による決済を優先してオンチェーン決済を後回しにすることはありません。
• 後方互換性： x402 は、標準のセキュリティ上必要と判断される場合を除き、既存のネットワークへの対応を廃止しません。可能な限り、メジャーではないバージョン変更では後方互換性を維持します。
• 信頼を最小化： すべての決済スキームにおいて、クライアントの意図に沿う場合を除き、ファシリテーターまたはリソースサーバーが資金を移動できないようにする必要があります。
• 使いやすさ： x402 コミュニティは、インターネット上の他の決済手段と比べて使いやすさを向上させることを目指しています。これは、暗号資産に関する詳細をできる限り抽象化してクライアントやリソースサーバーから隠し、ファシリテーター側で処理することを意味します。クライアント／サーバーは、ガスや RPC などを意識する必要がありません。

エコシステム

x402 エコシステムは成長を続けています！エコシステムページで、x402 を活用しているプロジェクトをご覧ください。以下のようなプロジェクトが掲載されています。

• クライアント側の統合
• サービスとエンドポイント
• エコシステムのインフラストラクチャとツール
• 学習やコミュニティのリソース

ご自身のプロジェクトをエコシステムに追加しますか？プロジェクトの申請方法について詳しくは、デモサイトの READMEをご覧ください。

ロードマップ： ROADMAP.mdをご覧ください。

ドキュメント： GitBook ドキュメントのソースについては、docs/をご覧ください。

用語：

• resource：インターネット上のものを指します。ウェブページ、ファイルサーバー、RPC サービス、API など、HTTP／HTTPS リクエストを受け付けるインターネット上のあらゆるリソースが該当します。
• client：リソースへの支払いを希望するエンティティです。
• facilitator：1 つまたは複数のネットワークで、決済の検証と実行を支援するサーバーです。
• resource server：クライアントに API またはその他のリソースを提供する HTTP サーバーです。

技術目標：

• クライアント、サーバー、ファシリテーターにとって、パーミッションレスかつ安全であること
• クライアントとリソースサーバーのどちらも、最小限の手間で導入できること
• リソースサーバーとクライアントの統合を最小限にすること（サーバーは 1 行、クライアントは 1 つの関数）
• 応答速度と決済保証のバランスを調整できること
• さまざまな決済フローとネットワークに拡張できること

仕様

x402 標準のドキュメント全文については、specs/をご覧ください。

一般的な x402 のフロー

x402 による支払いは通常、次のフローに従いますが、サーバーには大きな柔軟性があります。examples/ 内の advanced フォルダーを参照してください。

以下では、x402 プロトコルを使用した支払いのフローを説明します。クライアントがリソースに対して受け入れられる支払いの詳細をすでに把握している場合、ステップ（1）と（2）は省略可能です。

1. Client が resource server に HTTP リクエストを送信します。

2. Resource server は 402 Payment Required ステータスを返し、PaymentRequired の b64 オブジェクトを PAYMENT-REQUIRED ヘッダーとして返します。

3. Client はサーバーのレスポンスで返された PaymentRequirements のいずれかを選択し、選択した PaymentRequirements の scheme と network に基づいて PaymentPayload を作成します。

4. Client は、PaymentPayload を含む PAYMENT-SIGNATURE ヘッダーを付けて、HTTP リクエストをリソースサーバーに送信します。

5. Resource server は、ローカルで検証するか、PaymentPayload と PaymentRequirements を facilitator の /verify エンドポイントに POST して、PaymentPayload が有効であることを検証します。

6. Facilitator は、PaymentPayload の scheme と network に基づいてオブジェクトを検証し、Verification Response を返します。

7. Verification Response が有効な場合、リソースサーバーはリクエストを満たすための処理を実行します。Verification Response が無効な場合、リソースサーバーは 402 Payment Required ステータスを返し、レスポンス本文に Payment Required Response JSON オブジェクトを返します。

8. Resource server は、ブロックチェーンと直接やり取りするか、Payment Payload と Payment PaymentRequirements を facilitator server の /settle エンドポイントに POST して、支払いを決済します。

9. Facilitator server は、Payment Payload の scheme と network に基づいて、ブロックチェーンに支払いを送信します。

10. Facilitator server は、ブロックチェーン上で支払いが確定するまで待機します。

11. Facilitator server は、Payment Execution Response をリソースサーバーに返します。

12. 支払いが正常に実行された場合、Resource server は、リクエストされたリソースを HTTP レスポンス本文として含む 200 OK レスポンスを Client に返し、Settlement Response を Base64 エンコードされた JSON として含む PAYMENT-RESPONSE ヘッダーを付けます。

スキーム

スキームとは、資金を移動する論理的な方法です。

ブロックチェーンでは、資金を移動するための柔軟な方法が数多く利用できます。増え続ける支払いのユースケースに対応するため、x402 プロトコルでは scheme フィールドを通じて、さまざまな方法での支払い決済を拡張できます。

各支払いスキームでは、支払いを完了するために必要なアクションに応じて、運用上の機能が異なる場合があります。 たとえば、プロトコルに含まれる最初のスキームである exact は、upto とは異なる動作をします。exact は特定の金額を送金します（例：記事を読むために 1 ドルを支払う）。一方、仮想的な upto では、リクエスト中に消費されたリソースに応じて、上限額まで送金します（例：LLM によるトークン生成）。

スキームの詳細については specs/schemes を参照してください。また、EVM チェーンでの厳密な支払いに関する最初の提案スキームについては specs/schemes/exact/scheme_exact_evm.md を参照してください。

スキームとネットワークの違い

スキームは資金を移動する論理的な方法であるため、スキームの実装方法はブロックチェーンによって異なる場合があります（例：Ethereum で exact を実装する方法と、Solana で exact を実装する方法は大きく異なります）。

クライアントとファシリテーターは、適切なペイロードを作成し、支払いを検証・決済できるように、異なる (scheme, network) の組み合わせを明示的にサポートする必要があります。