Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Brian Weickmann, co-founder of ZKP2P. ZKP2P is a trustless fiat-to-crypto P2P on-ramp powered by ZK Proofs. On this episode, Brian explains how ZKP2P leverages ZK Proofs to translate DKIM signatures in Venmo and HDFC transaction confirmation emails to unlock on-chain assets like ETH and USDC. ZKP2P lets depositors charge a fee, creating a financial incentive to draw liquidity into the protocol. It was great learning more about ZKP2P from Brian, as this is one of the most exciting and tangible applications of ZK that's live today. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Brian, thanks so much for joining me on Web3 Galaxy Brain to talk about ZKP2P. How's it going today?

Brian Weickmann: Good, good. How are you doing?

Nicholas: I'm doing great. So ZKP2P is like a really exciting project that a lot of people, I mean, not everybody knows about it yet, but everybody who does is pretty excited. So what's the problem that ZKP2P, ZKP2P is solving?

Brian Weickmann: We see this as kind of helping solve, you know, there's been this persistent kind of like off, on and off ramp problem. The UX really is kind of sucks. You usually have to go through some sort of centralized exchange, or you have to, you know, pay some exorbitant fees to get money actually directly onto a blockchain. And some people are fine with kind of like the centralized exchange flow. I think like if you're an American or you're a Coinbase user, you actually pretty often find that that's a pretty annoying flow to take because, you know, you send money into your Coinbase account and then you have to wait five, six days for it to actually, you know, be movable on chain. So there's all these kind of like frictions of on and off ramping. And then obviously on top of that, there's kind of like some of these other things around just even the pure ability to on ramp, like having access to platforms that let you on ramp. And so ZKP2P is really cool. It's kind of inspired, like came from, was inspired by solving that problem, really. Like, how can we create a like robust and indestructible type of on ramp? And so that's, yeah, that's kind of how we came here. And it's definitely inspired a bit by some of one of our team members frustrations with things like Binance P2P as well. Having to deal with like dispute resolution and things like that. Like there is like the dispute resolution is done by the code, right?

Nicholas: So, yeah, I guess, I guess if you can solve. This problem, the Fiat on ramping and off ramping to problem in a way that's secure and cryptographic, then it can be global and permissionless also. So you don't have like, as you mentioned, like there's. maybe if you're in the States, it's not so difficult. But if you're in some part of the world that's served by less reputable companies or with higher rates, it's would be hugely advantageous. And it's maybe not something that's so visible on like English speaking, Western centric Twitter.

Brian Weickmann: Yeah. Well, and, you know, ultimately there's a lot of. Use for this beyond just like people wanting to get crypto on chains, they can buy like their favorite token or whatever, like hidden in some of this tech is potentially the ability to like really cheap, cheaply and efficiently remit across borders. Right. Like think of how, you know, kind of localized a lot of these payment networks are. So when I, you know, have Venmo, when I go to some foreign country, I can't really pay using my Venmo. Right. But essentially what we're able to do. Here is start kind of linking a lot of these payment networks together so I could pay on Venmo and my friend could receive their money. And we just launched UPI integration this week. They could receive the money in their Indian bank account. Right. So there's like some things like that. There's also just people who want access to US dollars. And instead of, you know, wanting to having to meet up with somebody to get US dollars or those sorts of things. You can, in theory, just use this and you can trade your local currency for US dollars at, we think, pretty competitive rates.

Nicholas: Yeah. So how did the project come together in the first place? Because I know you've got a pretty stacked team of developers. How did you all come together?

Brian Weickmann: Yeah. So we've actually worked together for a long time. So there's four of us. All four of us work together at a project called Set Protocol. It was like an index fund type project on top of Ethereum. Built all sorts of like structured products. last bull market. There's Alex. Alex was actually one of the founders of Set. I was the first employee in like June of 2018. And then Richard, who's also on our team, was the second employee in like September or something in 2018. And then Sachin joined us in 2021. And so that's kind of how the four of us all came together. And then, yeah, I mean, we all kind of sparked this. This mutual interest in the potential of zero-knowledge proofs, kind of around the beginning of 2023, all of us kind of really started deep-diving on it because we just, I don't know, looking into and learning about zero-knowledge proofs was kind of, in my opinion, one of those equivalent aha moments to kind of like Ethereum 2017 or something like that, right? You can start to see, like, all the things that are potentially achievable with zero-knowledge proofs. And so we were kind of going back and forth. We were going to conferences. And we came up with the idea with this at a Stark, was it Starkware Sessions in Tel Aviv? And then we actually hacked on it in ZKHack in Lisbon. And then from there, we just, you know, decided there's something here. We want to continue to pursue it. We were fortunate enough that the Ethereum Foundation and the Privacy and Scaling Exploration Group felt similarly. And so they, you know, were kind of able to fund, give us a grant to fund some of the work for the. Kind of last year and I think, you know, hopefully a little bit going forward as well. And so, yeah, that's kind of how we how we found ourselves here was just really four guys hacking on something, thinking, like trying to build something interesting. And yeah, I mean, I think so far it's continued to be very fruitful and very fun.

Nicholas: Awesome. So I want to get into, like, all the technical details of how it actually works. But I think first, just for people who haven't seen the site, who aren't that familiar from a UX perspective. If I'm a user, I want to on-ramp into, I guess, USDC on ETH. What would the most common path be? Maybe you could walk me through. what do I have to do just as a regular user who doesn't really understand the deep internals of it yet.

Brian Weickmann: So via ZKP2P?

Nicholas: Yeah, that's right. Yeah.

Brian Weickmann: So, yeah, well, first of all, like we have one deploy right now and that deploy is on base. So the entire flow. So I'll take, you know, go all the way to if you want to get to mainnet if you want.

Nicholas: Or no, let's do base.

Brian Weickmann: Let's do base. All right. Sure. So for base, it's the first thing you need to do is kind of we make you prove that you actually have an account with the payment network that you're trying to on-ramp with. Right. So what you have to do is go to our website. And when you register, you're actually submitting a prior email that you got from Venmo. And so when you submit that email, we're then able to generate a proof that says, like, OK. This is an email that was sent from Venmo, we're able to extract, like, your user ID, then we hash that and then we essentially submit, then you submit that on chain and that kind of creates your account is one way to think about it. And so now we've verified, like, OK, this is a Venmo user, we can let them kind of do all the actions that are available to Venmo users in our system. And then what you need to do is you actually need to go and escrow funds.

Nicholas: So you essentially write, like, s-stores and stuff like that. Are the hash of the user ID derived from the email that they submit?

Brian Weickmann: Yep, exactly. We know this is a hash of their Venmo ID because they've been running it through our zero-knowledge circuits, which prove the computation and et cetera, et cetera. I'm sure we'll talk a little bit more about that.

Nicholas: Yeah, we'll get to it.

