Vitalik has published two pieces in the past two months that together make the case for why AI agents need cryptographic privacy at the payment layer. Nobody else has laid it out this clearly.

The first, co-authored with Davide Crapis (the EF’s AI lead) on ethresear.ch in February, proposes a protocol called ZK API Usage Credits. The premise: when a user or agent calls an LLM API, they currently have to choose between identifying themselves (email, credit card, full surveillance) or paying per request on-chain (slow, expensive, every call traceable). The post describes a system where you deposit funds into a smart contract once and then make thousands of API calls anonymously, using rate-limit nullifiers so honest users stay unlinkable while double-spenders get slashed.

The second, published April 2, is more personal. Vitalik describes abandoning cloud AI entirely and running a local Qwen 3.5 model on his (pretty powerful) laptop. He cites research showing 15% of AI agent skills contain malicious instructions. He built a messaging daemon that requires human approval before his AI can contact anyone. He recommends wallet teams cap autonomous AI spending at $100/day and require human confirmation for anything above that or anything carrying calldata that could exfiltrate data.

Both posts are focused on Ethereum. The ZK API Credits protocol settles on Ethereum smart contracts. The wallet recommendations assume Ethereum’s tooling and account model. The Privacy Cluster, the 50-person team behind Kohaku, is an Ethereum Foundation initiative. But the problem they’re describing exists on every EVM chain.

The problem is chain-agnostic

The ZK API Credits post lays out the tradeoff directly: API providers currently force users to choose between identity-based access (Web2, full surveillance) or on-chain per-request payments (traceable, expensive). The proposed solution uses Ethereum smart contracts as the settlement layer for anonymous deposits and ZK-verified usage.

But the agents paying for these API calls don’t live on Ethereum mainnet alone. An AI agent managing a DeFi portfolio might execute trades on Arbitrum, bridge through Base, settle payments on Polygon, and hold treasury on Ethereum. An agent paying for computation through x402 might route transactions across whichever chain has the lowest fees at that moment. Real agentic infrastructure is already multichain by default. Agents optimize for cost and speed, so they don’t stick to one network.

The privacy leak Vitalik describes applies identically on every chain. If your agent’s API payments are visible on Arbitrum, a competitor can reconstruct your usage patterns just as easily as on Ethereum mainnet. If your agent’s trades are transparent on Polygon, front-runners can exploit them the same way. The chain doesn’t matter. The transparency does.

Yet the solutions being built are almost entirely Ethereum-first. Kohaku targets Ethereum mainnet and eventually some L2s. The ZK API Credits protocol deposits into Ethereum smart contracts.

If you’re building on Base, BSC, Gnosis, or any other chain the question becomes: who is building your privacy layer?

What the ethresear.ch commenters got right (and wrong)

The discussion under the ZK API Credits post is worth reading in full because it surfaces the real objections. So make sure to check it out.

One commenter called it “a solution in search of a problem” and argued that anyone who truly wants privacy will run inference locally. A direct push-back followed: hosting a LLM locally costs around $50,000 in hardware, and most users can’t justify that for everyday use. The economics of shared inference mean most agents will call remote APIs for the foreseeable future. Local-first is a fine principle, but it doesn’t scale to most real-world agent deployments.

One of the ML engineers made a more technical point: the refund mechanism in the protocol leaks information through timing metadata. Output token count, time-to-first-token, generation latency, speculative decoding acceptance rates. Over enough requests, traffic analysis can re-link anonymous calls to the same user even with perfect nullifier unlinkability. He cited a documented timing side channel in vLLM’s prefix caching that achieved near-perfect accuracy distinguishing whether two requests shared context.

This is the kind of detail that matters. The cryptographic layer can be perfect and the privacy still fails because of metadata leakage at the infrastructure level. Vitalik’s own April 2 post acknowledges this implicitly: he stores Wikipedia dumps locally to avoid leaking his research interests through search queries. He routes nothing through external services that he doesn’t absolutely have to.

