2026年3月29日 — 読了時間10分
🤖 新着：Quicknode AIクックブック AIプログラミングの10の実証済みレシピ エージェント.
レシピを見るSOC 2 タイプ II 認証取得・ISO 27001
x402 そしてMPP：その仕組みと、他のものとの違い
x402 とTempoの、HTTP 402ベースのAPI決済向けMPPを比較します。比較項目には、プロトコル設計、決済方法、課金方式（チャージ方式とセッション課金）、決済処理と領収書、およびQuicknodeのx402 SDKや、M2MおよびRPCワークフロー向けのMPP エンドポイント 。
2026年3月29日 — 読了時間10分
x402 APIキーではなくウォレットを使ってサービスやAPIの料金を支払いたいという場合、常にその名前が挙がってくる存在です。
最近、Tempo がMPP（Machine Payments Protocol）を公開しましたが、これとは設計思想の異なる第2の選択肢が登場しました。この2つは頻繁に比較されています。どちらもHTTPを基盤としています 402 支払が必要です、しかし、それらは異なるレイヤーで異なる問題を解決しています。
それぞれの仕組み、Quicknode のツールがどのような場面で役立つか、そして選択の際に実際に考慮すべきトレードオフについて解説します。
x402 Quicknode では、ウォレットさえあれば の RPC エンドポイントにアクセスできます。アカウントも API キーもサブスクリプションも不要です。USDC（ 、 、 ）または USDG（ ）で支払いを行い、すぐに呼び出しを開始できます。Quicknode Base Polygon SolanaX Layer
MPP（by ）Tempo は、あらゆる API を介したマシン間決済のためのプロトコルです。独自のチャレンジ／クレデンシャル／レシートflow を採用しており、複数の決済方法（Tempo ステーブルコイン、Stripe カード、ライトニング）に対応しているほか、RPC のような高頻度の従量課金制に対応したセッションモデルも備えています。
Quicknode 以下の両方に使用できる金型を提供しています： @Quicknode/x402 そして @Quicknode/x402-solana x402 用、およびMPP互換の エンドポイント は https://mpp.quicknode.com/ 以下の製品と併用するための mpp SDK。
x402 Coinbaseが考案したオープンスタンダードであり、HTTPに 402 「将来の使用に備えて確保されていた」状態が数十年間続いた末、ついに具体的な仕様が明らかになった。
その仕組みは単純です。サーバーは次のように応答します。 402 支払が必要です、クライアントは支払い要件を確認し、ステーブルコインの利用承認に署名してリクエストを再送信すると、サーバーは支払いを決済し、リソースを返します。これらすべてが、同じHTTP通信のやり取りの中で行われます。
Quicknode x402 を使用して、ウォレットによる認証を経た RPC インフラへのアクセスを提供しています。 アカウントを作成する必要はありません。USDC が入ったウォレットを接続するだけで、認証、決済、セッション管理など、それ以外のすべてはクライアントライブラリが処理します。Quicknode
2つのオープンソースパッケージ：
@quicknode/x402 –Quicknode x402 プロキシを経由した、JSON-RPC、REST、gRPC-Web、および WebSocket に対応したマルチチェーン クライアント
@quicknode/x402-solana –Solana KitおよびKiteに連携するSolana 専用のクライアント
本クライアントは、以下の支払いモデルに対応しています：
リクエストごとの課金 – 1回の呼び出しにつき0.001ドル、認証もセッションも不要。最もシンプルな方法。
クレジット・ドローダウン – SIWX（Sign-In with X）で一度認証を行い、USDCでクレジットのバンドルを購入し、その後、各リクエストでそのクレジットを使用します。継続的な利用において、より経済的です。
注目すべき点として、決済ネットワークはRPCネットワークから切り離されています。例えば、Base のSepolia上でUSDCを使って支払いを行い、Ethereum メインネットSolana 、Aptos 、Flow 、あるいはサポートされている140以上のブロックチェーン ネットワークのいずれに対してもクエリを実行できます。ウォレットも認証も同一です：flow 。
以下を使用しているクライアント @quicknode/x402 まず、Quicknode x402 プロキシに対してリソースをリクエストし（RPC、REST、gRPC-Web、WebSocketなど）、 402 支払が必要です 応答。その後、クライアントはSIWX認証を行い、JWTセッショントークンを受け取り、支払い認証情報を送信します。プロキシはその認証情報をx402 ファシリテーターに送信して支払いの検証と決済を行い、確認後にクレジットをチャージします。クライアントはセッショントークンを使用して元のリクエストを再試行します。プロキシはそれを上流のQuicknode インフラストラクチャに転送し、応答を受け取ると、クライアントに200 OKを返し、クレジットを1つ消費します。
MPP（Machine Payments Protocol）は、より広範なアプローチを採用しています。「x402 」が個々のエンドポイントの収益化手段として始まったのに対し、MPPは、あらゆるマシンがHTTPを介して他のマシンに支払いを行う方法を標準化しようとしています。
このプロトコルは、HTTP認証フレームワークを直接利用しています：
WWW-Authenticate: 支払い 402レスポンス内の情報は、クライアントに対してどのような支払いが必要かを伝えます
承認：支払い 再送付の際には、支払いの証明を添付してください
領収書 200のレスポンスが返ってきたことは、サーバーが支払いを承認したことを示しています
これはIETFのインターネットドラフト（作成者：by 、Tempo LabsおよびStripe）であり、単なるSDK の慣例にとどまらず、正式な標準規格として策定が進められていることを意味します。
MPPでは、支払い方法と支払いの種類を区別しています：
「メソッド」とは、決済経路のことです： tempo （Tempo 上のステーブルコインブロックチェーン ）、 ストライプ (カード)、 稲妻 (Bitcoin)、またはカスタム。
「インテント」とは、課金パターンのことです： 請求 （リクエストごとに1回限り）または セッション （チャネルベースの従量課金制）。
これが重要なのは、自由に組み合わせることができるからです。1つのAPIで エンドポイント は、Tempo のステーブルコインとStripeカードの双方を受け入れることができます。サーバーは402チャレンジで利用可能なすべてのオプションを提示し、クライアントは自身がサポートしているものを選択します。
特にTempo については、 セッション 興味深いのはその仕組みです。リクエストごとにオンチェーン の取引を決済する代わりに、クライアントはエスクロー契約に資金を預け入れ、リソースを消費するたびにオフチェーンのバウチャーに署名します。サーバーは、各バウチャーを単一の ecrecover 呼び出し；RPCもDB検索も不要で、純粋にCPU処理のみです。精算は、サーバーがチャネルを閉じることを決定した際にバッチ処理として行われます。トークン単位のLLM課金のようなケースでは、チャンクごとにオンチェーン を支払うよりも、この方式の方がはるかに実用的です。
MPPにおいて 請求 flow, ある mppx クライアントはMPPサービスからリソースを要求し、 402 「」で始まる応答 WWW-Authenticate: 支払い チャレンジ。その後、クライアントは選択したバックエンド（例：by でのトランザクションの署名や請求書の支払い）を通じて支払いを完了し、同じリクエストを Authorization: Payment <credential>, そしてサービスはバックエンドに対してその認証情報を検証します。検証が成功すると、サービスはリソースを 200 OK また、以下が含まれます。 領収書.
MPPにおいて セッション flow Tempo チャネルでは、クライアントはまず チャネルを開き、 エスクロー契約に資金を預け入れた後、サービスへのアクセスを要求します。サービス側はセッションバウチャーを要求し、クライアントは署名済みの累積オフチェーンバウチャーで応答します。サービス側は、以下を使用してローカルでバウチャーを検証します。by Tempo ecrecover そして、レスポンスを返す前に増分額を確認します。このバウチャー更新サイクルは、利用中に高頻度で繰り返され、その後、サービスはバッチ処理による決済においてチャネル「オンチェーン 」を閉じ、未使用の預託金はクライアントに返金されます。
x402 | MPP | |
|---|---|---|
起源 | Coinbase、オープンソース仕様 | Tempo Labs + Stripe、IETF インターネットドラフト |
ワイヤ形式 | カスタムヘッダー（X-PAYMENT-*） | 標準のHTTP認証スキーム（WWW-Authenticate: Payment、Authorization: Payment、Payment-Receipt） |
お支払い方法 | ステーブルコイン | 複数：Tempo ステーブルコイン、Stripeカード、ライトニングBTC、カスタム |
多手法による エンドポイント | いいえ。1回のリクエストにつき1つのスキームのみです。 | はい。サーバーは1つの402レスポンスで複数の処理方法を提示することができ、クライアントはその中から1つを選択します。 |
請求のパターン | プロトコルレベルでのみ、リクエストごとに適用される | 「リクエスト単位（課金）」と「従量制（セッション）」を別個のインテントとして扱う |
セッション／チャネルサポート | プロトコルには規定されていない。実装側で独自に追加される（例：クレジットシステムなど）。 | Native. session intentでは、オフチェーンのバウチャーとバッチ処理されたオンチェーン による決済を利用する決済チャネルを採用しています。 |
決済モデル | ファシリテーターは、クライアントとサーバー間の各支払いを確認し、決済を行う | 課金：リクエストごとに精算されます。セッション：サーバーは独自のスケジュールに従ってチャネルを閉じます。 |
領収書／証明 | ファシリテーターの確認 | 「支払・受領」ヘッダーと、参照番号、金額、資産、支払者を記載した受領明細 |
ステータスコードの意味 | 402：支払いが求められています | 明確な区別：402 = 支払いが必要、401 = 認証失敗、403 = ポリシーによる拒否 |
輸送 | HTTP | HTTP、MCP（JSON-RPC エラー -32042 および _meta フィールド） |
チェーンサポート | EVM、Solana | Tempo チェーン（tempo メソッド用）に加え、ブロックチェーン 以外のレール（Stripe、Lightning） |
標準化トラック | オープンソースのリポジトリであり、正式な標準化団体は存在しない | IETF インターネットドラフト |
In リクエストごとの課金 mode、SIWXもJWTも、セッション状態も一切ありません。各リクエストは独立しています。
プロキシは、アップストリームへの呼び出しが成功した場合にのみ支払いを処理します。RPC呼び出しでエラーが発生した場合は、支払いは発生しません。
設定できます preAuth: true mode のクレジット引き出し処理において、最初の 402 エラー発生時ではなく、クライアント作成時に認証を行うようにしました。これにより、ラウンドトリップを1回削減できます。
gRPC-WebとWebSocketはどちらも動作しますが、JWTセッションに依存しているため、クレジット引き落としモデルが必要です。詳細については、以下をご確認ください。
402 これは支払いに関する問題にのみ適用されます。クライアントの認証に失敗した場合、サーバーは 401 . 支払いは完了したものの、ポリシーによってアクセスがブロックされている場合は、それは 403 . この区別は仕様書に明示されています。
サーバーは複数の値を返すことができます WWW-Authenticate: 支払い 異なる決済方法に対応したヘッダー。1つの エンドポイント は、Tempo 、Stripe、Lightningを同時に受け付けることができます。クライアントが1つを選択します。
セッション「mode 」では、 領収書 ここにはトランザクションハッシュではなく、チャネルIDが含まれています。オンチェーン のトランザクションハッシュは、後でチャネルが閉じられた際に取得できます。
MPPは、AIツールの呼び出しにおいてMCP（Model Context Protocol）を介して動作します。このトランスポートでは、402はJSON-RPCのエラーコードに対応しています。 32042 、そして証明書や領収書はここに収納します _meta HTTPヘッダーの代わりにフィールドを使用します。
xml-ph-0000@deepl.internalのMPPプロキシに関する エンドポイント Quicknode のMPPプロキシ、料金、ルート、セッションとチャージのインテント、対応ネットワーク、およびクライアント設定に関する完全な詳細については、以下を参照してください。
Quicknode どちらも対応しています。どちらもアカウントは不要です。どちらを選ぶかは、 エージェント/アプリケーションが他にどのサービスと連携するかによって決まります。
ブロックチェーン によるデータアクセスが主な目的である場合は、x402 をご利用ください。その @quicknode/x402 クライアントは、JSON-RPC、gRPC-Web、WebSocketによる通信プロトコル、クレジットバンドル方式の課金、およびSolana Kitとの連携を提供しています。 @quicknode/x402-solana. これらは、Quicknode が自社のx402 プロキシ向けに特別に構築したファーストパーティのライブラリです。
もし エージェント 複数のサービスに対して支払いを行う場合、RPC用のQuicknode 、推論用のLLMプロバイダー、検索用の検索APIなどがあります。MPPを利用すれば、これらすべてに対して単一のプロトコルとウォレットを使用できます。Quicknode のMPP エンドポイント で https://mpp.quicknode.com/ 同じように動作します mppx 他のMPP対応サービスを呼び出す際に使用するクライアントです。
両方を併用できない理由はありません。インフラ層にはx402 を、その上に構築するAPIにはMPPを活用しましょう。
import { createQuicknodeX402Client } from '@quicknode/x402'
// Initialize x402 client for Base Sepolia
// Wallet needs testnet USDC — get it via POST /auth (SIWE) then POST /drip
const client = await createQuicknodeX402Client({
baseUrl: 'https://x402.quicknode.com',
network: 'eip155:84532',
evmPrivateKey: process.env.PRIVATE_KEY as `0x${string}`,
preAuth: true,
})
// Make a paid RPC call — payment is handled automatically
const res = await client.fetch('https://x402.quicknode.com/base-sepolia', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_blockNumber',
params: [],
}),
})
// Print the result
console.log(await res.json())import { createSolanaX402Clients } from "@Quicknode/x402-solana"
import { address } from "@solana/kit"
import { homedir } from "node:os"
const { rpc } = await createSolanaX402Clients(
"mainnet",
`${homedir()}/.config/solana/id.json`,
)
const balance = await rpc
.getBalance(address("dDCQNnDmNbFVi8cQhKAgXhyhXeJ625tvwsunRyRc7c8"))
.send()
console.log("Balance:", balance.value)mppx CLI# create a wallet (stored in keychain)
npx mppx account create
# charge intent — $0.001/request, one on-chain tx per request
npx mppx -X POST -H 'Content-Type: application/json' \\
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \\
<https://mpp.quicknode.com/base-sepolia>
# session intent — $0.00001/request, off-chain vouchers
npx mppx -X POST -H 'Content-Type: application/json' \\
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \\
<https://mpp.quicknode.com/session/base-sepolia>import { Mppx, tempo } from 'mppx/client'
import { privateKeyToAccount } from 'viem/accounts'
const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
// Polyfills globalThis.fetch — handles 402 challenges automatically
Mppx.create({
methods: [tempo({ account })],
})
// Charge intent ($0.001/req) — payment is transparent
const res = await fetch('https://mpp.quicknode.com/base-sepolia', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_blockNumber',
params: [],
}),
})
const { result } = await res.json()
console.log('Block number:', BigInt(result))import { Mppx, tempo } from 'mppx/client'
import { privateKeyToAccount } from 'viem/accounts'
const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
// deposit 0.10 PathUSD into a payment channel
// first request opens the channel on-chain, subsequent ones use off-chain vouchers
Mppx.create({
methods: [tempo({ account, deposit: '0.10' })],
})
const res = await fetch('https://mpp.quicknode.com/session/base-sepolia', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_blockNumber',
params: [],
}),
})
console.log(await res.json())x402 また、MPPは密接に関連しており、HTTPを介して有料のAPIアクセスを提供するという、同じ中核的な課題を解決しています。
Quicknode のRPCプロキシ機能については、どちらの方法も使用可能です。実際の違いは実装スタイルにあります。x402 はファシリテーターモデルに依存していますが、MPPはその依存関係を排除し、flow を正式なHTTP認証スキームとして定義しています。
2017年に設立されたQuicknode は、開発者 および企業向けに、機関投資家レベルのブロックチェーン インフラストラクチャを提供しています。99.99%の稼働率と、75以上のチェーンに対応したサポート を備え、チーム は妥協のないオンチェーン アプリケーションの構築とスケーリングを実現します。
最新のエンジニアリングに関する知見、製品の最新情報、Web3のニュースを、メールボックスに直接お届けします。