Brian Weickmann: And then so then next is we're essentially just kind of like a fancy escrow agent, almost, but peer-to-peer, like, and I shouldn't even say we, right? Like, it's just the smart contract. We don't, we don't do, we're not really doing it. We're not doing anything in the middle there. The, so the user then goes and says, like, I want to on-ramp, like, $100, right? So you go and you submit a, what we call an intent to pay somebody off-chain $100. And so what that does is that locks that $100 for you. So that if some user were to come directly after you and take that $100, you're not, you don't actually, like, send $100 to your counterparty and then the money is not there on-chain. Right? For you when you actually, like, want to unlock it. And so then you go, you submit, once you've, you know, signaled intent, you know, set those funds aside for yourself. Then you send a transaction via Venmo or whichever payment network. From there, you'll receive a confirmation email, similar to registration. You then take that confirmation email, run it through one of our circuits. That generates like a proof that you, you know, did the payment. We extract things like the amount, the time stamp, obviously who you sent it to, to make sure you're sending it to the right person. And then you use that proof to unlock those funds that were set aside for you on-chain. And so that's kind of the end-to-end. And then you would, at that point, have $100 on base or $100 USDC on base. The, you know, right now, the users have to kind of submit all those transactions themselves. So at the moment, you actually have to have ETH on base. Well, in the next, like, 7 to 10 days, depending when we're able to completely nail it down, we're actually adding a completely, like, gasless and walletless flow. So you don't even, you don't have to have any ETH or anything in your account. We can just get you directly on-chain. And then with that, we can also start doing things like, since it will be with 4337, 4337 wallet, we can then send a BIRDS transaction, for example. So you could on-ramp and bridge. So you could on-ramp and bridge to Solana or wherever you want within one transaction.

Nicholas: Very cool. And just to finish up on the, like, complete user perspective on that, this developments that are coming in the next couple of weeks are the, is the idea that this will be in its own app or it'll be a dApp that you connect to with an existing wallet? Yeah.

Brian Weickmann: So it's, it's, it would be, especially in our, in our current dApp. Yeah. So it's like a, it's a new feature we'll be adding to the dApp to kind of make it a lot more seamless. And kind of really do that zero to one on-ramping, right? Right now you kind of, like I said, you'd need to have funds on-chain. Now we can do it where you don't have to ever have any funds, like any new crypto user in theory to come do this and immediately get money on-chain or quickly get money on-chain.

Nicholas: Okay, very cool. So yeah, so let's dive into how it actually works in detail. I know there's a lot of interesting stuff going on under the hood. And I guess in the example that you just gave, we're also kind of assuming that there's already somebody who's put some. Ether, USDC in escrow on the other side of the transaction that's waiting for the Venmo to come in. So, I mean, one thing that maybe do you want to, is there a way that you like to run through it chronologically or should I just ask questions? I know like domain key identified. Yeah. Yeah. So like DKIM, like domain key identified mail is an important ingredient in being able to, I guess, know for sure that someone has the account that they claim. How does it work? What are DKIM signatures and how do they play a role? Yeah.

Brian Weickmann: So DKIM signatures are like the way to think about them is it's the signature over an email that lets like your email client know that, you know, it's coming from a valid source. So there's a registry of all the DKIM identifiers or public keys. And you can always check your email against that registry to make sure it's coming from the server that it says it does. Right.

Nicholas: So that would be like Venmo.com.

Brian Weickmann: Right. Exactly. So for Venmo, it's just Venmo.com. And so this is, yeah, obviously kind of there as like an anti-fraud type protection thing as well. But we are able to leverage, I mean, zero knowledge. peers can essentially leverage any signed data. Signature is essentially an attestation that something's true. So in this case, Venmo is attesting that the email came from their site. And obviously there's information in that email that they're also attesting to.

Nicholas: So basically we're relying on Venmo's attestation to the existence of the account. What information matters from the email? It's just the account name or something else?

Brian Weickmann: No, I mean, well, so I guess it depends on the action. So if you're registering, we are mainly just pulling out the, I mean, we're pulling out a couple of things. We obviously need to pull out like the public key. From that email so that we can make sure it matches the expectation. But the main like data point we're pulling out is that is the hash of that user ID. So that's for registration. But then for kind of the on-ramp portion there, we need a bit more information, right? To make sure that you're not like, you know, reusing an email or doing not even or potentially like sending funds to a friend. But saying it's, you know, it was legit. You know, so you sent it to the right counterparty or whatnot. So that's where we need to check like who you sent it to, the amount that you sent. We also like nullify all emails. So if you can't like reuse an email over again. So those are the kind of things that we're pulling out on the send. And we use like a regex type thing to do that.

Nicholas: So essentially you use something like Venmo or the Indian bank that you're working with or any potential other service. You trust that their DKIM signatures and that the emails that they're sending out to users are accurate. But how is it possible that you know that a user is not bringing an email like an email belonging to a different user that's not them? How are you able to confirm that they are the account holder and not just that they have access to a single email from Venmo, for example?

Brian Weickmann: Yeah, I mean, I think that's one of the one of those nuances of this is it's proving that you have access to an email. That you have, you know, so in this case, yeah, there is a certain amount of like like you're you have to. your email is essentially kind of critical for the infrastructure in this in this whole thing. Right. So, yeah, if if your email were to get to get hacked, potentially someone could pose as you. I think like the most they could really do is register under your name. Certainly they wouldn't be able to. Like execute any Venmo transactions on your behalf. Right. And if they're really benevolent, they register under your name and deposit money to be off ramped. And then people just will send you money for free. But that wouldn't be what happened.

Nicholas: So when once I'm registered with an email from Venmo, for example, the subsequent emails are required to confirm that I've made transactions. Like is Venmo sending an email for every single like, for example, sending. Fiat to another P2P participant. That email also is used in the computations.

Brian Weickmann: Yeah. So there's registrations a one time thing. And that's we can kind of take any old, you know, any old email and be like, OK, we're using this to just validate that you have an account. But then, like for any subsequent transaction, so any on ramping transaction, we do need an email to say to like a confirmation email. To know that you. Completed the transaction off chain in order for you to get the funds on chain. So for every like on ramping transaction, you will need to provide the confirmation email of that transaction.

Nicholas: Got it. So Venmo becomes kind of like. it almost feels like a centralized signer that we agree to believe in something like that.

Brian Weickmann: Yeah. I mean, it's like a if you really want to kind of put crypto terminology on it, it's like a another L2 or L3. And we're just validating the state. That L2 or L3. Right. Now, you know, obviously, we don't have direct access to their ledger. And so the way we validate that is via these emails. So we're kind of bridging the Web2 side chain to Web3.

Nicholas: So so once I've registered, I guess there's two actions I could be interested in either on ramping or off ramping. Yep. And so what's the next step? So once I'm registered, where do I go from there? Maybe where does ZK Snarks come into the picture? Yeah.

Brian Weickmann: So as far as like, well, I'll touch on off ramping real quickly because that is like one side of the component that the system haven't really talked about that much. So off rampers are essentially passive participants in the way our system is designed. So you are depositing funds and it's these on rampers that are coming and escrowing those funds, submitting like sending transaction off chain and unlocking those funds for themselves. Right. So the depositor, all they're really doing is they're just depositing those funds into our smart contract. And then like over time, they'll get, you know, those funds will be like kind of passively off ramp.

