01 · REQUEST
Call the API
The agent requests a paid resource without a human checkout or API key.
Agent Payment Intelligence Firewall
AI agents pay APIs.
The payment is public.
The link is not.
SubEtha keeps the HTTP 402 flow and changes the settlement boundary: a fresh burn address in the challenge, a proof-gated mint behind it, and no payer → provider transfer written on-chain.
Built on the official zERC20 toolchain. The current repository is a local, non-production reference implementation — unaudited, with production profile acceptance intentionally gated.
One payment / two surfacesPUBLIC LEDGER
BURNpayer → 0xd2d2…7ed9
fresh one-time address−1234
fresh one-time address−1234
MINT→ treasury
proof-gated settlement+1234
proof-gated settlement+1234
The chain sees both ends. The direct correspondence between them stays out of the public record. Timing and amount correlations remain possible.
01 / The problem
A payment log is a strategy log.
Machine payments make the leak worse. Every request can reveal what an agent depends on — while a fixed provider address exposes revenue, usage, and customer concentration.
Payer side
What the agent is doing can be inferred.
API choice, timing, order, and spend become a public trace of workflows, research themes, external dependencies, and cost structure.
Provider side
The provider's revenue is public.
A standard payTo address lets observers chart inflows and estimate growth, usage trends, and dependence on key customers.
02 / The protocol
Same 402 flow.
Different settlement boundary.
SubEtha is not a mixer and does not hide the fact that tokens were spent or minted. It changes what the public chain can connect.
02 · CHALLENGE
402 + burn address
The provider returns price and a fresh payTo; the treasury is never handed to the payer.
03 · AUTHORIZE
Sign or transfer
Permit mode lets the payer sign while the facilitator relays the burn. A self-transfer fallback remains available.
04 · ACCEPTED
Serve the resource
Once the burn confirms, the payment is accepted and the API result can be served.
05 · FINALIZED
Mint later
A proof-gated mint reaches the treasury without revealing which burn it redeems.
The boundary
Publicly private.
Institutionally auditable — by design.
- Public observers see a burn and a mint, not a direct payer → provider transfer.
- The provider and payer retain their own records for reconciliation today.
- Standardized customer-held view keys and time-bound auditor disclosure are roadmap work, not shipped controls.
Provider-side derivation
burnAddress = truncate160(
Poseidon("burn", recipientFr, secret)
)
recipientFr = SHA256(chainId ‖ recipient ‖ tweak)
secret never appears on-chain.
03 / The operational layer
Privacy is not enough. Operators need a record they can use.
The current implementation adds a participant-scoped payment history package: payer, provider, and facilitator views are separated, lifecycle state is explicit, and access is bound to verified server-side identity rather than caller-supplied headers.
Read the history model ↗PAYMENT RECORDVERIFIED VIEW
| accepted | evidence received |
| finalized | mint proof verified |
| participant | role-scoped |
| reorg | stale / revoked |
Unknown remains unknown until reconciliation. Records are not silently deleted. Public and payer views redact mint, treasury, linkage, and secret material.
04 / Current scope
From working flow to an operated payment layer.
The codebase is moving from a demo-shaped flow toward the responsibility of running it: durable state, identity boundaries, fees, profiles, and recovery.
Implemented
Facilitator daemon + provider/client SDKs
Config-driven HTTP facilitator with challenge, verify, settle, supported, admin, health, finalize loop, fee handling, and operational checks. SDK packages keep provider integration thin.
repository today
Implemented
Durable payment history
Participant bindings, role-scoped projections, signed identity resolution, bounded exports, encrypted backup checks, proof verification, and explicit reorg lifecycle states are in the current develop line.
repository today
Enabled / gated
Local and Sepolia profiles
Local operation is enabled. Testnet requires explicit Sepolia configuration and admin authentication. Production starts fail-closed until confirmation and finality policy is implemented and reviewed.
profile boundary
Roadmap
Managed private payment layer
Design partners, provider network, spend policy, customer-controlled view keys, sanctions screening, auditor exports, SLA, and commercial operation are not claims of the current PoC.
next discovery
05 / Who it is for
Protect the work behind the payment.
Start with the people whose payment history carries competitive information — on both sides of the market.
Financial research
Agents that buy data
Keep investment themes and research dependencies from becoming a public sequence of API calls.
API providers
Protect customer composition
Reduce payer-level visibility into inflows without pretending that the treasury or total activity is invisible.
Agent builders
Pay without owning settlement
Use x402-compatible interfaces while the private settlement and operational state remain behind a facilitator.
Trading & procurement
Keep timing from becoming strategy
Machine payment cadence can reveal what a bot watches, buys, or negotiates.
Infrastructure teams
Make the boundary reviewable
Accepted, finalized, proof, identity, and recovery are separate surfaces instead of one vague “private” claim.
Your agent. Your API.
Run the reference flow.
Tell us where the protocol, developer experience, or claim boundary breaks.
06 / See it run
A guided payment, end to end.
The web demo shows the client/provider split and the separation between accepted resource delivery and finalized treasury settlement.
Run the local demo ↗
07 / FAQ
The short answers.
Is this anonymous payment or a mixer?+
No. The burn and mint remain visible. The design removes the direct correspondence from standard public records; it does not remove operational knowledge, timing correlations, or the need for future disclosure controls.
What is the difference between accepted and finalized?+
Accepted means the burn evidence has confirmed and the provider can serve the resource. Finalized means the later proof-gated mint has been verified. They are deliberately separate lifecycle states.
Who can read payment history?+
The current history model is participant-scoped. A verified payer or provider identity can read its own projection when bound to the payment. Caller-supplied tenant or role headers are not authorization evidence.
Is production operation available?+
No. This is a local, non-production reference implementation. The testnet profile has explicit gates; the production profile remains fail-closed until confirmation/finality policy and operational review are complete.
Does SubEtha issue or fork zERC20?+
No. SubEtha connects an x402-style HTTP payment flow to settlement through the official zERC20 toolchain. It does not issue a new token or redistribute the official SDK source.
08 / Contact
Run the PoC.
Bring back the hard questions.
We are looking for agent builders, paid API providers, protocol engineers, and teams who can test whether payment-history leakage is a real problem in their workflow.