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.