Nicholas: Right. So I just I register with my Venmo account. I put some USDC into the smart contracts. And then over time, it's just being eaten up by people who are on ramping and sending me Venmo transactions to compensate for the USDC they're taking.

Brian Weickmann: Exactly. And, you know, we definitely want to obviously on ramp. Our focus so far has been a lot more on this on ramping. Side of things. But certainly we would love to also get like a fast off ramp as well. Right now, like I said, it's like a passive, passive activity. We'd love to get it to a point where it's also that can also be fast. Obviously, doing that then opens up interesting things with like merchants and things like that, too, potentially.

Nicholas: Is that just a benevolent activity at this point?

Brian Weickmann: Off ramping? Well, no. So you can set your. you can set a rate. So right now, I don't know what the current liquidity looks like. But, you know. You can set and you people are setting your from like 40 basis points to, you know, one percent essentially spread to to facilitate on and off ramps. Yeah. So the way everything is set up is like if you really want to offer it in theory, you could pay people to take your liquidity off chain. Right. So instead of capturing one percent, maybe you pay one percent. And now there's somebody like, oh, cool. I get paid one percent on ramp money. I'll do that. Right. So this is. it is a fully kind of. Like open peer to peer market. Like, however, you know, whatever your direction or the intensity of your interest to move one way or the other. Can you can express that via the.

Nicholas: And I guess the there's like events that are emitted when you do the depositing. that could be queried and like. essentially it's an on chain order book for on and off ramping. That could be.

Brian Weickmann: Yeah.

Nicholas: Bots could be servicing for sure.

Brian Weickmann: For sure. Yeah. You can easily build an order book. You know, there's certainly. I think at some point we would love to move more of that off chain. But at least for kind of the state we're in right now, because base is fairly cheap, it's we're okay kind of having that on chain. But yeah.

Nicholas: Cool. So I asked this question about ZK Snarks, but really it's not a separate step. You need it even for the registration piece. You need the ZK Snarks, right? Yeah. For people who don't know what ZK Snarks are, can you give like a high level on what they do, what capabilities they enable and who the. Parties are in a snark. Yeah.

Brian Weickmann: So I like to think of ZK Snarks as well. Not I like to think of people. think of it as just like it's the ability to prove any computation was run to like an exact specification. Right. So you can take some like inputs, put it into this black box, get some outputs. But you know that like this black box of the ZK circuit. The. The code that was. Expected to be run was run correctly. And then that has this like second property of being very easy to verify. Right. So one way to think about is you have a ZK. Snarks are actually like kind of expensive to create computationally. But you can think like you can have a supercomputer running all sorts of calculations for like a week. Right. Within the ZK Snark. And then you can submit. You could submit the outputs of. Of all those calculations to a smart contract on chain. It would be verified in like a second. So as this property is like very you can do any sort of arbitrary logic and then verify it very, very quickly. And so this is. this is nice for us because it allows us to say like, hey, you sent us this email. We put it into the zero dollar circuit and then the zero dollar circuit. We were able to validate the signature of the email. And then we were able to prove or able to like pull out different pieces of information from the email. And, you know, once from the output of that zero dollar circuit that the code is running. specification. Right. Because if somebody were to create a zero dollar proof using, say, like a fake email or something like that, or were to just try to submit a bunch of random numbers to validate the proof. It would air out and say, oh, this is an invalid proof. This was not run over the circuit that the user is claiming it was running. Does that make sense?

Nicholas: Yeah, it does make sense. So basically the burden is on the prover, like the party who's bringing the email. or maybe actually where does the computation actually happen for generating the snark? Yeah.

Brian Weickmann: So that computation that can we actually offer two options. So you can generate these things in like locally in browser. So we do offer that. It is quite. A bit slower because these are like very computationally intense, intensive proofs to create.

Nicholas: How slow are we talking?

Brian Weickmann: That's that'll be like 10 to 15 minutes, whereas you can also optionally send it. Use our remote prover. And that's about like 30 to 40 seconds to generate that proof.

Nicholas: As a user, I suppose I'm putting trust in your infrastructure if I do that. Although you can verify that. That it was done correctly, cheaply. So the client can verify still.

Brian Weickmann: Right. Exactly. You don't have to. You don't have to trust that we're running everything correctly because if we weren't, it would like the transaction when you went to submit it would revert. Right. There is obviously some trust around like, OK, you are sending an email to a remote server. But. Yeah. There's no like. We can't. We can't scam you on that by generating the proofs because then it just like wouldn't validate on chain.

Nicholas: Right. So the same mechanism that will be used to ultimately validate the information can be used to verify that the like speed up in doing cloud compute instead of local compute is legitimate. So you can automate some things or do them in the cloud and it doesn't introduce. at least the client can have the same guarantees that the their counterparty will ultimately have.

Brian Weickmann: Right. And that's like. that's the beauty and kind of like the promise of zero knowledge starts. Right. Is right. now they're computationally intensive. But as they get like as a computation computational abilities improve. But be as like. there's a ton of money pouring into researching zero knowledge proofs. A lot of that because of some of the applications, the actors, cryptocurrencies and blockchains. So we're seeing definitely improvements in the speed of some of these algorithms as well. And I think like over time, you'll start to see more and more of this stuff being able to be done locally on your computer. And in doing that now opens up like a whole different interesting privacy realm. You know, instead of validating emails, let's say validate my credit score. Well, I don't have to send all this information to somebody remotely. that gets stored on a server and like a database. Right. So they're running all the calculations on a remote server theory. You can do it locally and they can know. they know that you have run the computations correctly. So now they can trust the output of their credit score algorithm without ever needing your private data in their hands. Right. So that's kind of like really. the big promise here is like provable computation.

Nicholas: It opens over unrevealed data.

Brian Weickmann: Right. Unrevealed. Yeah. You can kind of keep all your data locally. Just send the outputs, you know, to wherever you need to send them. And they can then quickly validate like, OK, yeah, this was run to our specification.

Nicholas: It is a little mind bending to me still. Maybe if you haven't played with it personally, it's hard to fully grasp how it's possible to be sure that, for example, like the example you gave about credit scores. How can you know that the credit scores are accurate without having them revealed? But I suppose that is the nature of the technology.

Brian Weickmann: Yeah, it is. Like, I don't know. I feel like when we were first getting into it, just like moon math. Like if you ask me too much about them, I also don't write our circuits. I'm more on the smart contract side. But the math is like, you know, it's all sort of like abstract kind of abstract stuff going on there. That's a little can get a little about my head at times. But yeah, it is. It's it's pretty incredible technology. It's you know, it's one of those things that kind of broadens the really broadens what's available to us from like a decentralized stack. If you think of blockchains, it's kind of like a decentralized database. And we started like hooking on all sorts of business logic to it, which is like a theory and all this like smart contract business logic. Well, in theory, you could remove all of a lot of that business logic. Right. You could just make it basic. Like, OK, here's how you like add, remove, like update state. And a lot of this more, you know, business or back end logic could live in zero knowledge circuits. that you're then just like proving, you know, proving that you ran the code, as you said, to to the blockchain just over time.

Nicholas: Right. Doing just a lot less execution on chain and instead doing it off chain, just proving it.

Brian Weickmann: Yeah, right. Exactly. And that's why it's also seen as like a scaling technology. Because now you're doing all of this computation off chain and then just like very quickly and succinctly proving it on chain.

Nicholas: So we talked about these two roles. There's like the prover who is able to prove to a verifier that a statement is true without revealing too much about what they. I guess the computation itself is known, but the data that was computed upon is not known. So how do in the? is that more or less?

Brian Weickmann: I mean, there are some like points. You know, some interesting people. So again, if you had to do a personalization of the inputs that you, you do pass in, obviously those are those inputs or things that should be like, you know, you're okay with the public seeing. so not there's like. there's public and private inputs in the circuit. It's not all necessarily private. But the thing you would design the circuit in such a way that like the sensitive information is is inputted, you know, as a private input, like, for example, the email. We're not having you like post the entire email on chain for the next five years. validate you know like that that is a private input to our circuits. uh but there's like certain like the you would may pass in the your like the hash of your venmo id that you would pass in though as like a public circuit or as a public input. right because then you're like the the code you know executes it like pulls out whatever the the the venmo hash is and i can see like okay they do match it does make sense.

Nicholas: you mentioned also that regex is used in the process. how does that fit in?

Brian Weickmann: yeah so if you think of what like a raw email is so it's just essentially a big html uh file uh. and so what we're doing is we're we've identified certain parts within the email uh that hold that valuable information and then we're going and looking for those parts and just uh removing it or not removing it but grabbing it via regex okay.

Nicholas: so simple simple thing but trustworthy once you know that the dkim is correct

Brian Weickmann: right and there's like certainly writing uh zero knowledge circuits is not easy at this point like there's yeah i mean the the the language is is a lot of languages are pretty difficult especially you know we use sercom way to think about sercom is it's like literally wiring circuits like gates together in a circuit. so it's it's not necessarily like the most intuitive language to do. but at the same time we aren't doing anything that is like wild. you know we're validating signatures and doing a regex. uh and maybe for now that's really kind of pushes the the bounds of what can really be done with zk. because all these things that you you do all these different functions that you're running in your circuit increase the cost of computing the circuit right. so you start doing way too much stuff as many times as you can and so it may take two minutes three minutes to to do the proof remotely and then that kind of is a breakdown in the user experience right. so at this point there isn't because of some of the computational complexities. you know we can't really do it like a ton um but you know we can still do a lot with just some of these basic building blocks like regex and signature validation.

Nicholas: and also it's like an application that's here and now it's it's live right.

Brian Weickmann: Yeah, yeah. There's definitely been some zero-knowledge apps before us. I think I'm optimistic that we can be one of the first mainstream ones. That's certainly our goal. We think that this is a problem built to be solved by ZK. And it's a problem that a lot of people have in the cryptocurrency space. It's just getting money on-chain. And so we think our unique solution, ZK, provides an interesting opportunity to be one of those first dApps, really. Because most of the usage in this space... At least to this point, has been focused on L2s and scaling and things like that. There's definitely been a lot of great work done trying to play with things like privacy and stuff like that. But I'm certainly optimistic we can be the first one to break through and have a lot of people really using zero-knowledge proofs.

Nicholas: Yeah, absolutely. It's super practical. So... So, I know in some of the tech talks that the team has given, you discussed Halo versus Surcom. Maybe that's not your area of expertise, but I don't know if there's any insight you can give into why you ended up going with Surcom.

Brian Weickmann: Yeah, I mean, I think a lot of the decision around Surcom was... I think most of that was driven by some of our dependencies. So, I definitely want to give a shout-out to the ZK email team. So, this is another team within the privacy and scaling community. Privacy, scaling, and explorations group at the Ethereum Foundation. So, we're built on top of kind of their SDK, which is a general SDK for parsing emails in a zero-knowledge friendly manner, right?

Nicholas: And what was their reasoning for doing that as a fundamental SDK? What was the project? Like, what does their email product provide?

Brian Weickmann: Yeah, so they're very much more looking at it as like kind of an infrastructure piece. They have done some stuff with like an email wallet, too, which is pretty cool. But I think their approach has definitely been more on like the. how do we make emails, like... Because it's one of those common pieces of signed data, right? Every email you receive is signed. And if you look at zero-knowledge proofs as a way to take signed Web2 data and be able to trustlessly bring it on-chain, like, that's actually a huge potential primitive available. Another example of primitive, too, is actually like TLS encryption. That's essentially how your website or your browser talks to a remote server. And if we can, you know, potentially be able to like validate those sorts of interactions as well, that actually opens up a lot of the design space, too. So there's all these kind of like signed primitives that we can potentially, you know, use in facilitating on-ramps or, you know, and beyond our products that people broadly will be able to use within the crypto ecosystem and even just data, you know, kind of Web2. This is a tech that does not discriminate. I think it will have huge impacts on Web2.

Nicholas: Yeah, it's cool to think about the, I mean, you've come up with a very smart application for using the email verification to sort of bring some of the Web2 identity stuff on-chain without requiring a separate KYC step. You just run with whatever Venmo believes is good enough. And if the counterparties believe in it, then it's fine. I guess, is there, what do you imagine TLS could be used for? What are some hypothetical applications of that?

Brian Weickmann: I mean, I think. The main thing that is, it's just like access more than anything else. Right now, like, you know, we've spent a lot of time trying to integrate other payment providers. Not everybody, like emails are very inconsistent, right? Some payment providers will send you a confirmation email, but they really don't have much information in there or, you know, that we can actually use. Like there's been multiple providers we've wanted to integrate and they just don't have the data in it. So we've been trying to get, like, a data rich enough email to make it feasible for us to safely do it. Right. Like maybe it's missing a critical component, like the ID of your counterparty or something like that. Then it's like, well, we don't have that idea of your counterparty. We can't know that you weren't just sending it to your buddy. and now that like, he's going to send you the money back and I've doubled up your funds or whatever. Right. And so TLS gives us something that's probably a little bit more, a little bit more stable. It's a little bit more standardized and also it's just another tool in the tool belt, right? So instead of relying on the payment provider to providing like data rich confirmation emails, like, oh, well, there's going to be a bunch of data being sent back and forth from the browser and their server. And so we can kind of help, you know, we can sit there and validate and verify some of that data and use that as a way to facilitate on-ramp transactions.

Nicholas: And on the Halo versus Surcom stuff, I don't know if we rounded that out, but why was it that you ended up choosing Surcom? Yeah.