The point extends well beyond Ethereum. Privacy is a system design problem. ZK proofs handle one layer, but timing metadata, transaction graphs, IP addresses, RPC provider logs, and on-chain amount correlation all leak information through channels that the cryptography doesn’t touch.

Where Curvy sits in this picture

We’ve been working on this problem for two years, and our starting point was the same observation Vitalik arrived at: the payment layer is the critical privacy weak point for agents.

But we made a different scope decision. Instead of building a protocol that settles on Ethereum and works backward from there, we built middleware that works across eight EVM chains from the start. The reasoning was straightforward: agents don’t stay on one chain, and a privacy layer that only covers Ethereum mainnet leaves the rest of the transaction graph exposed.

Curvy’s SDK handles private payments at the infrastructure level. Shielded notes hide amounts, stealth addresses break sender-recipient links, and ZK proofs verify state transitions without revealing private data. The Portal system means the sender doesn’t need to install or use anything new; they send to an address from whatever wallet they already have, and privacy happens automatically on the receiving side.

The compliance question matters here too. One of the ethresear.ch commenters argued that society won’t allow anonymous agents to transact freely, and that KYC/AML is unavoidable. He’s probably right about the regulatory trajectory. That’s why Curvy has viewing keys and KYT/AML hooks in the SDK from the start. Agents shouldn’t be unaccountable. But they also shouldn’t have to broadcast every transaction to get permission to operate.

The ZK API Credits proposal is good cryptography. But it solves one specific slice: anonymous metered billing for API calls on Ethereum. An agent operating in the real world needs privacy across payments, treasury management, trade execution, and API billing, on multiple chains simultaneously. That’s a full stack, not a single protocol.

What this means for builders on other chains

If you’re developing agentic infrastructure on any EVM chain, the Vitalik posts are worth reading as a design document, not just as Ethereum-specific proposals.

The core principles transfer directly. Agents need to be able to pay for services without creating a permanent, public record of every interaction. Identity-based billing is a surveillance layer that agents shouldn’t have to accept. Per-request on-chain payments create traceable graphs that competitors can exploit. The answer involves some form of anonymous, prepaid, ZK-verified payment mechanism.

The implementation, however, can’t be Ethereum-only. An agent that’s private on Ethereum mainnet but transparent on Arbitrum hasn’t solved the problem. It’s just moved the observable surface to a different chain.

This is the gap we’re building for. The Ethereum-focused work is directionally right, but the scope needs to be wider and the timeline shorter. Agents are already transacting across multiple chains. The privacy layer should already be there.

---

Curvy is a privacy middleware for agentic payments. Documentation at docs.curvy.box.

The Vitalik/Crapis ZK API Usage Credits post: ethresear.ch

Vitalik’s self-sovereign AI setup post: vitalik.eth blog, April 2, 2026

At 02:47 AM, an autonomous operations agent named Nova quietly renews a domain.

No alerts are triggered. No procurement tickets are created. No one from the finance team is awake.

Yet a critical part of the company’s digital infrastructure has just been secured for another year. At scale, even the smallest operational payments become strategic signals.

Nova works for a fast-growing software company expanding across multiple regions. Its role is not focused on large treasury deals or complex negotiations. Instead, Nova handles thousands of small but essential financial operations that keep the organization running smoothly.

These include:

• renewing domains
• paying SaaS subscriptions
• topping up cloud credits
• settling API usage fees
• purchasing datasets
• maintaining marketplace listings

Individually, these transactions seem minor. Collectively, they define operational continuity and strategic readiness. This introduces a new class of risk, operational visibility at scale.

The Invisible Risk of Simple Payments

In the past, such tasks were handled manually or through centralized billing accounts.

A finance manager would receive reminders, log into dashboards, approve payments, and track invoices. As organizations scaled globally, this process became fragmented across teams, tools, and jurisdictions.

Missed renewals could lead to domain expirations. Delayed payments could suspend essential services. Overexposed credentials could create security vulnerabilities.

Automation tools improved efficiency but introduced new risks.

Shared payment tokens became attractive targets for attackers. Centralized billing accounts exposed spending patterns. Transparent transaction rails revealed operational signals to competitors.

