SubEtha keeps the x402 HTTP payment flow — request, 402 Payment Required, pay, result — and replaces settlement with zERC20 burn / mint. The provider gets paid, while the public chain does not expose a direct link between the paying agent and the API provider.
Machine-payment protocols like x402 settle with an ordinary on-chain ERC-20 transfer — public and permanent. An AI agent pays per request, at machine frequency. That single design choice leaks two things:
Keep paying from the same wallet and the public record shows which APIs were paid, when, how much, and in what order. An observer can read the agent's workflows, external dependencies, and intent — its payment history doubles as a behavior log and a window into its cost structure.
A fixed payTo address lets anyone watch the inflows and estimate revenue, usage trends, and dependence on key customers — material competitors can use directly for pricing and sales strategy.
API calls are high-frequency, mechanical, and purpose-bound. The more machines pay on-chain, the more the public ledger becomes the transaction log of the machine economy — and the greater its leakage risk.
SubEtha keeps the request / payment-required / retry shape of x402 — but the payTo carries a one-time burn address instead of the provider's treasury, and settlement goes through zERC20's burn → proof-gated mint.
The agent calls a paid API — no keys, no account.
The provider answers with a price and a one-time burn address — never its treasury.
When permit mode is offered, the agent signs an authorization bound to that exact burn address — no transaction or gas for the payer.
In permit mode the facilitator broadcasts the burn; self-transfer clients can broadcast it themselves. Once it confirms, the API result is served.
Later, a ZK proof mints to the treasury — without revealing which burn it redeems.
The guided browser demo runs the whole flow on the real zERC20 stack. Each step is a button, labeled with who acts — so you can see exactly what the client does, what the provider does, and what lands on-chain.
The payoff: the treasury grows, while traceable inflows to it stay at zero.
Not privacy as ideology — privacy as loss prevention. These are the domains where a public payment history is a direct competitive leak.
A fund's agent buying news, filings, satellite and on-chain data reveals its investment themes through its payment order alone. Payment privacy is alpha protection.
Payments across supplier, logistics, credit and FX APIs expose supply chains and demand forecasts — handing negotiating power to competitors and suppliers.
A bot paying per call for market data, signals and execution APIs stamps its strategy onto the chain — the timing and cadence of its payments show what it watches and when it acts. Observers can reverse-engineer, copy, or front-run it.
An agent paying per call for inference, specialized models and tool APIs publishes its own architecture — which providers it depends on, at what volume, at what unit cost. That is your product's blueprint and cost structure, readable by competitors.
With a fixed payTo, anyone can chart a provider's revenue, growth and key-customer dependence. SubEtha makes revenue unreadable from the chain.
If your payment history would tell a competitor something, we'd like to hear about your case.
No. Both ends of a payment stay visible: anyone can see that the agent spent tokens, and anyone can see that the provider's treasury received tokens. The one thing that never appears on-chain is the link between the two — which payment became which deposit. The goal is confidential machine payments for enterprise AI agents, not anonymity: auditable disclosure through view keys is an explicit part of the roadmap.
Barely. The flow stays the familiar one: call the API, get told “payment required”, pay, receive the result. The only difference is the payment address you're handed — a single-use address created just for that one payment (the burn address), instead of the provider's own receiving address. Settlement then runs behind the scenes through zERC20's burn → mint.
In permit mode, when the facilitator offers the PermitBurner helper, the agent only signs an approval — think of it as signing a check (technically, an EIP-2612 permit plus an authorization pinned to that exact payment address). The facilitator submits it and pays the gas. A self-transfer fallback is also available, but then the payer submits the burn transaction and pays gas.
Only two records. One: the payer sent tokens to a single-use address (the burn). Two: tokens arrived in the provider's treasury (the mint). Nothing written on-chain connects the two, so an outside observer can't tell which payment became which deposit.
No. SubEtha issues no token of its own and modifies (forks) nothing that already exists. It is the bridge that connects the x402-style payment flow to settlement on the official zERC20 toolchain.
An experimental batch path is available for supported deployments. A provider can let payments accumulate and settle them into its treasury together, at a time of its choosing. Since every payment uses its own single-use address, batching still does not create a direct on-chain payer-to-provider link, although timing and amount correlations remain possible.
For the implementation details and the thinking behind SubEtha, see the longer technical articles.
The full loop — request, 402, permit or self-transfer, burn, accepted response, and proof-gated mint — runs today on the official zERC20 toolchain as a local, non-production reference implementation. Unaudited; commercial availability remains subject to licensing and operational readiness.
Validate the payment-history leakage problem with financial research teams, data providers, and agent builders now — before choosing which enterprise controls and provider integrations to prioritize.
Make the first integration easy on both sides. For API providers: a drop-in x402 adapter, testnet sandbox, onboarding docs, settlement and fee transparency, and hands-on integration support. For agent builders: payer SDKs, MCP/Python/CLI and framework integrations, safe defaults, examples, and reference apps. Providers should accept SubEtha without changing their API product; agents should pay without implementing private settlement themselves.
Harden the real-settlement x402-compatible payment layer and its provider and agent integrations for external testing. The initial beta focuses on one network and one asset, with security and operational hardening before broader availability.
Give enterprises control over how their AI agents spend: per-agent budgets, approved providers, human approval, persistent payment state, reporting, and integrations with agent runtimes.
Customer-controlled view keys, time-bound disclosure packages, sanctions screening on both deposit and payout, auditor exports. Publicly private, institutionally auditable.
Operate a managed private payment layer for enterprise AI agents: convert design partners into paid deployments, build a trusted provider network, publish a public draft of the x402 privacy scheme, and harden the developer integrations for external use. The product is operated confidentiality — not only a library.
SubEtha is a privacy-preserving payment layer for AI agents using APIs and data services. We're speaking with people building or operating agents, providing services to them, and exploring this space. Try the demo, read the code, or get in touch.
SubEtha は x402 の HTTP 決済フロー — リクエスト、402 Payment Required、支払い、結果 — をそのままに、決済を zERC20 の burn / mint に置き換えます。プロバイダには支払いが届きますが、公開台帳には支払ったエージェントとAPIプロバイダを直接結ぶリンクが現れません。
x402 のようなマシン決済プロトコルの決済は、通常のオンチェーン ERC-20 送金で行われます — 公開され、恒久的に残る形で。AIエージェントはリクエストごとに、機械の頻度で支払います。この一つの設計が、2つの情報を漏らします。
同じウォレットから払い続けると、どのAPIに・いつ・いくら・どの順序で支払ったかが公開記録に残ります。観測者はエージェントのワークフロー、外部依存、意図まで読み取れます。支払い履歴は行動ログであり、コスト構造を映す窓でもあります。
固定の payTo アドレスへの入金を見れば、誰でも売上・利用トレンド・大口顧客への依存度を推定できます。競合が価格設定や営業戦略にそのまま使える材料です。
API呼び出しは高頻度・機械的で、目的に直結しています。マシンがオンチェーンで支払うほど、公開台帳はマシン経済のトランザクションログとなり、その漏洩リスクも大きくなります。
SubEtha は x402 のリクエスト / 402 / リトライという形を保ちつつ、payTo にはプロバイダの受取アドレスではなくワンタイムの burn アドレスを載せ、決済は zERC20 の burn → 証明ゲート付き mint で行います。
エージェントが有料APIを呼ぶ — APIキーもアカウントも不要。
プロバイダは価格とワンタイム burn アドレスを返す — treasury は決して見せない。
permit モードが提供されている場合、エージェントは burn アドレスに束縛された認可に署名するだけ — 支払者のトランザクションとガスは不要。
permit モードではファシリテータが burn を送信。self-transfer では支払者自身が送信します。確定と同時にAPIの結果が返る。
後段でZK証明が treasury に mint — どの burn の償還かは明かさずに。
ガイド付きブラウザデモは、実際の zERC20 スタック上でフロー全体を実行します。各ステップはボタンになっていて、誰が動くのかがラベルで分かります — クライアントが何をし、プロバイダが何をし、オンチェーンに何が残るのか。
その結果: treasury の残高は増えるのに、そこへ追跡可能な入金はゼロのまま。
思想としてのプライバシーではなく、経済的損失の回避としてのプライバシー。公開の支払い履歴が、そのまま競争情報の漏洩になる領域です。
ファンドのエージェントがニュース・開示情報・衛星画像・オンチェーンデータを買えば、支払いの順序だけで投資テーマが露呈します。支払いの秘匿はアルファの保護です。
サプライヤー・物流・与信・為替APIをまたぐ支払いは、サプライチェーンと需要予測を露呈し、競合とサプライヤーに交渉力を渡してしまいます。
マーケットデータ・シグナル・執行系APIに呼び出しごとに支払うBotは、支払いのタイミングと頻度がそのまま戦略を刻印します。観測者はそこから戦略を逆算し、コピーし、先回りすらできてしまいます。
推論・特化モデル・ツールAPIに呼び出しごとに支払うエージェントは、自らのアーキテクチャを公開してしまいます — どのプロバイダに、どの規模で、いくら払っているか。それはプロダクトの設計図と原価構造であり、競合から読み取れてしまいます。
固定の payTo では、売上・成長率・大口顧客への依存度を誰でもグラフ化できます。SubEtha はチェーンから売上を読めなくします。
いいえ。支払いの両端はどちらも見えたままです — エージェントがトークンを支払ったことも、プロバイダの口座(treasury)に入金があったことも、チェーン上で誰でも確認できます。決して現れないのは、その2つを結ぶ対応関係 — どの支払いがどの入金になったのか — だけです。目指すのは企業AIエージェント向けの秘匿マシン決済であって匿名化ではなく、view key による監査可能な開示もロードマップに明記しています。
ほとんど変わりません。「APIを呼ぶ → 『支払いが必要です』と返ってくる → 支払う → 結果を受け取る」という手順はそのままです。違いは、案内される支払い先がプロバイダ本来の受け取りアドレスではなく、その支払い専用に作られた使い捨てアドレス(burn アドレス)になること。あとの精算は zERC20 の burn → mint が裏側で処理します。
permit モードで、対応する PermitBurner をファシリテータが提供している場合は、エージェントのガスは不要です。エージェントは「この支払いを許可します」という署名だけを行い、ファシリテータが送信とガス支払いを担います。self-transfer のフォールバックでは、支払者自身が burn transaction を送るためガスが必要です。
残るのは2つの記録だけです。1つは「支払者が使い捨てアドレスにトークンを送った」という記録(burn)、もう1つは「プロバイダの口座にトークンが入った」という記録(mint)。この2つを結びつける情報はチェーン上のどこにも書かれないため、外から見ても、どの支払いがどの入金になったのかは分かりません。
いいえ。SubEtha 独自のトークンは発行しませんし、既存の仕組みの改変(フォーク)もしません。x402 型の支払いフローと、公式 zERC20 ツールチェーン上の精算とをつなぐ橋渡し役です。
対応するデプロイでは、実験的なバッチ経路で複数の支払いをまとめて精算できます。プロバイダは支払いをため、都合の良いタイミングで treasury へまとめて mint できます。支払いごとに別々の使い捨てアドレスを使うため、バッチ化しても直接の payer → provider リンクは作られませんが、金額やタイミングによる推測可能性は残ります。
SubEthaの実装詳細や設計の背景については、より詳しい技術記事をご覧ください。
リクエスト、402、permit または self-transfer、burn、accepted 応答、証明ゲート付き mint という一連のフローが、公式 zERC20 ツールチェーン上のローカル非本番リファレンス実装として現在動作しています。未監査であり、商用提供はライセンスと運用準備の確認を前提とします。
金融リサーチチーム、データプロバイダ、エージェント開発者と、支払い履歴が戦略を漏らす問題を今の段階から検証します。企業管理機能やProvider統合の優先順位は、この検証結果から決めます。
最初の導入を、両側で簡単にします。API Providerには、差し替えやすい x402 アダプタ、テストネットのサンドボックス、導入ドキュメント、精算・手数料の透明性、統合支援を提供します。Agent開発者には、payer SDK、MCP・Python・CLI・各種フレームワーク統合、安全なデフォルト、サンプル、リファレンスアプリを提供します。ProviderはAPI自体を変えずにSubEthaを受け入れ、Agentは秘匿決済を自前実装せずに支払える状態を目指します。
実決済を備えた x402 互換の決済レイヤーと、プロバイダ・エージェント向け統合を外部検証に向けて強化します。初期ベータは1つのネットワークとアセットに集中し、広い提供の前にセキュリティと運用面を固めます。
AIエージェントの支払いを企業が管理できるようにします。エージェントごとの予算、許可Provider、人間承認、永続的な決済状態、支払いレポート、エージェント実行環境との統合を提供します。
顧客が管理する view key、期限付き開示パッケージ、入出金双方の制裁スクリーニング、監査人向けエクスポート。公開台帳上では秘匿、機関に対しては監査可能。
企業AIエージェント向けの managed private payment layer として運用提供します。デザインパートナーを有償導入へつなげ、信頼できるProviderネットワークを作り、x402 privacy schemeのドラフトを公開し、開発者向け統合を外部利用に向けて安定化します。提供する本体はライブラリだけではなく、運用される秘匿決済レイヤーです。
SubEthaは、AIエージェントがAPIやデータサービスを利用するための、秘匿性を備えた決済レイヤーです。AIエージェントを開発・運用している方、エージェント向けのサービスを提供している方、この領域に関心のある方とお話ししたいと考えています。デモやコードについて、ぜひお気軽にご連絡ください。