Brian Weickmann: So a lot of it was kind of this, uh, dependency, uh, you know, that, right. That like there's, there's Surcom library was the one that was just the most, yeah, that, that, that was one that was ready. Uh, I will say though, like we are looking into, we would love to at some point, uh, use Halo, uh, Halo 2. I know what Axiom just released, uh, I believe a universal verifier for Halo 2, um, which is great. You know, one, one of the kind of pains with using, uh, Surcom is we have to do a trusted setup ceremony for every, every circuit that we create. Halo 2 would not require that. And that's based because of kind of like the different ZK backends that are being used there. Some of them require trusted setups per circuit and others of them. You. Run one trusted setup for this like global verifier, which is what, um, Axiom launched and all, all circuits can then be verified against that, that kind of like global verifier. Um, so yeah, I think over the longterm we'll, we'll definitely, I believe trend towards Halo 2, um, operationally, it's just makes a bit more sense for us. Um, but for the moment, kind of the, the packages that were available. To us, uh, made sense to stick with Surcom. That's also like, I think internally we felt a little more comfortable with Surcom too. Um, just cause that's kind of what we all started writing some circuits with. Um, I know Richard and Sachin, there are two kind of circuits guys, uh, have gotten pretty familiar and pretty comfortable with Halo 2 as well. But yeah, that's kind of a lot of it. There's, there wasn't any like necessarily, uh, you know. We think one is better than the other. It was, it was definitely driven more by kind of what was available to us at the moment. Yeah.

Nicholas: Yeah. And there's a great talk at the ZK summit number 10, I think, uh, that I'll link in the show notes that people can check out with, uh, your teammates give more, more details on the comparisons and stuff. Um, so once the proof is generated by either the client itself or the ZKP2P infrastructure in the cloud that the client can verify, it's conveyed on chain in the deposit or, uh, uh, request transaction or how does it work? What gets started on chain? Yeah.

Brian Weickmann: So basically you've registered, right? Now you've signaled your intent. So you've kind of said like, okay, for the next X amount of time, this money is escrowed for me. Right. And then you send the payment off chain, you generate the proof. And then this is when you call it, we call it on ramp appropriately named. Uh, and you just submit your, the, the proof we extract, you know, the proof is going to be sent to the client. It's going to output kind of all the different pieces of data that we need. Uh, and then we validate that, you know, you've sent it to the right person to write them out, all those sorts of things. And then that's how the funds are unlocked for you. So that, that proof is essentially, you know, if you were to look at it, it's just, it's kind of just gibberish. Um, it's a bunch of, it's like, like four arrays of random numbers and hashes, but it outputs and it does, it does mean something. They're not actually random, but they're not, they're not actually random, even though, I guess that's kind of the whole point, right? If it wasn't random, then you could probably, you know.

Nicholas: So in some way, the, is it fair to think that the ZK snark element here is allowing you to do DKIM verification, signature verification, uh, on chain in a way that's gas efficient and also protects the privacy? If not having the users expose the emails that they're sending or receiving, or even their Venmo account names, like you get both the privacy piece and you're able to do that signature verification, which at least from reading your docs, it seemed like DKIM signature verification in solidity would probably not be feasible, but via the ZK route, it is something that it's, it's tractable for you.

Brian Weickmann: Right. Yeah. I mean, that's, that's another great point actually, is that not all like signature verification and, and, you know, hashing. Hashing functions and, and signature verification, not all of that is, is equal, right? So there's certain curves that Ethereum works really nicely with, but there's a whole host of kind of like cryptographic or yeah, like signature schemes and hashing schemes that Ethereum doesn't work very well with.

Nicholas: They're just not available as opcodes or pre-compiles, I guess, essentially.

Brian Weickmann: Yeah, exactly. There's, there's no pre-compile. So you're actually would have to go in there and implement, you know, in solidity. Right. The signature verification, which would be very gas intensive because you'd be doing a ton of math, right? And so we're able to do all that computation off chain and then submit the proof, like, Hey, this signature type that you can't verify. very well, we'll do it. But there is, there's also interesting kind of like, honestly, one of the bigger issues is more like the hashing functions that are used for, yeah, for kind of creating the. The digest, right. That that's, that ends up getting signed. There's some hashing functions that are, you know, optimized for ZK. And then there's other hashing functions that are maybe more optimized. You know, Ethereum is, is more favorable for, you know, kind of other, other types of hashing functions. Right. And so that's another kind of like intricacy. And then if you do like multi-party computation, there's other hashing and signature schemes that are. More like better suited for multi-party computation versus zero knowledge proofs. So there's kind of all these other little intricacies that you need to tie together too.

Nicholas: And what is it that you're able to verify so conveniently of these, like, how are you able to do it in a gas efficient way in the EVM? What is the verification technique you're using?

Brian Weickmann: Yeah. So, I mean, so basically when you write a zero, like a circuit, you can also, there's like a. A verifier that's, that's generated based off of that circuit. And that verifier is we, we kind of just deploy that on chain and any, any proof that gets, uh, that's sent on chain. We just check against that verifier. Right.

Nicholas: So it's unique to the, so basically you guys write some circuits that do the verification that's required for your very specific application. You can sort of compile that into something that you can write a contract. That you can put on chain and then that contract can be accessed every time you want to verify a signature of this data type, uh, for this kind of snark. Uh, and so you don't need to redeploy it for every single transaction. You can just reuse it. And it's, it sounds like it's somewhat gas efficient to do that verification too, or it's feasible. Yeah.

Brian Weickmann: It's gas efficient relative to having to do that. Like the computation that the circuit is doing on chain. Right. So, you know, it's still going to be like a couple hundred K of gas, but it's maybe, you know, if you had to do the signature. Verification in solidity on chain, maybe that's a couple million of gas.

Nicholas: Um, so it's a couple hundred K that's not bad. This kind of.

Brian Weickmann: what's that? Yeah. It's like 200, 300 K, I think, especially on base, it's pretty cheap. Um, so yeah, I, again, it gets to kind of the other use, the other usage that people talk about with ZK beyond privacy is kind of like this, like compression or scalability ideas. Like you can do all this computation off chain. And very cheaply validated on chain, you basically, you basically can, you know, a theory was kind of like the world's slowest computer and you can validate the, uh, the outputs of the world's strongest computers very, very quickly on the world's slowest computer.

Nicholas: And I guess that also lets you get access to all of these different hashing algorithms and signature schemes. If you can just prove them with ZK, then you go that route rather than trying to lobby the EIP process to incorporate pre-compile systems. But yeah, I think for every type of signature scheme, this just can be a solution for all of them. I guess in the current specification though, it requires that you deploy a contract for each unique scheme that you would like to verify.

Brian Weickmann: Well, again, again, that's dependent on, um, the, the backend you're using for your, for your zero knowledge curve.

Nicholas: So you're saying halo2 might, might allow for a global solution?

Brian Weickmann: Yeah. Like we, we wouldn't have to do a, uh, a trusted set up ceremony for, for every, every circuit that we write. Um, you know, yeah, we can just write the circuit, uh, and, and be able to submit those, uh, the, uh, the proofs generated by those circuits to that kind of global verifier.

Nicholas: So global verifier means really you wouldn't need to deploy a unique smart contract at all. You would just have your sort of escrow contract that would call out to this global verifier. So it, right. It's almost like, um, in the EIP-7212 stuff with the SECP-256R1 curve, the P256, uh, verifier people are using for verifying pass keys. Like there, there is a single contract that can verify all of those. So a global verifier for Halo 2 would maybe act in the same way, but also give you the access to all these other signature schemes that could be proved and verified through that contract. Yeah.