What appears trivial at a human level becomes strategically sensitive at scale.

A Strategic Move Before the Market Knows

One night, Nova receives an internal signal.

The company’s leadership has decided to explore entering a new Southeast Asian market. The expansion has not been publicly announced. Marketing campaigns are still being prepared. Local partnerships are under discussion.

However, securing key digital assets must happen immediately.

Nova begins searching for available domains relevant to the new market. It identifies several high-value names tied to local language keywords and emerging product categories.

Timing is critical. If competitors detect these purchases, they may infer the expansion strategy or attempt to acquire adjacent domains.

Nova initiates negotiations with multiple domain registrars operating through automated marketplaces. Each counterparty system needs assurance that Nova is authorized to transact.

Nova presents cryptographic proof that:

• it represents a legally recognized organization
• it has delegated authority to execute operational purchases
• the transaction falls within predefined budget constraints

Verification happens instantly, without manual review or identity document exchange.

Trust is established between machines.

Confidential Execution in Competitive Environments

Once the optimal domain portfolio is identified, Nova executes the purchases.

Instead of using a persistent account identifier that could be tracked across transactions, each payment is routed through a privacy-preserving execution layer.

Every purchase generates a unique settlement path.

External observers can verify that:

• compliant operational payments occurred
• authorized entities were involved
• policy limits were respected

But they cannot determine:

• which market the company is preparing to enter
• how many domains were acquired
• how the purchases relate to upcoming product launches
• which suppliers or registrars were involved

This confidentiality protects strategic positioning. This is not a feature of a wallet or an application. It is a property of transaction execution itself.

In global markets, even small signals can trigger competitive responses. Domain registrations, infrastructure spend patterns, and vendor relationships often reveal more than formal announcements.

Nova ensures that preparation remains invisible until the company is ready to act.

Continuous Operations Without Friction

Throughout the same night, Nova completes dozens of additional tasks.

It renews a marketing microsite domain scheduled for an upcoming campaign. It settles usage fees for a machine learning API that crossed its billing threshold. It tops up a regional cloud account after detecting increased compute demand.

Each action is executed within clearly defined authority limits. Each transaction generates an internal cryptographic audit record.

By morning, the operations team receives a concise report:

• payments executed
• budgets consumed
• anomalies detected
• policies enforced

Automation has not reduced oversight. It has transformed oversight into programmable governance.

Accountability When It Matters

Months later, during a financial review related to international expansion, auditors request confirmation of certain operational expenditures.

The company does not need to expose full transaction histories or reveal competitive strategy.

Instead, it provides selective cryptographic disclosures proving that:

• Nova was authorized to perform the domain acquisitions
• Transactions were executed within approved limits
• Counterparties met compliance requirements

Regulators obtain assurance. The organization retains confidentiality over its market entry plans.

Both objectives are satisfied.

A New Layer of Organizational Capability

Nova is not simply a convenience tool.

It represents a new operational model where organizations deploy autonomous agents to manage continuous financial execution with precision and discretion.

As companies expand globally, such agents will handle procurement, subscription optimization, logistics coordination, and infrastructure management in real time.

They will require:

• delegated organizational identity
• scoped transactional authority
• privacy by default
• auditability on demand

Systems that automate execution must also control what that execution reveals.

What begins as a quiet domain renewal becomes a glimpse into the future of enterprise operations.

In that future, organizations will not rely solely on human workflows or static payment systems.

They will deploy accountable, confidential digital operators capable of acting instantly while protecting strategic intent.

And the infrastructure enabling these operators will shape how commerce is conducted in the autonomous era. It will determine not only how transactions are executed, but how much of that execution remains visible.

---

This thought leadership article was written by Mališa Pušonja, CPO at Curvy.

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.

Curvy is a privacy infrastructure for EVM-compatible blockchains. The Curvy SDK is the developer surface for that protocol: it generates stealth meta-addresses, derives per-payment destinations, scans announcements, and signs from the resulting addresses, across every chain Curvy supports.

