Curvy is a privacy infrastructure for EVM-compatible blockchains, and one of the workloads it was built for is autonomous agent payments – the kind of always-on, programmatic spending that AI agents, scheduled bots, and machine-to-machine services do without a human at the keyboard.
This post explains why agents need privacy in a way that human users do not, what breaks when you skip it, and how to wire up Curvy’s stealth-address SDK so an agent can send or receive payments without exposing its main wallet.
Why agent payments are a privacy problem of their own
A human user has bad days where their address gets doxxed and a good firewall around the rest of their financial life. An agent does not have that buffer.
An agent’s wallet is its identity, its operating capital, and its attack surface, all in one. The address signs every transaction, holds every balance, and is the thing competitors, scrapers, and adversaries will watch first. Three things go wrong when that wallet is public:
The first is competitive intelligence. If an agent is running a strategy – arbitrage, scheduled procurement, content licensing, a market-making loop – every move is on chain. The strategy is reverse-engineerable from the trades. The schedule is observable from the timestamps. The counterparties are visible to the recipients.
The second is targeted exploitation. An always-online wallet with predictable spending patterns is the most appealing target a phishing or sandwich operator could ask for. Public balance plus public schedule equals a planning document for an attacker.
The third is downstream linkage. Every entity the agent pays inherits the agent’s transparency. A vendor receiving a payment from a known agent wallet is a vendor whose business with that agent is now on the public ledger, whether the vendor wanted that or not.
The standard answers – rotate addresses manually, route through a custodian, run on a privacy chain – either do not scale to the volume agents produce or break the developer ergonomics of running on EVM.
What Curvy gives an agent
A single change of address per payment, derived deterministically by the sender, is recoverable only by the recipient. The agent publishes one stealth meta-address. Anyone paying it lands at a fresh, single-use destination. The agent’s main wallet does not appear on the receive side at all.
The send side works the same way in reverse. The agent computes a stealth destination from a counterparty’s meta-address, sends a normal transfer, and never reuses that destination. There is no bridge, no pool, no withdrawal queue. The funds settle on the chain the agent was already running on.
Because Curvy is direct point-to-point and not a shielded pool, agent payments stay composable with the rest of an agent’s stack: it can still call DeFi, swap, bridge, hold custody – none of that breaks because the funds live at real EOAs.
A minimal walkthrough
The full reference is in the Curvy SDK docs. The shape of an agent integration is short enough to sketch here.
1. Generate the agent’s meta-address
When an agent is provisioned, it generates a stealth meta-address once and stores the spending and viewing keys in whatever secure store you already use for its main key material.
import { Curvy } from ‘@0xcurvy/sdk’
const curvy = new Curvy({ chain: ‘base’ })
const { metaAddress, spendingKey, viewingKey } = await curvy.generateMetaAddress()
// Publish metaAddress alongside the agent’s identity (ENS record, manifest, etc).
// Persist spendingKey and viewingKey in the agent’s secure storage.
The viewing key is what lets the agent scan announcements to find incoming payments. It can be given to a scanning service without giving up the ability to spend, which matters for hosted agent infrastructure.
2. Receive a payment
When a counterparty pays the agent’s meta-address, Curvy posts an announcement to the protocol’s registry contract. The agent’s scanner watches for announcements that match its viewing key and surfaces the resulting stealth address.
const incoming = await curvy.scan({
viewingKey,
fromBlock: lastSeenBlock,
})
for (const payment of incoming) {
// payment.stealthAddress, payment.amount, payment.token, payment.txHash
await ledger.record(payment)
}
Scanning is a read-only operation. It never reveals the agent’s identity to the network, and it can be done by a separate process from the one that holds spending authority.
3. Spend from a stealth address
When the agent needs to spend, it derives the per-address private key on the fly using its spending key plus the announcement metadata, and signs as usual.
const privateKey = curvy.derivePrivateKey({
spendingKey,
announcement: payment.announcement,
})
await wallet.sendTransaction({
privateKey,
to: vendorStealthAddress,
value: amount,
})
There is no separate “withdraw” step. The funds are already at a normal EVM address. The agent signs from the derived key and the transfer settles like any other transaction on the chain.
4. Pay another stealth recipient
If the counterparty is also using Curvy, the agent computes a fresh stealth destination from their meta-address and sends to that:
const destination = await curvy.computeStealthAddress({
metaAddress: vendorMetaAddress,
})
await wallet.sendTransaction({
to: destination.address,
value: amount,
})
await curvy.announce(destination.announcement)
The announcement is a single small write that lets the recipient find the payment without revealing it to anyone else.
Patterns that work well for agents
A few configurations show up repeatedly in production deployments.
Rotating receive endpoints per session. An agent that interacts with many counterparties can publish a single meta-address but expose it under different ENS records or capability URLs, making correlation across sessions harder for anyone watching from outside.
Separating scanner and signer. Run the viewing-key-only scanner in a high-availability environment and keep the spending key inside an HSM or threshold-signing setup. Curvy’s design supports this cleanly because viewing and spending are separable.
Selective disclosure for invoices. When an agent needs to prove a payment to a counterparty or auditor, the spending key holder can produce a view-key-style proof of receipt without revealing the rest of the agent’s history. This is built into the protocol and documented in the Curvy compliance toolkit.
Per-flow meta-addresses. A high-volume agent can rotate meta-addresses across business lines (procurement, settlement, refunds) so a leak in one flow does not compromise the others.
What does this change in practice
Once private payments are wired into an agent’s stack, two things shift quickly.
The agent stops being a public asset. Its strategies, balances, and counterparties stop being free intelligence. The vendors and partners it pays stop being implicated in the agent’s transparency.
The integration cost is small enough that it stops being a roadmap item and starts being a default. We have seen working integrations land in a single afternoon for teams already comfortable with EVM tooling.
If you are building agent infrastructure – a payment rail for AI agents, an autonomous treasury, a machine-to-machine settlement layer – the Curvy SDK reference is the place to start. The contracts are open source at github.com/0xCurvy, and the team is reachable through curvy.box.
Frequently asked questions
Why do AI agents need private payments?
An agent’s wallet is its operational identity. A public wallet leaks its strategy, schedule, balances, and counterparties to anyone with a block explorer, which is a security and competitive risk that human users do not have to the same degree.
Does Curvy work for autonomous, always-online agents?
Yes. Curvy was designed with always-online recipients in mind. Scanning is read-only and can be separated from spending authority, which fits standard agent infrastructure patterns.
What chains can agents use Curvy on?
Solana, Ethereum, Base, Arbitrum, Polygon, Optimism, BSC, Linea, and Gnosis at the time of writing. Additional EVM chains are added on a rolling basis.
Can my agent prove a payment was received without revealing all its history?
Yes. Curvy supports selective disclosure: the recipient can prove receipt of a specific payment to a counterparty or auditor without exposing other transactions. The compliance toolkit covers this in detail.
Does Curvy require a token or staking?
No. There is no Curvy token, no points program, and no staking requirement. Agents pay normal EVM gas for their transactions.
Curvy is a privacy infrastructure for EVM-compatible blockchains. Read the SDK docs at docs.curvy.box or browse the source at github.com/0xCurvy.