Your agents shouldn’t broadcast your strategy
The chain sees that an agent paid. Not who it paid.
How an agent leaks strategy
- agent wallet
- api.vendor.eth ×212 today
- data.market.eth ×40
01 Every call names a vendor.
- rival’s dashboard
- agent-04 switched to
- compute.node.eth
02 Tool changes show up live.
- rival’s roadmap
- They’re building X.
- Ship it first.
03 Your strategy becomes theirs.
A machine that seemed to play on its own. Look inside the cabinet.
Joseph Racknitz, The Turk, 1789
Where Curvy sits in x402
Standard x402 between agent and service. Curvy only changes where the money lands.
Request
402 + payment terms
Signed EIP-3009 authorization
Settle
Settled to a fresh address
200 + response
What an agent wallet leaks
All of it is readable from one public address, by anyone, for as long as the chain exists.
- 01 Vendors Every service it relies on.
- 02 Cadence When it works, and on what.
- 03 Prices What each service charges you.
- 04 Strategy Which tools you switch to, and when.
How it works with x402
-
01
Service replies 402
With its payment terms
-
02
Agent signs
Standard EIP-3009
-
03
Curvy settles
To a fresh address
-
04
Call completes
Confirmed by reference
- Standard x402
- One-off or batched
- Payments SDK
- Docs for coding agents
Who sees what
The agent’s transfer and amount stay public.
| who | Agent’s payment | Which service | Service revenue |
|---|---|---|---|
| The public | Can see | Hidden | Hidden |
| The agent’s owner | Can see | Can see | Hidden |
| The service | Can see | Can see | Can see |
One-off or batched?
- Cost per payment
-
Higher
- Time to settle
-
Faster
Best when something downstream waits on each confirmation.
What design partners get
-
A direct line
Work with our engineers, not a ticket queue.
-
Shape the roadmap
Agent-side privacy, built with you.
-
Early access
Try new pieces as they land.
-
A joint write-up
A case study, if you want one.
We’re looking for design partners
Building agent wallets or payment networks? Let’s build the next pieces together.
Before you build
-
Standard x402
No change to agents or services.
-
What stays public
The agent’s transfer and its amount.
-
Owner visibility
The owner sees every payment.
-
Custody
Non-custodial. Keys stay with you.
-
Cost per payment
Batch to lower it.
-
Agent-side privacy
Being built with design partners.
Is it right for you?
Good fit if
- You run agent wallets or an agent payment network
- Your agents pay services over x402
- Users care who sees their agents’ vendors
- You want to shape the next pieces with us
Not yet if
- You need agent-side privacy in production today
- You need chains other than Arbitrum
- Your agents pay with cards
- You need fiat settlement
Built to be checked
- Audited by Ethernal Full report public on GitHub
- Open-source contracts github.com/0xCurvy
- Published research Stealth address protocols
- 10+ years together Two PhDs in ZK and cryptography
Questions
Does this work with standard x402?
Yes. Agents sign the same EIP-3009 authorizations and services return the same 402 responses. The Curvy facilitator handles settlement.
What can an observer still see?
The agent’s transfer and its amount. Not which service received it, so no vendor list and no per-service spend.
Can the owner see every payment?
Yes. The owner controls the agent’s wallet and sees every payment it makes.
Which tokens are supported?
Curvy Payments settles on Arbitrum. Check the docs for the tokens the x402 facilitator accepts today.
Agents should pay the way companies do.
Tell us how you take payments today, and we’ll show you where Curvy fits.
- Your payment flow, step by step
- What stays visible, and to whom
- How the SDK fits your stack
- Your compliance questions