exact と upto の2種類のスキームを使用しています。これらは異なる課金の問題を解決します。
exact
exact は、リクエストがターゲット API に到達する前に価格を確定できることを示します。クライアントが署名した金額が最終的な引き落とし金額です。
適しているもの:
- 固定価格の画像生成;
- 固定価格のビデオタスク作成;
- 固定価格の検索またはツール API;
- 注文の支払い。
exact は USDC EIP-3009 TransferWithAuthorization を使用します:
/verify ステージで署名と金額を検証し、/settle ステージでこの承認をチェーン上に提出します。
upto
upto は、クライアントが最大上限を承認することを示し、Ace Data Cloud はリクエストが完了した後に実際の使用量に基づいて決済を行い、実際の引き落としは上限を超えることはありません。
適しているもの:
- チャット補完:最終価格はプロンプトトークンと補完トークンに依存;
- ストリーミング応答:実際の出力の長さが終了した後にのみわかる;
- 将来の後置計量 API。
upto は Permit2 PermitWitnessTransferFrom を使用します。クライアントが署名するのは固定の転送ではなく、ウィットネスを伴う上限の承認です:
permitted.amount は上限であり、最終的な引き落としとは限りません。ゲートウェイは /record ステージで実際の使用量を amount に変換してファシリテーターに渡します。ファシリテーターは amount <= permitted.amount の決済のみを許可します。
Base upto のプログラム実行結果:
- 402 で返された承認上限は
95215atomic USDC であり、クライアントはこの上限で署名します。 - モデルの実際の応答後、結算は
3atomic USDC のみであり、チェーン上の取引は BaseScan で確認できます。 - この結果は
uptoの重要な違いを示しています:署名金額は上限であり、チェーン上の決済は上限未満であることができます。 - 実際の使用量が上限を超えた場合、ファシリテーターは決済を拒否し、クライアントはより高い上限で再度承認する必要があります。
upto は現在 Base でのみ提供されています。SKALE は exact のみを提供しており、後置計量が必要な場合は Base を使用してください。
なぜ Permit2 承認が必要か
upto は最終的に x402 プロキシを介して Permit2 から支払いウォレットから USDC を引き出します。初めて使用する前に、支払いウォレットは Permit2 に対して一度 ERC-20 アローワンスを与える必要があります。
Python CLI:
upto エンベロープに署名する必要があります。なぜなら、nonce、deadline、witness、金額上限が異なるからです。
ゼロ金額決済
upto は実際の金額が 0 である場合をサポートします。例えば、ターゲット API が成功裏に課金可能な量を生成しなかった場合、ゲートウェイは amount = "0" を渡すことができます。ファシリテーターは成功を返しますが、チェーン上の取引は発生しません。
これにより、「リクエストが成功しなかったが、依然としてチェーン上の費用が引き落とされる」という問題を回避できます。
選択の提案
どれを選ぶべきか不明な場合は、まず SDK のデフォルト動作を使用してください;SDK はサーバーが返す一致するネットワークの支払い要件を選択します。
Base upto チェックリスト
接続またはトラブルシューティング時には、以下のパラメータが同じ 402 応答から来ていることを確認し、クライアント署名時に一貫性を保ってください:
一般的なエラーと対処法:

