ZK Is Not Enough: Privacy Requires System (Re)Design

Transcript

Hello everyone. Welcome to presentation which was actually initially meant to be self-reflection for for our own curvy team. Just to go through what we went through during previous year, all the key decisions that we made. And today I wanted to bring that whole transparency to all of you here. I'll share the full story of thinking, planning, execution flow. And I try to pack everything up in 20 minutes. So we will have to run through few slides, but we can definitely stay after and and discuss if you're interested. The title itself was actually inspired by our innovation stack. You can replace ZK with any other technology of your choice

and the result would be the same because there is no one single holy grail that solves all the problems that we faced and that users are facing when using privacy products today. So we will try to go through through this journey together. For us everything started a bit more than 3 years ago. Most probably you remember this blog post from Vitalik describing stealth addresses. And this was the initial thing that actually triggered us and challenged us. Can we build a stealth address protocol which is Ethereum compatible, fast enough, private enough for for users and which can work on on today's Ethereum stack.

The result on the right is the first research paper that we wrote about that. It was I think 2 and 1/2 years ago. And then based on that research paper we started iterating. We challenged ourselves. Can we build a multi-sig version of it? Can we build a post-quantum resistant version of it? Can we incorporate in the existing cryptographic version some lessons learned from the post-quantum version? And also can we build the POC with with that cryptography? And the result was that stealth addresses, if if you look at the concept, are very good for for private receiving.

They can also have a very good user experience on the receiving side with ENS usernames. And on the other side, when you try spending or managing those funds, you face bunch of the challenges. And those are some of the challenges that we addressed immediately with the POC we built. First, how will you actually sponsor the gas to to to your users? How will you manage those funds and on on the other side also keep keep privacy? So, that pushed us further. And then we said, "Okay, we need to figure out what to do with that spending side, how to solve that problem of keeping privacy end-to-end when users are actually trying to to

aggregate their funds." That's how the ZK aggregator as part of our innovation stack was was born. So, the idea was, "Okay, users can receive funds privately through through stealth addresses which are all and through their usernames which are ENS compatible from from any wallet that supports ENS." Let's let's give them a chance to put all those funds into into into ZK aggregator and protect protect their privacy on the on the on the spending side.

What what worked well? Funds could move and we we managed to do that with the same cryptographic solution that that was initiated through through this research paper that I mentioned. But, we faced a significant user experience friction at that point. With that, we did a usability research and out of 78 people that went through for that research in different phases, only two of them were comfortable with shielding unshielding and knew on their own how to how to deal with these flows. Although we tried to to bundle bunch of the actions in the background, so users

keep keep using this our protocol in the same way they would use regular crypto transaction, it wasn't enough because people people had to to people had to to to understand what's under the hood and how this technology can be used and they saw some terms for the first time. Also, time locality was a big problem that that wasn't easy to solve because if you all your actions need to be manual when you are using the privacy privacy protocol, basically it means that it is it is much easier to make the correlation between between deposits and withdrawals and to see, okay, the

although we can we cannot see what happened in the privacy pool, you can see and make correlations who who was on the sending and receiving side from the privacy pool. And of course, cost of operations ZK cost is is much bigger from from the gas consumption, so we had to solve that as well. The next step for us was introducing Curv Portals. Curv Portals actually enable us to to to automate the whole shielding flow. So, when users receive money, there is zero action that is needed from from their side to put those those funds into the ZK aggregator. Also, through through that automation, we we managed to solve the time locality issue. So,

basically there is a higher time span between deposits and withdrawals, between the moment when you receive money and the moment when you actually try managing your funds. So, it is much harder to to to correlate that. And we also incorp- incorporated compliance came AML/KYT checks at the receiving side. So, basically, it is not possible to enter the the the ZK aggregator without uh going through through those checks. Uh we also made a decision to put the whole ZK aggregator at a single chain in order to optimize the the cost that I mentioned previously and in order to to make the the the privacy set uh

bigger from the very beginning. Uh what what worked well with Curv portals, the UX friction was solved. Uh we did the new round of of uh usability checks and it was much easier for for for users to to uh use the privacy protocol. The whole flow of activities looked pretty similar to them to what they are used to. Uh the as I mentioned, time locality uh problem was was addressed in this way and privacy set was concentrated and and bigger than fragmented around different chains. While on the other side, users could uh deposit and withdraw funds to to any supported chain

uh through LiFi integration. Uh what came as a challenge was the token mapping because, obviously, you know, some uh when you move funds across chains and when you want to automate those those actions, there are basically uh some activities uh some some tokens which are uh available on one chain and are not present on the other one. And uh again, people saw this as a very good privacy layer, but they asked us, "Okay, what can we do once we are inside the privacy uh pool inside the ZK aggregator and how do we add additional utility?"

So, that's how the uh we started thinking about private DeFi and also retail payments as as a use case. So, the idea was, "Okay, let's once when funds are in, once when funds are fully protected in the Zcash aggregator and no one externally can can see your balances, can see your activities, how we will actually protect how we will actually give you additional utility while also protect your privacy. And then we enable private swaps again through for life integration and also enable DeFi connector integrations through for wallet partnerships. Also, we managed to optimize the time for payment receipts, so this becomes more

suitable for POS retail retail use cases. Uh I managed what what we what we what we managed to do for for this step and then the new challenge appeared. We faced that there is a market that it isn't didn't exist a few months ago and that basically we we were not prepared for. Luckily, some some of the things were already there and that's the reason why we are ready to today announce the the launch of the Crops Cash. Crops Cash is basically a gentle payment workflow which gives you private and regulated payment workflows for your agents that

you can uh embed through through through any uh any any agent workflow that you already use and through for Curv MCP and agent skills enable your agents to to to privately transact on chain while also keeping the the control. Uh in the whole thought process we said, "Okay, this is a huge thing because today we are ready to to to put the completely new uh new new way of interacting interacting with Curv and on the other side having private payments and having regulated private payments is not

enough. There are a bunch of challenges which will come out of these use case, things that need to to to to be addressed. And in order to address them, we need strong partnerships. To name some of them, if we truly believe that B2B payment urgent payments will be presented in B2B payments, basically what we will be needed aside from the privacy side is the identity side. How can you actually prove that your agent represents really the the the the legal the legal company that it you it claims it represents. On the other side, how my agent can claim that it

really represents the company that it claims and how they can interact with each other while also keeping privacy and having that kind of that kind of payment workflow so other observers cannot see what we actually actually did. So, this is actually just the beginning. And as Steve Jobs said in one of his talks, you cannot connect the dots if you look forward, you can only connect them looking backward. So, the the the the goal for us at this point was to sit and to reflect on what we went through and how actually our innovation stack evolved over time and how it it changed over time and what are the challenges that we see today

as as as I mentioned and what the next steps might might be. Obviously, there are a bunch of examples when you are in in doubt and you are not sure how how to address these challenges. So, sometime during last summer, we sat down and we created something that we call Curv product manifest. And the whole industry is obviously changing pretty fast, but we need to be aware about what are the pillars which will actually shape our product and shape our decisions. And what are some things that we cannot negotiate about? And these pillars are what you can see at the top.

So, we said to ourself, "Okay, privacy and compliance need to go hand by hand." And there is no chance that we will actually make a compromise on one of these in a Curv protocol, but that is not enough. Obviously, that is what you see as as a partner starting to integrate with Curv, but also our goal is to make the usability flow even as I like to say, our parents can use it. Also, to make Curv open so partners can easily integrate with it. Obviously, security is important part when you're dealing with with financial rails. And of course, if you want to cover as many use cases in fintech as as we want to, then you need

to optimize the cost and optimize the speed as well. So, obviously, those challenges are not easy to to to to address. And obviously, you will need to make compromises from time to time. So, when we when when when we are at a specific crossroad, we need to come back and to see and say, "Okay, let's let's discuss how these how these decision will have an impact on our principles and how it will actually impact the the the product." Some takeaways from the previous months, as I mentioned, privacy doesn't go alone. And often, you need to rely on other partners who actually