If you are integrating private payments into a wallet, payroll tool, merchant flow, agent platform, or treasury application, this is the layer you will spend the most time with. This post walks through what the SDK does, how to install it, and the four operations that cover almost every integration.

A working integration usually takes a developer between 30 minutes and half a day, depending on how much UI polish you want.

What the Curvy SDK does

The SDK is a TypeScript library with first-class support for Node.js and modern browser environments, plus a Rust crate for server and embedded use. It handles four things:

It generates and manages stealth meta-addresses on behalf of recipients.

It derives single-use stealth destinations from a meta-address on the sender side, so payments land at fresh addresses every time.

It scans Curvy’s on-chain announcement registry on the recipient side, so users find their incoming payments without revealing what they are scanning for.

It derives the per-address private key needed to spend from a received stealth address, on demand.

Everything else — submitting transactions, custody, UI — uses your existing tooling. The SDK is intentionally thin around the privacy primitive.

Install

npm install @0xcurvy/sdk

# or

pnpm add @0xcurvy/sdk

# or

yarn add @0xcurvy/sdk

The package is published from the github.com/0xCurvy/sdk repository. Releases are signed and changelogged, and the audit reports are linked from the README.

Initialize

import { Curvy } from ‘@0xcurvy/sdk’

const curvy = new Curvy({

  chain: ‘ethereum’, // ‘ethereum’ | ‘base’ | ‘arbitrum’ | ‘polygon’ |

                     // ‘optimism’ | ‘bsc’ | ‘linea’ | ‘gnosis’

  rpcUrl: process.env.RPC_URL,

})

The SDK reads chain-specific protocol addresses from a bundled registry. You can override them for testnets or local forks via the addresses option.

The four operations

1. Generate a meta-address

Recipients run this once. The result is a meta-address (publishable, the same way you would publish an ENS name) plus a spending key and viewing key (private, stored alongside any other key material).

const { metaAddress, spendingKey, viewingKey } = await curvy.generateMetaAddress()

A common pattern is to derive the spending key from an existing wallet so users do not have to manage another seed phrase. The SDK supports BIP-32-style derivation against any provider that exposes a signer.

2. Compute a stealth destination on the sender side

Senders take a recipient’s meta-address and produce a single-use destination plus an announcement.

const { stealthAddress, announcement } = await curvy.computeStealthAddress({

  metaAddress: recipientMetaAddress,

})

The sender then submits a normal transfer to stealthAddress and posts announcement to the protocol so the recipient can find the payment. Both can happen in the same transaction.

3. Scan for incoming payments on the recipient side

Recipients run a scanner against Curvy’s announcement contract using their viewing key.

const incoming = await curvy.scan({

  viewingKey,

  fromBlock: lastScannedBlock,

})

for (const payment of incoming) {

  // payment.stealthAddress, payment.token, payment.amount,

  // payment.txHash, payment.announcement

}

Scanning is read-only. The viewing key never has to leave the scanner process, and it can be given to a hosted scanning service without exposing spending authority.

4. Spend from a received stealth address

When the recipient is ready to spend, the SDK derives the address-specific private key on demand:

const privateKey = curvy.derivePrivateKey({

  spendingKey,

  announcement: payment.announcement,

})

From here, sign and submit transactions with whatever library you already use — viem, ethers, web3.js, or a wallet abstraction layer like AA bundlers.

Patterns that come up

Wallet integration. A wallet team typically adds a “Receive privately” toggle that exposes the user’s meta-address as a payment endpoint, plus a background scanner that surfaces incoming stealth payments alongside normal balances. Users see one inbox; the SDK handles the privacy underneath.

Payroll and contributor payouts. Payroll tools generate per-contributor stealth payments from a meta-address the contributor publishes once. The contributor’s main wallet never appears on the payroll’s transaction history, which removes a category of leak we have seen burn teams.

Merchant checkouts. Merchants accept payment by displaying a meta-address rather than a static wallet. Each customer’s payment lands at a fresh address; refunds go back via the customer’s stealth meta-address if they share one.