Brian Weickmann: I think, um, the. Yeah. The other signature schemes, what's interesting about that too, is like, it's not necessarily a free lunch either. Like, like I was saying, there's some signature schemes that are better suited for, uh, zero knowledge proofs versus, you know, signature and hashing schemes. Right. So ultimately, like it may all look the same on chain, um, but there, there may be like costs to bear in terms of the computation time and complexity off chain. Right. So it's not like a. But it is certainly from like the, the cost of, uh, transacting on chain standpoint. It's it's yeah.

Nicholas: And shifting the burden away from needing to update the EVM spec to support all kinds of custom things. Right.

Brian Weickmann: Right.

Nicholas: What's a, what's a nullifier? You mentioned them before. What are, what are nullifiers? Yeah.

Brian Weickmann: Nullifiers are basically just, we essentially in our use case. more broadly, it's, it's basically a way to say like, okay, this piece of data. We've seen it before, uh, and, and so you should kind of like announce, yeah, like somewhat, somewhat like announce, um, for our use case, we're just hashing emails because that hash should never change and storing those on chain. So then exactly in a mapping. So anytime somebody comes and, um, submits a proof, that proof is actually out also outputting a hash. Of the, of the email. And so then in our smart contracts, we'll check to make sure that that hash hasn't previously been used. Um, so yeah, it's basically a way to like nullify the data and say like, okay, this is no longer, no longer valid or, and that's primarily for like double registration or also for double withdrawals. Uh, it's mainly for the, like we actually allow anybody, you can, you can re-register from multiple accounts if you want. So you don't have to, it's not like. One Ethereum address, one Venmo account, it is actually an Ethereum addresses, one Venmo account. Um, so we're not as concerned about that. Uh, it is more of that kind of like, almost like a double spending, right? You're, you know, if we go back to that, you know, Venmo is an L2 or L3 example. You're basically saying like, oh, Hey, I, you know, trying to reuse the same transaction.

Nicholas: I've collected on this already.

Brian Weickmann: Yeah. Yeah.

Nicholas: So what are the trust assumptions and the risks associated with, uh, with using ZKP2P under the current design?

Brian Weickmann: Yeah. I mean, um, certainly like from a risk, well, I guess I can start with like, there's always risks in things like the, uh, and this isn't, this wouldn't necessarily be like a loss of funds risk, but it's more of like a, you know, if Venmo or HDFC, who's the, our UPI thing, if they were to change like email templates, so changing email templates could like invalidate, uh, payments you've made off chains. So then we'd have to like rewrite the circuits, redeploy them, and then you can validate that payment. Right.

Nicholas: Um, good thing banks don't change, uh, the software. that much, right?

Brian Weickmann: Yeah. Yeah. I mean, the, the bigger thing is really kind of those DKIM key rotations that, and that also points to certainly one of those kind of like the trust assumptions. Here is right now we're maintaining what that DKIM key is, um, it's behind multi-sig obviously, but there is like some sort of trust that we're putting the correct, um, you know, public key on chain. I think we, that's one of the, like the main things we're trying to kind of move away from. Um, and we have some ideas around, you know, doing that. And some of it's just like, there's like simple solutions, like, okay, well, if you deposit money, or if you're the off-ramp where you just define the domain key that is valid, right. And then, you know, it's more, then it becomes more of like a UI problem. It's like, okay, is this, you know, what's the domain key that we know? Is this a valid domain key? And then it's more of like an informational problem versus kind of like us actually having to essentially maintain that, uh, that domain key on chain. Um, cause that's like a very different, uh, just a different trust assumption. There that you have kind of like in us. Um, so we definitely want to move away from that.

Nicholas: If, if ever the keys were rotated, you, the off-rampers would, could maybe submit some new updated data to the contract without having to remove all of their deposits or how, you know, what, like, let's say the, let's say the emails were to change in some way. Um, what would have to happen with the USDC? Let's say that's already in the contracts. And if people are. I guess if you have like a transaction in flight already from Venmo to somebody and you're going to make a proof about it and then the keys rotate, that could be a problem for you too.

Brian Weickmann: Right. Yeah. So there is definitely that. So we'll start with like depositors, people who have deposited their funds into, uh, the smart, uh, to, unto the smart contract to off-ramp, they wouldn't have to do anything. right now, actually, like the way things are designed, that's like incredibly passive. They wouldn't have to do anything in the way, because we're kind of, you know, at the moment, maintaining that, that domain key, you are right. Like if, you know, the, our first user that gets sent, uh, an email with a new email template, they may get stuck in the situation where it's like, oh, uh, I can't, I can't validate this, this payment anymore. Right. And this is where, you know, I mentioned like TLS earlier, like this is where things like that are a little bit more like reliable. There's also potential other things we could do around like. You know, like a rejects virtual machine or something like that, potentially, although that, that, that would just reduce the turnaround time for the circuit. It wouldn't necessarily, you know, it wouldn't solve, solve the problem if, if the template changes. Um, so yeah, anyway, a little bit of a ramble there, but yeah, that is definitely one of the, the, the, the risks is this email template changes when you send the transaction. Now you get the new email. And it doesn't validate against our, our verifiers.

Nicholas: Got it.

Brian Weickmann: Trying to think any other. Yeah.

Nicholas: Those are some of the main people. Yeah. People want to see the whole, the full list. There's a docs page on it.

Brian Weickmann: We've tried to be very like upfront with those sorts of things. Like this is, this is new tech. Like, uh, we're not, we're not trying to hide anything. Uh, we can't hide anything ultimately. Like it's all open source code. Um, and so it's definitely encouraged people. Like take a look at, at some of the risks.

Nicholas: Yeah. The docs are great. And the, and the website's very forthcoming with all the risks, uh, as well.

Brian Weickmann: Thanks. Yeah. That's definitely was our intention. But yeah, you know, these are, this is like a living and breathing project, right? So things will, will continue to kind of work on some of these things over time to kind of decentralize and remove some of these trucks, uh, kind of current trust assumptions.

Nicholas: Um, why did you decide to partner with, uh, HDFC, this, uh, Indian bank, uh, for the UPI? Yeah. Transactions maybe for context, like what is UPI and why is this bank relevant for what? Yeah.

Brian Weickmann: So UPI is kind of India's, um, kind of nationwide payment rails. It's actually, uh, pretty impressive. The it's basically like every Indian citizen has, um, Like a UPI ID and you can easily send money to anybody via the, via these rails, uh, anybody or any like merchant. That sort of thing. So I think it's just essentially a very efficient, uh, version of kind of like web to financial plumbing.

Nicholas: WeChat or something. Alipay.

Brian Weickmann: Yeah. Well, this is even like, I would say even like a level below, below that, right. Is it's like, we, we chat or Alipay maybe built on top of something like, like this. Um, this is like the, the, you know, the, the, the true plumbing that can then support other like FinTech apps and things like that. Yeah. So as far as the HDFC integration, I think, you know, Sachin, one of our team members actually lives in India. Uh, so he would know a little bit more about, about it, but HDFC is just one of the bigger banks, essentially, and bigger banks and, you know, have the information that we need in their emails to be able to, to, uh, you know, do the proofs and, you know, reliably be able to facilitate the, the on-ramping transactions without there being any potential fraud or anything like that. So, um, yeah, that, that was really the, the, the main criteria is one, what do you think most people are using? And two is the data available in the emails to be able to, to do it.