solved some other challenges and some other parts that you face on on the way of building your innovation stack. A year ago, privacy wasn't that popular thing. No one wanted to touch it. Uh investors told us that it is too risky. Also, some partners told us that it is too risky to to to to do it. Obviously, around 6 months ago, things changed and uh we can see privacy as one of the keywords here uh at at the whole conference and the whole community uh that people are talking. And obviously, uh at the moment when some institutions started to join and enterprise company started to join the web free space, uh privacy started to be a a a specific

thing that uh it is it is mandatory and it is not uh optional anymore. Uh so, also another feedback that we got a year ago was that uh there are other products on the base on stealth addresses and we realized that we we made a mistake by trying to position us as uh stealth address protocol because we are not married to a specific uh technology or specific tech stack. We're actually resolving a problem and the problem is incorporated in the product manifest that I mentioned. So, we started iterating on that specific problem, addressing things one step at a time, not the specific approach.

Uh although like we couldn't have the same level of usability without stealth addresses or the stealth same level of usability without uh ZK, uh but none of these tech stacks individually is enough to to to address the product manifest in a way that I mentioned. Also, what is very important for us is to talk with the real people every day and with the users and to get their feedback on actually every step in order to understand, "Okay, we managed to resolve one thing, but what that uh solution brings as as a as a new uh new chain of problems?"

And that new chain of problems, solving them uh also creates the innovation stack I put here in a a book that uh I recommend and that was part partially inspiration for for for this talk, which is called the innovation stack. And obviously in a this environment that is changing so fast and that is pushing you, you need to accept and embrace the non-linear path that some things that you you managed to solve won't be a solution as you planned. Sometimes you will find dead ends, some sometimes you will find crossroads, but at the end of the day you need to understand that that building a product is is is

on that kind of a challenge and that kind of that kind of a journey. So for us, I hope that as as I as I mentioned, I wanted to bring this level of transparency and the presentation which was initially meant to be for for our team only. I hope that it was actually useful and that it brought some new fresh ideas to you. We are actively looking for wallets, networks, dApps and any web free product that want to bring end-to-end privacy to their users. And if you are among them, I would be happy to talk with you after this.

Thank you. Do we have some questions maybe? There is a question here. Thanks a lot. It's a It's a It's a amazing job. So, I'm wondering how do you realize that technology-wise? Because are you still using the ZK-based stack or you're using like MPC or other ways? Because how can you decouple like transactions uh and uh yeah. Yeah, great question. Uh

ZK-STARK is used and is also central part of of Curv uh yeah. Uh ZK aggregator is also what sits under the Curv portals. So, it was uh needed to have end-to-end privacy uh assured for for our users. Uh but it wasn't enough to solve the UX friction and it wasn't really suitable for the receiving side. So, we combine basically multiple approaches in order to have Curv as it is today and to to to Oh, sorry. To be able to to uh fulfill these pillars from the product manifest that I mentioned.

This is the docs. No doxing. So, I'm curious what you mentioned about the DeFi integrations. Um like say I Well, I checked the docs and it I only saw uh stuff about swaps. So, when you mentioned that you can interact with like other DeFi protocols, if I were a DeFi like say I run a DeFi protocol, would there be a way for users of Curv who have shielded funds to interact with that DeFi protocol without unshielding them or how would that work? Great question. Yeah, the flow would be actually look in the background that you unshield the the position that you need the the uh funds that you need in order to take the specific position and then funds

would be automatically shielded back into the uh privacy pool after you finish with that. So, you can imagine it being as a temporary connection uh which would come with the wallet through through through the wallet experience. Sorry, and then would you need to like do you guys need to approve the DeFi protocols that are interacting or that are doing these interactions or >> in this case, no. No, in this case, it's at the wallet level. So, wallet incorporates Curv. You don't even to be aware of uh Curv. The The experience is like private experience inside the wallet that you're used to.

Thanks a lot. Thank you everyone. >> audience and I encourage you to continue the discussion outside after if you want. Thank you. Thanks.