Agent infrastructure. Agent platforms typically separate the scanner (viewing key only, runs in standard cloud infrastructure) from the signer (spending key, runs in an HSM or threshold-signing setup). The SDK supports this split natively. There is more on this pattern in the agent payments walkthrough.

Treasury and DAO operations. Treasuries pay vendors and contributors out of stealth addresses without publishing a quarterly compensation table to anyone with a block explorer. View keys can be shared with auditors for selective disclosure.

Compliance and selective disclosure

The Curvy SDK exposes the building blocks for compliance-friendly disclosure: proof of receipt to a specific counterparty, source-of-funds attestation, and view-key-scoped audit access. None of this is bolted on; it falls out of the underlying cryptography.

const proof = await curvy.proveReceipt({

  spendingKey,

  payment,

  toCounterparty: counterpartyAddress,

})

The full reference is in the compliance toolkit docs. For teams whose legal counsel needs to evaluate the design, the threat model is documented end-to-end with explicit non-goals and disclosure paths.

Performance notes

Stealth-address derivation is cheap, sub-millisecond on commodity hardware. The bottleneck in any integration is scanning, because the recipient is reading every announcement on the chain since their last checkpoint and filtering with their viewing key.

The SDK ships with a default scanner that handles batching, range queries, and resumption against any standard RPC. For high-volume recipients (busy merchants, agent platforms, large payrolls) we publish a managed scanner endpoint that returns only matched announcements, which reduces RPC load to a single subscription.

Audits, gas profiles, and benchmark runs are published in the contracts repository.

Getting help

The fastest path to a working integration is the Curvy SDK quickstart, which has a runnable example end-to-end. Issues and feature requests go in github.com/0xCurvy. Integration support for production builds is available through curvy.box.

If your stack is not TypeScript, the Rust crate covers the same surface area. Other language bindings (Go, Python) are tracked on the SDK roadmap.

Frequently asked questions

What is the Curvy SDK?

The Curvy SDK is the developer library for integrating Curvy Protocol’s stealth-address private payments into an EVM application. It handles meta-address generation, sender-side derivation, scanning, and per-address key derivation.

Which languages does the Curvy SDK support?

TypeScript and JavaScript are first-class. A Rust crate is published for server and embedded use. Additional language bindings are on the roadmap.

Which chains does the Curvy SDK support?

Solana, Ethereum, Base, Arbitrum, Polygon, Optimism, BSC, Linea, and Gnosis at the moment. New chains are added on a rolling basis.

Is the Curvy SDK open source?

Yes. The SDK and the underlying contracts are open source under permissive licenses at github.com/0xCurvy.

Does the Curvy SDK require a token or staking?

No. There is no Curvy token. The SDK and protocol are usable on any supported chain with normal gas.

How is the Curvy SDK audited?

The contracts and SDK have been audited by independent firms. Reports are published in the contracts repository and the docs site.

Curvy is a privacy infrastructure for EVM-compatible blockchains. The SDK and protocol are open source at github.com/0xCurvy. Documentation is at docs.curvy.box.

There is a recurring question in on-chain private payments: which is better, stealth addresses or shielded pools? It is the wrong question. The two designs protect different parts of a transaction, and most serious privacy programs end up using both.

Curvy is the stealth-address option in that pairing. Curvy is a privacy infrastructure for all major blockchains, built around per-payment address derivation rather than commingled balances. This post explains where each design wins, where each has a real cost, and how the two fit together.

The two designs in plain language

A shielded pool works by depositing funds into a shared smart contract. Once inside, balances are tracked privately using zero-knowledge proofs. Users transact within the pool without revealing amounts or counterparties, then withdraw to a clean address when they exit. Privacy comes from the size of the pool: the more participants, the larger the anonymity set, the harder it is to trace any specific deposit to any specific withdrawal.

A stealth-address protocol – the design Curvy implements – works by deriving a fresh, single-use address from a recipient’s published meta-address. The sender computes the destination off-chain, sends a normal transfer to it, and posts a small announcement so the recipient can find the funds. Privacy comes from address unlinkability: the recipient never has to reuse an address, and the link between their main wallet and the receiving address is not visible on-chain.

