00 — 課題
支払いログは、戦略ログになる
x402 の決済は、普通の ERC-20 送金です。公開され、永久に残ります。エージェントは機械の速さで払い続けるので、その記録はそのまま行動の記録になります。
見えているのは「支払い」だけ。しかし誰に・いつ・いくら・どの順でが揃うと、そこから先は推測ができてしまいます。
公開台帳に残るもの
▶ を押すと、1体のエージェントが3つの有料APIに支払う様子が台帳に記録されていきます。
観測者が読み取れること
まだ手がかりがありません。支払いが積み重なるほど、読み取れることが増えていきます。
プロバイダ側:固定の受取アドレスを1つ見張るだけで、売上の推移が積み上がって見えます。
※ アドレス・金額・パターンは概念説明のための例です
依存先と意図が漏れる
同じウォレットから払い続けると、どの API に・いつ・いくら・どの順で支払ったかが公開記録に残ります。ワークフローも外部依存も、そこから読み取れます。
売上と顧客の動きが漏れる
受取アドレスが固定なら、入金を数えるだけで売上・利用トレンド・大口顧客への依存度が推定できます。競合がそのまま使える材料です。
01 — しくみ
リンクの消し方
402 のやり取りはそのままです。変わるのは、payTo が使い捨ての burn アドレスになることと、精算が burn → 証明ゲート付き mint になることだけです。
登場人物は3者。チェーンに触るのは facilitator だけで、burn アドレスを導出できるのもここだけです。
1件の支払いを、時間順に3つの場面で追います。
3つは別々のやり方ではなく、同じ1件の支払いの前半・中盤・後半です。STEP 1 と 2 は同じ HTTP リクエストの中で数秒のうちに終わり、STEP 3 だけがその数分後、リクエストの外で起こります。
支払い先が決まる場面です。エージェントが有料 API を呼ぶと、402 が金額・トークン・期限と一緒に payTo を返します。その payTo に載るのが、facilitator がこの支払いのためだけに導出した使い捨ての burn アドレスです。プロバイダ自身の受取先は一度も出てきません。
※ 図は流れを説明するための簡略化です
burn アドレスは毎回新しい
導出側の秘密の値なしには、そこから受取先を逆算できません。burn 同士も互いに結びつきません。
証明はどの burn かを明かさない
mint の ZK 証明が公開するのは transfer root・受取先ハッシュ・金額だけ。どの burn を使ったかは秘密入力のままです。
提供と mint は同時ではない
x402 は同期的な支払い確認を求めますが、zERC20 の性質は burn と mint の時間差から生まれます。だから burn で提供し、mint は後で行います。
正直に書いておくこと
- facilitator には隠れません。すべての支払いを処理し、対応関係を常に把握しています。隠されるのは公開台帳に対してであって、この当事者に対してではありません。
- burn は取り消せません。Accepted が成立した時点で、資金は不可逆に焼かれています。
- ただし失敗しても資金は失いません。決済が失敗した場合、支払者の資金は消費されず、リソースも提供されません(fail-closed)。
- 自動返金はありません。支払ったのに拒否された例外時、支払者に残るのは証跡だけです。期限切れなどの回復は運用者の手動判断になります。
02 — 見える範囲
隠れるもの、隠れないもの
オンチェーンに書かれなくなるのは1つだけです。それ以外は公開されたままで、しかもその1つも、支払いの件数が少なければ推測できてしまいます。
「匿名になる」わけではありません。支払いの両端はどちらも見えていて、書かれないのは対応関係だけです。
候補が2つしかありません。当てずっぽうでも半分は当たります。少額・低頻度の運用では、この主張はほとんど成立しません。
金額と時刻が一致すれば、候補はここからさらに絞り込まれます。金額は公開されたままだからです。
対応するデプロイで使える実験的なバッチ経路では、1回のトランザクションで合計を mint するため、グループ分けの推測余地はむしろ広がります。
permit モードか self-transfer かの選択は、この性質を強くも弱くもしません。
※ 件数と確率は概念説明のための例です
公開されたままのもの4
金額
公開burn は普通の送金と同じ形のイベントです。いくら焼かれたかは誰でも見られます。
支払者の活動
公開burn イベントには支払者のアドレスが入ります。「このエージェントが・この額を・この時刻に焼いた」は見えたままです。
treasury アドレス
公開mint 時に calldata と送信先として現れます。402 で伝えないのは決済フロー上の非開示であって、チェーンからの隠蔽ではありません。
タイミング
公開burn も mint もタイムスタンプ付きの公開イベントです。時刻の一致は上の推測材料になります。
ミキサーや匿名決済ですか?
いいえ。支払いの両端はどちらもオンチェーンで見えています。書かれないのは「どの burn がどの mint に対応するか」だけです。監査に使える view key での期限付き開示はロードマップ段階で、まだ提供されていません。
新しいトークンを発行しますか?
しません。フォークもしません。公式の x402 v2 と公式の zERC20 ツールチェーンをつなぐ統合レイヤーで、scheme 名は subetha-zerc20 です。x402 v1 へのフォールバックはありません。
通信そのものは隠れますか?
隠れません。SubEtha は HTTP に手を加えません。プロバイダは通常の Web サーバと同じように、接続元・ヘッダ・時刻を見ています。通信経路の秘匿は対象外です。
03 — 現在地
いま動くもの、これからのもの
全フローは動きます。ただし検証済みの構成はローカル開発スタックで、未監査・非本番の段階です。
現リリースでは、支払いの受け入れが有効になるのは profile = "local" を明示したときだけです。
全フローが動く
リクエスト → 402 → burn → 証明ゲート付き mint まで通しで動作します。各ステップをボタンで進められるガイド付きのブラウザデモも用意されています。
オープンソース
公式 zERC20 ツールチェーン上のオープンソース実装です。支払者・プロバイダ側は Apache-2.0 のパッケージと素の HTTP で統合し、facilitator が使う zERC20 SDK は BUSL-1.1。商用提供はライセンスと運用準備の確認を前提とするとされています。
未監査
監査は受けていません。脆弱性は GitHub Security Advisories から非公開で報告することになっています。
本番向けではない
再現可能な検証済み構成はローカルスタックです。非ローカルでの受け入れは、プロファイルごとの確認・ファイナリティ方針が実装・テストされるまで無効のままとされています。
プロファイルによる受け入れ制限
プロファイル未設定は非ローカル扱い(フェイルセーフ)です。制限が外れるのは設定ではなくコード側の対応後で、プロファイルごとの確認・ファイナリティ方針が実装・テストされてからとされています。
デザインパートナー募集
金融リサーチチーム、データプロバイダ、エージェント開発者と、支払い履歴が戦略を漏らす問題を検証している段階。いま動いているのはここです。
Provider と Agent の両面導入
差し替えやすい x402 アダプタと payer SDK を整え、どちらの側も秘匿決済を自前実装せずに使える状態を目指す段階。
決済レイヤーのベータ
1ネットワーク・1アセットに絞って提供する段階。
エージェント統制
予算の上限、許可したプロバイダ、人間による承認。
コンプライアンス
顧客が持つ view key、期限付きの開示、入出金双方の制裁スクリーニング、監査人向けエクスポート。
商用化
マネージドな決済レイヤーとしての提供。
※ 機能として提供されているものは、まだ一つもありません。DISCOVERY が「募集中」なのはデザインパートナーの募集が進行中という意味で、機能の提供ではありません。第2章で触れた view key による開示も Phase 3 の予定です。