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.