Both are real privacy. Neither is a mixer in the regulatory sense. The mechanisms are different and the trade-offs are different.

What each design is actually good at

What shielded pools do well

They hide transaction amounts. A pool transaction reveals nothing about the value moved. Stealth addresses do not hide amounts, because the transfer is a normal on-chain transaction.

They hide the graph between participants inside the pool. Once funds are shielded, internal transfers between users are unobservable from outside.

They provide a strong anonymity set when the pool is large and active. Activity itself is the privacy.

What stealth addresses do well

Stealth addresses hide the link between a recipient and their incoming payments without requiring the recipient to take any action ahead of time. The recipient publishes a meta-address once, the same way they would publish an ENS name, and from that point any payment lands at a fresh, unlinked destination.

Settlement happens in a single, normal-looking transaction on the chain a sender already uses. There is no deposit, no withdrawal, no waiting for a pool to fill. Composability with the rest of DeFi is preserved because the funds live at a real EOA, not inside a shielded balance.

The regulatory and reputational risk that comes with commingled funds does not apply. Curvy payments are direct point-to-point transfers, not pool entries. There is no shared anonymity set whose worst depositor drags the rest down.

Recipients who are offline or stateless are supported natively. The recipient does not need a session, a connected wallet, or a deposit beforehand. That matters for vendor payments, recurring contributions, and autonomous agents.

The honest weaknesses

Where shielded pools struggle

Composability is hard. Once funds are inside a shield, interacting with the rest of DeFi means exiting and re-entering, which costs time, gas, and anonymity-set quality.

Anonymity-set quality is a function of pool activity. A pool with low usage offers weak privacy. A pool with one whale and many small users offers asymmetric privacy.

The legal narrative is harder. Pools have to actively distinguish themselves from sanctioned mixers. Some shielded-pool designs do this well with association sets, but the lift is real.

The liveness assumption: the recipient must be the one operating the shielded balance. That fits a wallet user. It fits a payroll recipient less well, an autonomous agent less well, and a “send a tip to a contributor I just met” workflow not at all.

Where stealth addresses struggle

Amounts are visible. A stealth payment hides who the recipient is, but the value transferred is on-chain in plain sight. For most payments, this is fine; for treasury operations where the amount itself is sensitive, it is not enough on its own.

The recipient has to scan announcements to find their money. Curvy and the EIP-5564 standard make this efficient and well-supported in clients, but it is a step that does not exist in a shielded balance.

Interactivity with the protocol contracts costs gas, though Curvy’s design keeps this minimal. The announcement is a single small write per payment.

When to use which

A few patterns show up consistently among teams using both designs:

Payroll and contributor payouts. Stealth addresses. The recipient is often offline, often unfamiliar with shielded-balance UX, and the goal is “their address shouldn’t be searchable,” not “the amount is a secret.” Curvy fits cleanly.

Treasury operations where amount is sensitive. Shielded pool. If a DAO is moving capital between strategies and the size itself is the secret, hiding the recipient is not enough – the value needs to be hidden too.

Vendor and merchant payments. Stealth addresses. The buyer wants to pay normally; the seller wants their address not to become a public payment ledger.

Internal DAO transfers between known parties. Often a shielded pool, because the parties are already known to each other but not to the public.

Agent-to-agent payments. Stealth addresses, almost always. Agents are always-online, always-funded systems whose main wallet must not be exposed. Shielded-pool UX assumes a human-in-the-loop session.

Cross-program privacy posture. Use both. A treasury can hold operating capital inside a shielded pool and pay vendors out of stealth addresses. A protocol can route subscription revenue through Curvy while running a shielded reserve.

Where Curvy fits in the broader stack

Curvy is one piece of on-chain privacy infrastructure. The framing where stealth addresses replace shielded pools, or vice versa, is not the right one. The honest read of the design space is that they cover different threat models and the surface area where they overlap is small.

If you are evaluating private payments and the question is “which design?”, the better question is usually “for which payment, and against which observer?” The answer often points to one design for some flows and the other for others.