Nicholas: And I guess you don't need to really partner with them as long as those, especially the email data is available. It's sort of permissionless from your perspective and you get to tap into UPI.

Brian Weickmann: Yeah. In some ways. Yeah. It's kind of like this, this is how, in theory, like we could become this kind of connector between all these different, you know, localities, um, trying to really bring people that are on their local payment networks, more close to kind of the global ecosystem as well. Right. Uh, right now that is, like I was saying, it's like incredibly segregated, pretty much every country has their own payment networks. There's like some that are kind of, there's some companies that are transnational, but, but even within those companies, the payment networks are still kind of like walled off from, from the other countries, just because, you know, obviously every country wants to have its own control over its own like financial system. Um, but so we're, yeah, we're kind of a way to just like link all these things together.

Nicholas: So does this allow you to like, can you do swaps? Could I go from a Fiat on-ramping with, um, HDFC UPI transaction and have someone receive, um, USD in their Venmo directly?

Brian Weickmann: We don't have that built yet, but yes, uh, that is actually, I think a subset of the team, I was able to, to be there, um, uh, one of the hackathons I think is in Paris. Uh, they actually built a prototype for this. So the ability to, to go from like, to pay somebody in Venmo and have somebody receive money in their like wise account or, or it could be HDFC or, uh, any of these other things. And, uh, payment networks that we're looking at.

Nicholas: Do you know how in those constructions, how are you able to know what the, um, the exchange rate is between the two currencies?

Brian Weickmann: Uh, so those are all still just be set by the, the on-rampers and off-rampers and they're in their specific kind of like, they're intense, I guess.

Nicholas: Yeah.

Brian Weickmann: Well, what am I trying to say is because we have like different deploys for each payment network. And so on the Venmo side, you'd be doing like USD to USDC exchange. Right. And then when you go, let's say you're doing to UPI, then you'd be doing a USDC to, uh, rupee swap. And so on the, you know, kind of the Venmo side of things, you're essentially doing a one-to-one transaction, obviously some sort of a spread. And then on the other one, people, uh, on the kind of like UPI side, people would be maintaining kind of some sort of, you know, price based on the price of rupee to, to, to us dollar.

Nicholas: So basically you, when you are making your orders, there are essentially limit orders where you say what you're willing to pay or be paid. in that way, you don't need an Oracle for establishing the price. It's just whether it's within their tolerance or not.

Brian Weickmann: Right. And, you know, obviously there's things we can, as we look to make some improvements to the protocol, there's things that we can potentially do to, uh, make that pricing more efficient. Like right now, because. Yeah. You know, because it's not tied to an Oracle, for example, like, like you said, it's a limit order. Um, and so if, you know, for whatever reason, currencies move really fast, okay. You may get your limit order, make it like picked off. Right. Uh, other there could, but there could be other constructions that depositors or offer amperes could buy into. Right. So you could in theory use an Oracle and just have, they would define like, okay, give me 50 basis points, you know, above the Oracle price and that's roughly right. Something like that. Or, you know, one thing that we would love to do is ultimately move this to kind of like an off-chain type of order book. So then anybody can, you know, update their, uh, their conversion price at any time, essentially by invalidating a prior order and sending a new one. It'd be similar to zero X. Like if you're, if you're familiar with, with how zero X works, where there's kind of these off-chain messages, if you want to cancel, if you want to invalidate it, there's either like a time period. After which it expires. or if like you want to invalidate it beforehand, yeah, you have to submit the cancel order on chain.

Nicholas: I'm not super deep on it, but have you thought about like? Uniswap X also has this kind of like natural incentivization with a declining price over time that encourages people to take the offers faster?

Brian Weickmann: Oh, interesting. Yeah. Kind of like, um, it's almost like an auction of sorts. I I'm actually not super familiar with, with Uniswap X, uh, either.

Nicholas: Essentially from what I understand, at least it incentivizes you to take the limit. Order sooner, uh, by having a declining, uh, price at which you can, uh, take the order over time.

Brian Weickmann: Yeah. I mean, I think that's all like, these are all just different pricing strategies. Like if you're in a kind of like write out, uh, a feature list, one of those buckets of features may be something like, okay, well, how do we allow depositors to, uh, specify like their off-ramp price? Um, and so right now, yeah. I mean, you can basically think of what we have. An option, but with a flat, flat curve, right. The price isn't moving, but yeah, we could also set up all these, whatever pricing strategy, like if people are feeling they're going to be increasingly more, have like an increasing need to get their money off ramps, then yeah, you could have the type of price curve that you're talking about. Other people may just be like, I just want to get off at some point. I don't, I don't really care, you know?

Nicholas: Right. Is, uh, so is EKP2P a company or how are you thinking about the organization?

Brian Weickmann: Yeah. Uh, so we do, you know, we do have an entity, um, that, you know, I guess is, is ZKP2P. Um, right now though, we're all, uh, grant funded. So, and that's kind of a status that we want to maintain for certainly as long as we can. Um, ideally we would love to never take any kind of like investment, but yeah, uh, we, we've kind of slowly morphed into, uh, into becoming kind of like a company. We've all started, uh, kind of started moving onto this full time and basically just trying to find ways to, to bootstrap as, as we go, uh, like I said, like PSE has been an awesome partner for us, not only like financially, but also being able to provide audits, um, that sort of thing. And we're, and we're excited to be able to showcase some of the work that they've been doing too. Right. Like ZK email is, uh, is a, uh, PSE project. And so we get a, you know, those guys get to see kind of their code in production being used, um, by people that's on ramp and the other ones like TLS notary, as we were talking about, kind of these TLS connections, TLS notary is, is a kind of a scheme to be able to, to, um, validate, you know, uh, TLS connections. Um, so yeah, I mean, we've been very fortunate really to work with them. Um, and then, you know, there's a number of other kind of, uh, projects we've talked to around like grants and things like that too, but yeah, that's, that's kind of how we're, we're approaching it. You know, we, we have an entity, we have a, you know, we have a company, it's all like, it's all four of us have worked together for a long time. So we're just kind of, in a lot of ways, it still has a bit of that, uh, kind of just hacking on things feel, but we do, you know, we're, we have certain goals and, and theses that we're trying to test. And, um, yeah, we're definitely moving forward as like a full blown company.

Nicholas: Awesome. And I know that it's, it's live right now. Do you foresee it being integrated into some of these new passkey smart account wallets that are coming out or any other things that are sort of shaking up how onboarding to crypto in the first place happens? Are they potential customers or integrators?

Brian Weickmann: Absolutely. Yeah. Yeah. We've, uh, we've definitely talked with a number of wallets. We've talked to chains, things like that. Um, you know, ultimately like what is really nice about how we do things is it's a lot of these wallets or even just dapps themselves. They can now have. A embedded on ramp into their, into their app. Right. Versus saying like, Hey, go to Coinbase and like transfer some money in. And then like, hopefully the user comes back. Right. In theory, like. Any, any drop off that occurs there. just by embedding us directly in the app and it's like okay couple clicks you get the money directly in your account. I will also say like our kind of four three three seven implementation that will be launching like seven to seven to ten days. while we don't intend to be like a wallet it does. it will operate similarly to how if you know a kind of fractional wallet wanted to integrate us. yeah so I mean we we've talked a lot of those themes. we're really excited about the opportunities there because we do think that that's like that. being able to embed an on-ramp into an app is really powerful especially for wallets.

