# Miloš Novitović - Building Privacy Protocols in Web3: Lessons from the Frontlines

- Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup)
- Date: 2025-10-07
- Duration: 17:33
- Watch: https://streameth.org/watch/yt-rkjMDikTA3k
- YouTube: https://www.youtube.com/watch?v=rkjMDikTA3k

## Description

Privacy in Web3 is both urgent and underserved. As adoption grows, more users and businesses are starting to recognise the risks of public-by-default infrastructure, from exposed balances to fully traceable transaction histories.

In this talk, we’ll go through hands-on lessons from building Curvy, a stealth address protocol for private and compliant blockchain transactions. We’ll explore real-world challenges across technology, product and go-to-market, including UX/security tradeoffs, compliance considerations, and ecosystem integration.

## Transcript

Even though there have been a lot of technical challenges, uh this won't be a technical talk and I think it's important to emphasize that this is going to be a talk for everyone told from the products builder perspective. Um obviously the main uh character of this story is going to be uh Kirby the protocol that we have been building during the last couple of uh years actually two years now. Um and in a nutshell uh it all started with a simple and what seemed as obvious idea but as soon as we deep dive into the development we figure out that what we initially imagined to build uh isn't that simple. Uh we felt stuck uh multiple times. However, we didn't stop. Uh we continued and today we have a production version of the application and real users. But you know let's start from from the beginning from the idea. Uh it's all started as I said around two two and a half years ago uh when Vitalik shared his now famous post about stealth addresses. Um and that's what got us motivated. But uh before we continue with our story uh let's just briefly cover the concept of stealth addresses. It's really simple and that's why it's also a beautiful concept. So you can imagine that you have a public ID username or for example in our case ENS name. So uh people that want to send funds to you privately can use that public username and each time they enter it they're going to get the different stealth address. They send funds to you, you receive them and if you receive funds from 10 people, all those funds, all those transaction will be sent to the different uh addresses and in the end of the day only you are the one who knows that all those funds belongs to you. Someone who is watching from side cannot recognize that all those transactional, all those assets are part of your portfolio. Uh so that's the the concept itself and uh we um in our company have an R&D department that's called 3327 and yeah this is the fun fact as most of the people from this region of eur Europe we were also inspired inspired by the Nicola Tesla and that's why we named our R&D department like this because 3327 was the number of room where Nicola Tesla spent his last 10 years of of his his life in New York hotel on my head. That's a fun fact. So at that point in time we already have been researching some researching some cryptography and um privacy tooling and when we saw the concept you know that post we deep dive into the uh researching the idea just to understand you know what is the current state of the stealth addresses and what are potential boundaries and what we might be able to improve and ideally build a product on top of that. Um at the end we didn't stop on one research on one idea. We built a couple of of we published a couple of research papers and couple of prototypes. Uh first one was related to analyzing the current state of the self address protocols and trying to figure out how we can improve it. Uh making it more efficient with some uh faster view scanning dual key infrastructure and etc. Then we move to making a postquantum uh resistance that self address protocol and um also we try to play with the multi cell address protocol but at the end of the day we were researching just to researching just to understand what are the limitations and you know where we can find the space for for improvement. Once we had all those prototypes, we moved to the uh product. We launched the uh protocol to the production uh and we wrapped it up in a web application which is basically a web wallet uh with a couple of other uh features. Um however that's was one of the first time when uh we realized that you know what we build isn't sufficient uh because um at that point we were able to enable users to receive funds privately via stealth addresses. But that's only the half of the problem. The other half is how to manage and send those funds from your stealth addresses uh to other wallets privately. And the stealth address infrastructure usually breaks privacy when it comes to managing and sending assets. For example, uh if you don't have a native gas on a stealth address, you need to fund that specific address with a native token. And if you fund multiple stealth addresses from the funding wallet, it's going to break privacy bits because you're going to link all those wallets with your funding wallet. Also, if you want to send more than what you have on a single stealth address, you have to merge assets from multiple addresses. And again, that's breaks privacy. So uh at that point we realized that we need something uh that uh we called ZK real air something that will help us aggregate transactions from multiple addresses and send them privately something that will help us to enable private swaps uh batching bridging and etc. Um however this was again a moment when new set of challenges uh arised. Uh first of one was ease of use. Um since sending transaction via re layer uh requires a couple of steps to happen under the hood and you have to abstract all those steps because users don't want to use a application that's going to look like a de dev tooling like like dev tool or some PhD uh project. Um so that was one problem. The second one uh was costs. Our initial estimate said that uh sending transaction via ZK relay are going to cost us and actually user 60 times more and we can agree that users do care about the privacy but they don't want to wait days or or pay hundreds uh for a transaction to be uh submitted. Uh and at that point in time we again felt a bit lost because we were trying to create a more efficient faster cheaper Delta protocol. We were trying to build a messaging layer on top of that to build the ZK real layer. We were basically trying to solve many different challenges within privacy in the web 3. Um and it led us to a lot of back and forths within our team. uh misalignment uh we frequently heard from our CTO and devs that what we imagine to develop isn't possible at least right now and we realized that we need to focus we need to narrow down the challenges that we are trying to solve within the web three privacy u niche we sat down and we created something that we called a product manifesto and that's something that uh it's basically a set of values that we choose to follow while building um and solving each of the challenge we have in front of ourselves. But it actually wasn't some kind of the buzz word like um you would initially thought. It's something that really helped us align internally and helped us prioritize initiative within different uh part of of the team. And what we came up with uh we together decided that we want to focus on building a solution for compliant private and fast crypto payments payments and uh while doing that we want to focus on usability, privacy, compliance, openness, security, speed and cost and it's a lot to focus on at the same time but still solving a privacy problems in web 3 is a complex task and let's just briefly cover each of these what this mean um in real world situation that we have in a day-to-day job. So when it comes to the usability um we want users to just define the end goal whether it's to send transaction privately or to receive funds privately. Everything else should be uh fixed and taken care of by by Kurvy. So we can say that curvy is intent based user defines send goals and curvy do everything else. Uh privacy this one is obviously really important. Uh and privacy it's not binary. It's not zero or one. There is multiple grades of privacy in between. Uh with curvy privacy privacy get is you know set by default. That means it's not going to go to the zero. But it's up to users to define the optimal level and actually the optimal balance of cost, speed and and and privacy. Maybe someone wants to have a faster transaction and with a low level of of privacy or someone else want to wait longer but to be sure that the privacy of their you know transaction and onchain activity is is is higher. um compliance. Um this is also something that was really important from us from day one because uh there were a lot of uh privacy solution that didn't made it because of the compliance. So we wanted to uh create a flexible infrastructure that can support use cases for the compliance and that's why from the day zero we choose to go with this dual key uh infrastructure where you have a private and public viewing and spending key and you can give your uh viewing key to someone who can have an overview of all the transactions you you you have but they don't have a custody of of Yeah. Um, openness. Uh, yeah. This one is simple. So, uh, even though we launch initially on on Ethereum and we are mostly focused on Ethereum, we are open to other ecosystems and, uh, it's reflecting also in our infrastructure. Uh, security, there are no compromises with with the security. Um, and in the end, speed and and costs. Um we agreed that uh users do care about the the privacy but they don't want to pay hundreds in dollars for for the transaction either to wait uh uh days. Um and um in a nutshell curvy is not a mixer. It's not a privacy pool. It's not just stealth address protocol. Uh Curvy is a modular priv privacy router. uh build with embedded uh compliance. Um and here are just you know a couple of of uh lessons that we covered during today's talk. You know something that we figured uh during the last year and a half up to two years. Um and uh yeah um I hope we're going to see each other next year as well. just to share what you know we did in the meantime, what went well and where we failed and what new lessons we we learned. So yeah, I was a bit faster and I guess than was supposed but we can move to the questions at least. Well, thank you mash for those real world uh experiences at going to privacy and thank you. Let's give you all a hand for Milash. [Applause] You went through the presentation quite fast. So, do we have any questions down here from the audience? No. And no here. So, I have one. So, I have a lot of issues getting my transactions into privacy. What do I do? Not all my transactions are private, especially on the chain where you see everything, right? How do I keep it more private then? >> Uh so uh there is a couple of option. So uh of course you can use a curvy as as an option but I wouldn't like to to cover that as as an option right now. Uh there is a multiple privacy pool solutions right now that exist that you can easily go through and uh protect your current portfolio with them. So I would say that's the easiest way if you want to use your current portfolio and let's call it protective uh from from onchain activity in you. Yeah, because of private I know every time I join a new project like new wallet just for this project just to hide everything and then you do the stupid mistake. You transfer into the same address that you put everything on exchange, right? And that wallet is like bubble map everything is there. So what what will Kirby do to when you're ready? I want to know you. >> Yeah, that's a great point. So uh even though we built a wallet, one more wallet that you might uh use uh we used it as a just a use case you know to present what can be built with the protocol. Our end goal is uh to offer other wallet solutions either dexis to use a curvy as a protocol you know to just integrate and try to protect their users transaction with our SDK and our infrastructure. So yeah, I do agree that we do not need yet another wallet where I'm going to move all my m my funds from Metam Mask or any other wallet that I'm you know used to. It's better to have a you know protocols that wallets that already exists can integrate with and protect and chill them. So to answer your question like soon you know our SDK will be ready. So we want to offer it to the other wallets u to integrate it and try to protect uh their users privacy by using our infrastructure. >> Yeah. Well, you always have the seed phrase you can move over without actually clearing the wallet. Would that work still with your protocol? >> Yes. >> That's wonderful. Just put in my seat phrase and I have all my wallets there. Perfect. So I'm wondering one thing especially what is coming up in 2027. The European Union is working on a law where all wallets have to be public. you have to actually claim that wallet. How is your protocol going to work with that? Especially when you to use your anything in Europe, they want this new law. >> Yeah, again that's a good question. Uh you came prepared. Um so um actually we are currently talking with a couple of potential partners that do care do care about regulation. So uh they can easily use that uh private uh viewing keys and share it with any regulator if they want. So any company that again do care about the regulation can utilize the curve infrastructure and build a solution that's at the same time private for their users. On the other hand has an optional transparency and and auto potential option for auditors to review it. Well, that's very nice to work it hand in hand by still being private but still have the option to hey okay here's the data we actually need. So I don't have any more questions we have anyone else ready with a question. Well Mil there we go. Thank you. >> Hi uh do you do KYC by yourself or uh you integrate other solutions? >> Uh we don't do it. uh we would expect from our partner who wants to you know use our protocol to you know choose KYC provider they want for example in the case for let's say some exchange want to use us they want to be regulated they can use the infrastructure as I said use those pending private p public keys but they would be the ones who put the KYC provider on the top of our protocol so it's flexible