For teams who want to integrate the stealth-address side, the Curvy SDK handles meta-address generation, sender-side derivation, recipient-side scanning, and the announcement flow. It runs on Ethereum, Solana, BSC, Base, Arbitrum, Polygon, Optimism, Linea, and Gnosis. Curvy is open source at github.com/0xCurvy.

For teams using shielded pools alongside Curvy, the protocol docs include integration notes for moving funds between a Curvy stealth flow and a shielded position when both are in use.

Frequently asked questions

Is Curvy a mixer?

No. Curvy is a privacy protocol. Funds are not pooled, and each payment is a direct transfer from sender to a fresh address controlled by the recipient. There is no commingling and no shared anonymity set. Curvy team does not touch the funds, they can either enter and pass through the protocol or, in case of a compliance check failure, be returned to the sender.

How is Curvy different from a shielded pool?

A shielded pool hides amounts and graph structure inside a zero-knowledge anonymity set, requiring users to deposit and later withdraw. Curvy hides the link between a payment and the recipient’s main wallet, with no pool to enter and no withdrawal step. The two designs solve different problems.

Are stealth addresses zero-knowledge?

Stealth-address derivation does not require zero-knowledge proofs. It is a key-derivation scheme. Some implementations layer ZK on top for additional properties, but the core primitive is simpler than a shielded pool.

Does using Curvy affect regulatory exposure?

Curvy does not commingle funds, which is the central regulatory concern with mixers. The protocol publishes a compliance toolkit that supports source-of-funds attestation and selective disclosure to a counterparty or auditor.

Can I use Curvy together with a shielded pool?

Yes. The two designs are complementary. A common pattern is to hold operating reserves inside a shielded pool and pay external counterparties via Curvy stealth addresses.

What does Curvy hide, and what does it not hide?

Curvy hides the connection between a recipient’s main wallet and the addresses where they receive payments. It does not hide the amount of any individual payment, the sender’s address, or the fact that an announcement was posted to the protocol.

Curvy is a privacy infrastructure for EVM-compatible blockchains. Curvy is open source and live at curvy.box.

Curvy Protocol is a privacy infrastructure for EVM-compatible blockchains. The shorter answer to “why does this exist” is that every previous approach to on-chain privacy treated it as a feature you opt into, when it actually needs to be a property of the system.

This post is the long version.

The problem the team kept running into

The first time it was obvious that on-chain privacy was broken was the moment a blockchain address became a public résumé. Pay an invoice from your hot wallet, and the recipient can click your address on a block explorer and see every position, every counterparty, every paycheck for the last year. They have not pried. The information is just there.

Multiply that by every salary, every supplier payment, every customer refund, every treasury operation, every recurring subscription. Public chains were supposed to be a neutral settlement infrastructure. Instead, they became the most powerful financial surveillance tool ever built, voluntarily shipped by the people using them.

The standard answers were not good enough.

Mixers worked, then they got sanctioned. They also concentrated risk: a user queued up with everyone else who happened to need privacy that week, and a withdrawal carried the reputation of every other deposit in the pool. That is a privacy product whose cost depended on strangers, which is a fragile place to stand.

Privacy chains worked too, but they sat off to the side. Using them required bridging in, transacting, and bridging out. Each crossing was a fingerprint. The privacy was real, but the user experience punished anyone who cared about it.

Per-transaction ring signatures and shielded transactions on alternative L1s were technically elegant and culturally isolated. The applications, the liquidity, the wallets, and the users were on Ethereum and its L2s. Privacy that requires a user to leave the room where everyone else is working is not the kind of privacy people will actually use.

What was missing was something that ran where activity already lived, did not require pooling, did not require a separate chain, and did not require the recipient to be online.

Why stealth addresses

Stealth addresses are not a new idea. The cryptography goes back more than a decade, and the canonical Ethereum framing has been on the research roadmap since 2023. The reason they had not become standard infrastructure was practical, not theoretical: building a clean SDK, getting the standards aligned (EIP-5564 for the address format, EIP-6538 for registries), supporting the major chains, and wiring up scanning so recipients could actually find their money – none of that existed yet as production-ready software.