Nicholas: yes definitely it's. one of the biggest problems for increasing adoption is just how onerous it is for regular folks to. I mean if a web to app had to ask you for your driver's license before you could get an account they'd be a lot less popular.

Brian Weickmann: yeah yeah I mean it's just. these are those small UX things. they're just gonna get better and better over time. with crypto. it's like oh you know I don't have to do five steps to fund a wallet I just have to do. I can do one and I can do it directly in. you know this DAP I'm on. I don't need to like go through five different tabs to figure it out like. these are the things that will ultimately make. they'll ultimately be able to onboard more and more people. As we get closer and closer to the flows that these people are used to, it reduces the friction to even own a crypto wallet. It's like even just being able to sponsor gas and things like that. These are massive improvements in UX. We're hopeful and excited to be a portion of that, for sure.

Nicholas: Very cool. Aside from the fees that the depositors apply to their deposits, are there any other fees associated with using CKP2P?

Brian Weickmann: Not at the moment. We do have the ability to add a little fee for any volume that goes through. We don't have that turned on at the moment. It's still early. We don't even know the best way to monetize. Best way from, obviously, a revenue standpoint, but also from a legal standpoint, a regulatory standpoint. Where can we actually try to accrue value to ourselves in a compliant way? It's there. Don't have any plans to turn it on anytime soon. There's that small little fee.

Nicholas: Is there any MEV concerns, or does it relate to MEV in any way under the current construction?

Brian Weickmann: Not really. I guess the only MEV, the only potential concerns would be somebody front-running a signal intent. Let's say there's only a little bit of liquidity left. If you could see your transaction trying to take that last liquidity and front-run it and get that liquidity themselves. But as far as any exploits on the on-ramping side, no, because it's tied. It's very, very tied to the two counterparties. It's not generalized. Anybody can step in.

Nicholas: Looking forward, what else do you, I guess, is the focus expanding to new countries, new banks or fiat providers? Beyond that, do you have any plans? What things you could do with these techniques that are not just about on-ramping or really majorly focused on on-ramping? for now, I guess?

Brian Weickmann: I would say our guiding light in terms of, like, we have like a full-blown guiding light at the moment. I think this is some of the things that we're trying to figure out. Like this year is definitely going to be a year of experimentation for us. Like we have all these theses on, you know, who the market is, what they want, what different individual markets want that we all, we kind of want to test out a little bit, right? But as far as kind of like a North Star of sorts would be essentially Binance P2P. Like, how can we just create a better Binance P2P? You know, that's, it's early, like these things are all, if we find some like awesome market that is slightly different in some way, then, you know, we may kind of make a hard left turn. But that's kind of our guiding light at the moment. So to the extent of like, OK, what, what do we need to do to kind of get some more future parity there? I think there's certainly. one of the big things is being able to swap into kind of like any asset. So 4337 actually would allow us to do that because we can bundle a bunch of transactions together. so we can bundle like your on ramping transaction with like a swap into ETH or bundle your on ramping transaction within a bridge transaction. So now you have USDC on Solana, Arbitrum, Ethereum, kind of like wherever you want. So we're starting to get close to that functionality. And then it's like, OK, we obviously want to add more payment providers. And part of that is to be able to test things around, OK, well, how how starting with thesis is just people's pure demand for US dollars versus people just want to get money on chain and like invest and do that sort of thing. And then there's all these other theses around. We were talking about a little bit earlier. How do I send money from Turkey to India, India or Argentina? Like, how do we do how are we able to potentially do that sort of thing? Because, I mean, there's some massive remittance markets out there, right? Like, is there a way to potentially put ourselves, you know, insert ourselves into that market? Right. So it's, you know, it's at a very high level. It's going to be a lot of integrating new new payment processors or payment networks, integrating, trying to explore like different ZK primitives to allow us access to more of these payment processes is kind of like the TLS type of work. And then how do we like working on integrations with, you know, wallets and things like like, how do we make that experience like really nice for people? And then there's all these. those are more on the technical side and there's certainly some like operational stuff around, like how do we improve liquidity, all those sorts of things that we'll be investing some time in as well. Yeah, that's exciting.

Nicholas: Brian, thanks so much for coming on the show and telling us all about ZKP2P. It's a super exciting project. And very cool application of this next gen tech for a problem that tons of people have today. So it's very exciting. Yeah.

Brian Weickmann: Thanks. Well, thanks for having me. This is this is great. Great to chat with you. And yeah, as always, feel free to reach out. in our we have a telegram channel. It's actually fairly active. So feel free to reach out if you have any issues. Hopefully not. But if you do, we're always in there. Or if you have any just any questions. Yeah. If you're, you know, if you're a US citizen or just have Venmo or you have an HDFC account, it really would be would be awesome for you to try it out and let us know what you think. And yeah, we have more coming. We'll have have some integrations on the horizon with Turkey and Argentina. So we're excited for those as well. Those are those are some very crypto hungry countries.

Nicholas: So, yeah, I'm sure it makes me think. I'm sure it's not a super high demand. Place given the regulatory environment is convenient enough for crypto, but Canadian Interac transactions generate emails made me think I wonder if it would work out easily, but probably not such an urgent market to address.

Brian Weickmann: I mean, there's all these, you know, beyond the emails. There's just so much signed data around us. Like, yeah, I think the the opportunities are really pretty, pretty big in the ZK space. So that would be my other my last thing. I would say to people, like, if you're interested at all in this, like. It's early like this is see, I started writing solidity and like twenty seventeen, twenty eighteen, I would say the tooling is maybe even worse than it was then at the moment, but it's getting improved and there's a lot of people investing time and energy and whether it's from, you know, kind of the industry side or also a lot of like academic effort going into zero knowledge groups as well, because there are there are a lot of benefits outside of just firetruck, a lot of benefits outside of just Web3. There's a lot of potential for this in the Web2 space as well. So I would very much encourage people to jump in, try to learn, build some cool things like you're you're ahead of the curve. I think if you're getting into VK now.

Nicholas: Yeah, definitely. And it's exciting to hear there's all these grants available to for projects so they can experiment without getting on the VC treadmill. At least right away. Yeah.

Brian Weickmann: Yeah. I mean, we've been very blessed that you know, we've been able to leverage leverage those grants. But yeah, I can't speak highly enough of the privacy scaling explorations group within the Ethereum Foundation. Yeah, they've been great to work with. And we've definitely a lot of other folks we've talked to that have been great to work with, too.

Nicholas: That's great. So if people want to learn more, zkptp.xyz, lots of links in the show notes. Brian. Thanks again for coming through and thanks, everybody, for listening.

Brian Weickmann: Thanks much.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at Web3GalaxyBrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5:00 p.m. Eastern Time, 2200 UTC on Twitter spaces. I look forward to seeing you there.