AI agents pay APIs.
The public link is gone.
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.
A payment log is a strategy log.
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.
The same 402 flow. The link is what's missing.
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 burn address is an opaque one-way hash, fresh for every payment — the receiver can't be derived from it, and burns don't link to each other.
- The mint's ZK proof exposes only the transfer root, a recipient hash, and the amount. Which burn was spent is a private witness.
- The payer is never shown the treasury: the 402 carries only the burn address. No payer → treasury transfer ever exists on-chain.
Watch one private payment, end to end.
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.
Where confidentiality is a must-have, not a nice-to-have.
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.
Frequently asked questions
Is this a mixer or anonymous payments?+
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.
Does it change how I integrate x402?+
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.
Does the paying agent need gas?+
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.
What actually remains on-chain?+
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.
Is there a new token?+
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.
Can a provider settle many payments at once?+
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.
Go deeper into the design.
For the implementation details and the thinking behind SubEtha, see the longer technical articles.
From working flow to payments layer.
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.
Building services for AI agents?
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.