The appeal of the design, once you sit with it, is that it does the minimum needed.

A recipient publishes one stealth meta-address. Senders derive a fresh, unlinkable destination from it for every payment. The transfer settles on the chain the sender already uses. There is no separate token, no shielded balance to manage, no bridge, no anonymity set to wait inside.

Privacy emerges from the address derivation itself, not from commingling funds with strangers. That is a smaller, cleaner property to defend, and a more honest claim to make to a user.

It also keeps a useful door open. The recipient holds the keys that let them prove provenance to a counterparty, a tax authority, or an auditor when they choose to. Selective disclosure is a feature of the math, not a bolted-on compliance layer. That matters a great deal to the kinds of teams who actually need privacy at scale – payroll, treasury, agent infrastructure – who would otherwise default to “off” because the legal team flagged it.

What we got wrong, and what we learned

The first version of Curvy was a hosted product. The bet was that users wanted a polished wallet experience. They did, and they didn’t. The wallet teams already had polish. What they did not have was a privacy primitive they could drop into their own product without rewriting their stack.

Curvy was rebuilt around the SDK. Same protocol, different shape. The integration target became a developer rather than an end user, and the people who care most about private payments — payroll tools, merchant gateways, agent platforms, DAO treasuries – could ship a stealth-address option to their users in days rather than building it from research papers.

The second thing that needed correcting was the place compliance occupied in the design. The real customers for private payments are not adversarial to regulators. They are companies, treasuries, and individuals who want privacy from each other and from the open internet, not from law enforcement. Once that was clear, the compliance toolkit got built alongside the privacy layer rather than after it. View keys. Source-of-funds attestation. Selective disclosure. The kind of features that let a CFO sign off.

Where this is going

Privacy on public chains will eventually look like TLS on the public internet. In 2010, encryption was a feature you opted into for sensitive sites. By 2018, it was the default and an unencrypted page was the exception. We are nowhere near that for blockchains today, but the trajectory is the same. The technology is here. The standards are here. The user demand is here, even if many users cannot articulate what they are missing until you show them their own address on a block explorer.

Curvy Protocol is one piece of that future. It is intentionally narrow: stealth addresses, on multiple chains, as default-on infrastructure, with a clean SDK and an honest compliance story. The reason it exists is the reason anyone builds infrastructure – someone has to. The math worked. The chains were ready. The user’s pain was concrete. The thing that did not exist was the protocol, the SDK, and the audited contracts that turn a research paper into something a builder can ship before lunch.

So Curvy was built.

If you are working on payroll, agent payments, merchant rails, treasury operations, or anything else where the recipient deserves not to have their entire financial life on display, the docs are here, the code is at github.com/0xCurvy, and the team is reachable through curvy.box.

Privacy should be the floor, not a feature. Curvy is built toward that.

Frequently asked questions

What is Curvy Protocol?

Curvy is privacy infrastructure for EVM-compatible blockchains. It uses stealth addresses to let payments settle on public chains without linking back to the recipient’s main wallet.

When was Curvy built?

Protocol research began in 2023, with the first production deployment shipping in 2024. The current SDK and multi-chain support shipped through 2025 and 2026.

What problem does Curvy solve?

Curvy gives recipients private addresses on public blockchains, so payments do not link back to a main wallet on a block explorer. The protocol works without bridges, pools, or a separate chain.

Why not use a mixer?

Mixers commingle funds and create regulatory and reputational risk that propagates to everyone in the pool. Curvy uses direct, single-use addresses derived per payment. There is no shared anonymity set, and the recipient retains the keys needed to prove provenance to an auditor or counterparty.

Why not use a separate privacy chain?

Privacy chains work, but they require users to leave the chain where their activity, liquidity, and counterparties already live. Curvy was built to work where users already are: on all major chains.

Curvy Protocol is a privacy infrastructure for EVM-compatible blockchains. Read more at curvy.box.