Episode 381 - Payy and Payy Card, the Undoxable Credit Card

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week, Terrun and I catch up with Sid and Cal from Pay. We talk about their private payment product, the focus they've put on building good UX for this one use case, how the evolution of ZK tooling allowed for it, the inner workings of the Visa remittance system,

and a very detailed walkthrough of how pay works under the hood. We tap into a number of other related topics like how the goal of self-s sovereign money has been lost to speculation, why many of the new stable coin projects seem to be a return to traditional finance, how privacy payments and well-built applications are making a comeback in 2025 and more. Now, before we kick off, I just want to make sure you're following our release of the ZK whiteboard sessions season 3. These videos produced by ZK Hack and supported by Bank Capital Crypto feature our hosts Nico and Gummo exploring the building blocks of the ZK systems we know and love. We are currently releasing one module every two weeks. These can be found over on the Zero Knowledge Podcast

YouTube channel. Subscribe there to be reminded and we'll be adding the link to the show notes. Now, here is our interview with Sid and Cal from Pay. Today, Trun and I are here with Cal and Sid from Pay. Welcome to both of you. >> Hi there. Hey. Excited to be here. >> Cool. Hey, Tun. >> Hey. Excited to be back and talking about kind of the oldest application in crypto, but the still unsolved one. >> Very much so. Cool. Quick disclosure. Trun, you're an investor. Yes. In pay. I am also an investor through ZKV.

>> Of course, nothing that we say is ever investment advice, etc. We have been tracking this project for a while now, so it's very fun to get you on the show to dig in. Also, you've had some cool announcements recently. I think there's lots to talk about. >> Yeah. >> So, I want to start by actually jumping into pay. It's a project that I I see as kind of tackling one of the age-old ZK applications, which is private payments. So, what is pay? This is pay spelled with two Y's, by the way. And what makes pay unique? Pay is digital cash, self-s sovereign digital cash, the way it was supposed to be built. It is Bitcoin but actually usable. It is something that we

started working on in 2023 when payments, stable coins, anything to do with that was very unsexy >> and also privacy >> and privacy >> was very unpopular. a little dangerous to work on maybe even. >> And our belief is that true self-s sovereign digital cash that's private is really the missing link between what Bitcoin's vision was and what its implementation should have been. >> And we've built three insanely complex and yet simple to use technologies to solve this. The first one is Pay Network. Pay Network is a blockchain

that allows for compliant and private stable coin transactions. We've also built Pay Wallet, which is the most usable stable coin payments app, and it also functions as as a bank account where you can use Stablecoin to save, spend, and in the future invest, and borrow. And we've recently just shipped Pay Card. Pay Card is the first non-custodial crypto card with privacy built in, which makes it undocibleable. >> You're positioning it as a continuation on Bitcoin, which is funny to me because to me it would be a continuation on Zcash, >> which is like the privacy payment application. That was what they were

built for. >> Why do you not see that as part of the thread? Like do you you see yourself more as a successor to Bitcoin? like tell me a little bit about why that would be. >> Yeah, it's a good question. I think Zcash took its primary directive of adding privacy to a Bitcoin like system. That's not our primary directive. Our primary directive isn't privacy. Our primary directive is self-s sovereign digital cash. And well, it turns out you have to have privacy in order to enable that at scale. >> So that's why I think we're more of a continuation on Bitcoin. I mean, we're inspired by Zcash in many ways.

But privacy is not our prime directive. It just happens to be something we believe is required. >> Interesting. And maybe I mean where Zcash is also an asset that can gain in value like Bitcoin in the case of the pay payments like those are stable coins. So you're not investing in those stable coins necessarily. You're not it's not speculative. >> Yeah. And I think removing speculation from crypto really forces you to make it usable >> cuz people will use the terrible products that we have in crypto, the janky workflows, all because of speculation >> and greed. And that's fine. But really, the test of a real product is do you

actually solve a problem in someone's life and do it in a way that's really accessible to them? >> Cool. >> Okay. I have a a boring but important question. Why the two W's? >> Really? Of all the things. Of all the things. Okay. Uh actually it was three W's at the beginning. >> Oo. >> And Callum said three was too many. He said drop the Y. So I dropped one Y. >> It's cleaner. Very nice. >> It's cleaner. And then we ended up with P A Y.

>> Cool. >> Okay. I just feel like the audience sometimes needs to know etmology, right? Like especially in in crypto where like the names just get crazier over time. Pay is like a name that's an easy name to understand but then slightly crazy, right? It's like it has like the one streak of colored hair or something, you know? It's like your blues blue glasses. >> Exactly. There you go. >> Actually, there's one more tidbit I'll mention since we're going into lore a little bit. I always believed like we wanted to build this product that was like loved by people like almost a cult product. And what I realized was like when we misspelled pay with two Y's, it's almost like a if you know, you

know, and you get to tell people, you get to say, "Oh, I use pay is pay with two Y's." There's this extra, I think, ownership and connection over that. It's subtle, but I've heard this in person and I've heard people say this in front of me and it's kind of just a moment to like own that and and and know something that someone else doesn't. >> And and also I cannot spell pay the other way now. Like every time I write in a document, it's like p y. >> Oh man. All right, Cal, I want to hear a little bit about you. What got you started got you interested in this?

>> Yeah, I'll be I'll be totally honest. Like for me it was I I got totally zk pill. I kind of like found this technology and I was like this is incredible. This is nuts. Like this shouldn't be possible. Like to be able to >> be able to do this and I always always my blockchain experience was like yeah but how is this going to work? Like this is all great but like how do we get like consumers using this blockchain technology if you don't have privacy? And I think for a long time, like particularly when we when we started this, like it was it was not a super popular idea that like we would need privacy. And I think actually in recent months, and maybe I'm skipping ahead here a little bit, but in recent months

because people can now use the payments in a real world, maybe on a card, and they they're starting to see that like, oh crap, >> privacy. >> You can't have like this world exist without privacy, right? Like we don't have that, you It's not like your bank broadcast all of your transactions today. Like we're taking a step backwards. And I think when you're just paying your friends, you know, for for some food over crypto, like every now and then, you can kind of have some good security ops and and make it work. But when you're doing like everyday payments, like it just does not work. So yeah, I I I guess for me it was it was mostly if I was EK.

>> Interesting. Before you started working with Sid, what were you doing? >> Actually, it's kind of interesting story how we met. I was actually at YC when we met. Um, and I was building a data analytics company and he was actually using the product and he kind of reached out and was just like, hey, like this is cool, but like you're missing this feature or something like that. >> You're a power user with lots of feedback. Nice. >> And then he was like, "Oh, I'm in California." And I was like, "Oh, great. Like I'm at YC. I'm in I'm in California." And like he just like took me in cuz it was actually a pretty lonely experience like being in California for the first time like by myself. He was like, "Oh, I'll take you to the mountains and we'll just go for a walk." And like we just started chatting

about like everything from blockchain, crypto, like where like where is the world at? And I think kind of some of those nearly initial conversations like spurred our thinking of like starting the company together because it was I think it was 2020 when we first met and and it wasn't until 2022 that we actually started the company together. >> Cool. So I kind of want to do a bit more on this history with both of you. Sid, you talked about sort of the Bitcoin story. You were using Zcash, but yeah, just recently I had Ian Meyers on the show and in that we talked about, you know, this this early blockchain plus ZK combination and Zcash, the formation of Zcash. The goal of Zcash has always been payment rail payments for in private

form. What did they do right and what did they do wrong? Like why do you feel like there needed to be an evolution? I mean, they were also very early. they didn't have maybe the same tools that you guys have had, but yeah, like why not build towards this like build on Zcash or something like that. Why build something new? >> I think when we started this first principles approach to payments, we looked at everything that was out there and we asked a simple question. Can I get my friends and family to use this product for payments? And the answer for Zcash was like no. It was a it was a resounding no. And there's a few really strong reasons why it's a fluctuating currency.

So you can't >> it's not >> reasonably use that for payments. It's not it's it's one of those attributes of money right? >> Second, it had this brand identity and reputation around these like privacy, but like really deep privacy and maybe you're not doing good things with it. Brand. And obviously that's that's not something technical. That's just that's a signaling and brand thing. >> Mhm. >> And then last, it was just really hard to use, right? So, you would you would have you had a few different Zcash wallets were really like they were kind of hard to set up.

>> Yeah. >> You had to sync the chain. So, I think it took like 30 minutes or an hour to like when you initially like started it and then getting money in and out was super annoying >> and you had to move it from the shielded to the or the unshielded to the shielded. It wasn't privacy by default actually. >> Yeah. Exactly. And once it was shielded, like it was like, okay, I'm can I offramp this now? Like because I went through the shielded pool. >> Yeah. And that came up later as well with the compliance stuff where all the exchanges started banning offramping of of Zack of Shielded Zack >> and we said, "Okay, obviously this is not usable." I think what I think what Zcash got right was it is to me a very clear successor to Bitcoin for store of

value. It is in my opinion the best private store of value, digital store of value in the world. >> Yeah. >> But as we know with Bitcoin, store of value doesn't mean it's actually usable >> for payments or day-to-day things. Yeah. And like we love Zcash like we built we started with Halo 2 because because that was the right technology at the time and I think we've moved a long way in particularly in ZK world in terms of what the cutting edge and and what's available now and what we can do now. And so like that's also something that's changed. I think the other thing with Zcash is, you know, it is supposed to be a Bitcoin su successor and it it really does replicate Bitcoin but make it private and that's great if you want a

Bitcoin, a store of value, which is what Bitcoin is great at. But what Sid was mentioning is that Bitcoin doesn't really work for payments because the block time is too slow. I think for Zcash it's like 2.5 minute block time. Like you know, you go and pay for a sandwich, you got to stand there for 2 and a half minutes. It's just not going to work. So yeah, I think that that was the other reason we couldn't build on top of it from a technical level. >> Cool. I think it actually might make sense for us to dig a little bit into the technical level. There's a bunch of questions that I have actually about the product and like how the product works, but let's hold on that because you just mentioned having started with Halo 2, but then exploring different tech stacks. What does it look like today and

how is pay built? >> Yeah, so we're in an an L2ZK Validium rollup. That means that we only post the root hash onto the L the L1 that we roll up to. That's Polygon today, but we could actually roll up to any chain and we'll be adding that potentially in the future. And it's essentially a big Merkel tree. So when you do a payment on pay, you do a ZK proof on your phone. That's the primary way that you get privacy. So anyone who says like you can get privacy without doing the zero knowledge proof on your phone is lying to you. Um you have to have the proof on your phone. And once you've done the proof on the phone, you have to have the client side proof. And then that gets sent to a sequencer who basically bundles all these transactions together

and does one big proof that combines all these other proofs together and then posts into the L1. So that's kind of architecturally how pay works. We have this big Merkel tree and if your if your note is in the Merkel tree, then you have funds. If it's not in the Merkel tree, then you don't have the funds. But how does like if if it's all local, how are you actually interacting with other individuals in this network? Like if if you're only sending a proof to the sequencer showing some transaction, showing your balances, how does like another user guarantee that you would have what you say you have?

>> Yeah. So the Merkel tree is is public to everyone. So everyone can see this Merkel tree which is basically a hash of hashes where each hash represents the money that you have like your balance effectively >> and it uses a UTXO model. So that's similar to Bitcoin actually similar to Zcash. They use those models. So every hash represents some monetary value. >> Um and then I obviously want to spend that money. Maybe I want to send it to you Anna. What I do is I do a proof on my phone that says like hey like there is a hash that exists. Everyone agrees this hash exists in the Merkel tree. I'm going to do a proof that says I'm not like creating money or destroying money.

I'm just going to like maintain money so that the inputs that I put into this transaction and the outputs are going to match. That's what UTXO stands for. >> It's basically saying that like the monetary value going into the transaction is the same as the monetary value coming out. >> And then the ZK is basically just saying like did everything go correctly and this is the new hash that you should post to the Merkel tree and these are the these are the the hashes that should be nullified. Now, when we first went live with pay, we used a nullifier approach. So, when you spend money, you couldn't actually link anything at all.

So, you could make a payment and that would be completely hidden because we create new h rather than like removing the old hashes from the tree. >> Yeah. >> We created new hashes which kind of meant you couldn't double spend that money. >> But it totally offiscated what was there before. But you've changed that. It's not like that anymore. >> Yes. So, we've changed that and I think maybe we can kind of dive into some of the compliance stuff. I think one of the big areas of compliance for us was how do we make the a system that is as private as it possibly can be but doesn't get wrecked.

>> And I think, you know, we've seen things with Zcash, for example, where you just can't get your money out once you've gone into a shielded pool >> because of compliance reasons, like because to take it out could like taint your wallet or something. to take it out like you just can't none of the offramp providers will accept it. you know, a lots of the apps won't won't accept it from that point onwards. And so, you know, something that's been really strong for me and Sid is always looking at, okay, like how can we make this a really usable experience? >> And we felt the best way to do this was to have a lineage that is basically open to everyone, but the transaction amounts, the transaction values, the transaction recipients and sender are

all private. So okay, and really taking a step back like why did we make the system the way we made it? We have like really one goal which is to stop North Korea and people like North Korea from like abusing the system, right? Like that's what we all want as a good system. And so we couldn't think of a better way to do that to discourage them but keep privacy for everyone else than to keep the lineage but keep everything else private. uh you know for every every user then at that point like there's nothing that I can look at and say like hey you've done this or you've interacted with this person because we use this UTXO model every single note effectively has its own address its own like completely randomness except for the fact that you can trace some lineage

so if North Korea steals loads of money puts it into pay you can trace that they just like tried to use it as a mixer and took it out the other end. I think one interesting thing about the compliance aspect is you and maybe we can start with the question of assuming that you wanted a credit card as the form factor that you wanted the end user to use like what is like the minimal amount of compliance you need to get that off the ground right so like there's a sense in which a user onboards they have to provide some private information right to cuz like obviously the card issuer needs to know something but then afterwards like what happens that data when I transition to being fully on chain, what what data is remnant? Like

walk us through the whole process, right? Like a user opens the app, the app looks great, they say, "I want a card. What happens next?" Like cuz I I really do think like just that b the basic steps while seemingly simple compared to some of the ZK stuff can actually be like a little bit non-obvious to most people. Yeah, it's quite complex which is why it took us quite some time to build and launch this feature because we wanted to build something truly novel and move the industry forward than just another crypto card which you know there's a bunch of underlying providers if you just want to build a regular crypto card on base or you know arbitrum or whatever it's like couple weeks you just slap a UI together and and it's there. What we did was we created paycard as the first

undocible non-custodial crypto card. And what does undocible mean? So it means that you can't connect your KYC information to your pay network balance and transactions. Every other non-custodial card, there is one entity that can has both of those pieces of information. Ah, >> and today Nosis Pay or Metamas card or EtherFi card are kind enough that they're not doxing everyone, >> but it's dependent on their org.

>> As we progress in large scale adoption of crypto, the data analytics and exploitation problem becomes real. Today we have folks like TRM Labs and Arkham and other good folks indexing the blockchain uh multiple chains correlating things. I recently heard this is not public yet but and I can't disclose who told me this but I recently heard TRM labs uh can now fully dean anonymize rail gun >> and they use really advanced like clustering algorithms and all sorts of stuff to do that. And so fundamentally what we wanted to build was something undocible disconnect KYC from onchain identity. The way we did that is when

you KYC with the pay card and all of your pay your visa transactions those are just trapfy. So imagine like those visa transactions are stored somewhere. You know the KYC stuff is stored somewhere. This is all according to privacy policies and this GDPR compliant and all that stuff that has to exist in order for a Visa card to be issued. There's just simply no other way. >> But what we innovated on was saying because we use pay network for each card transaction.

>> We able to disconnect that KYC information and your Visa card transactions from other pay network transactions. Like it's not connected to this Morkel tree. Wait, it's not connected to the larger Merkel tree, the pay Merkel tree, or it's not connected to your But like you were I I thought you were going to say that it's it's really the ID component, this KYC and your payments like your own payments. Those are not connected, right? >> Yes. Those are not connected and neither is like the public activity on the network >> can't be looked at, analyzed, indexed, and used to link it to you as a person or your card spending.

>> Maybe just to understand how this works. So like the Visa transactions, this is using traditional rails. Is the are the Visa transactions connected to your KYC? Is it kind of like I have a full Visa card and I'm KYC and Visa knows who I am and Visa knows my my transactions? >> Yes. So you can't you can't ship a Visa card without that. Those there's AML requirements. There's counterterrorism financing requirements. You have to maintain that data for 5 years. Every single Visa card issuer, whether they're crypto or not, has to store and maintain that data. and they have to connect it to your identity. There's no other way around that.

>> But then you talk about the transactions the on Visa being connected to the blockchain transactions. How does that work anyway? Like are you mimicking what's happening on the Visa network and then mapping it to this Merkel tree or is it like happening at the same time on a device? Yeah. How does that connection happen? >> I think it's it's useful to compare it to what other cards are doing because it maybe like helps to like see where the differences lie. So, if you have another card that's just fully on the public open chain, then you can see where money is coming in. You can see that money being used in the wallet and then you can see that those transactions being spent and and being moved out of that wallet to be spent on the user card transactions. The way that it works on

pay is we non-custodally take reference of one of the hashes that exists. So you kind of say, hey, like I have this hash that's in the Merkel tree and that should allow me to you can produce proof say, hey, this this should allow me to spend this much money on chain >> and basically you can withdraw that at any time. So it's completely non-custodial. I can just say, hey, like I want that back and and do another transaction to get that money back >> or we can basically forward that money and offramp that money to the Visa effectively.

>> So we can only do two things with the ZK. we can either like send it to Visa or we can like the person can clear it back. We can't actually touch that money. >> Um so when we come in we look at that proof to say like oh yes like they have the money we we then submit the transaction on chain to cover the cost of that Visa transaction. We actually do that within the 1 second time that you have cuz our block finality is around like 1 second. we can actually like issue that, get the response back from the network and then authorize a transaction to Visa. And anything else that happens on pay, you can't you can't see anything else that happens on pay at that time. Like I can't see like what like how people got to that amount of money, how they got to that balance.

>> I want to kind of walk through a transaction because I just might not know how credit cards work that well. I don't know. Like I have a credit card. I have a pay credit card. I go to a store. I pay for something at the store. The store owner doesn't have crypto. So it's not like a behind the scenes crypto payments are going they are just going to accept the Visa transaction. >> How like I still don't fully get like the connection to the pay part of it and the private part of it. So like really walk me through kind of like that like I have the card I make a payment. Does it like automatically at that moment take from a balance on pay and do something to it?

>> Yes. So exactly. So like when when you sign up for the card program, you effectively upload, as I said before, like your money to pay, but we can't spend it or do anything with it. >> So this means like you're taking maybe you're on an L1. You like go change it into Actually, I wanted to ask you what token it is. Is is it like the standard stable coin tokens or is it a native one? >> Yeah. So pay network is its own protocol. So we're not like ERC20. We we do USDC on Polygon. We bridge that and it gets basically replicated on the pay network. So, when you think of money on the pay network, it's really just like four values. Actually, a really nice way to think about how money works on the pay network is when you send a link, right? I don't know if you've ever used

the pay app and you to send a link to send money to someone, but the entire money is in that link. >> So, we actually store the private key, we store the value of that note, and we store the address of that note. And all of that information enables you to have the money at that time because you can do a transaction at any time with with those three pieces of information. So I can like send the do the proof and send it to the merket tree and it gets accepted. So 10 people could have that same money and until someone claims it, that money is kind of like belongs to nobody, right? Like that money belongs, it's just it's an ephemeral wallet, right? effectively with this money in it and I claim it and then no one else can spend it because I claimed it into a new

wallet which was my own wallet. So when you're thinking about the Visa situation, they basically send us kind of like one of these these notes to say like hey I have this money >> who's they Visa or the user? So, so sorry the phone the the phone >> the mobile user. Okay. >> The mobile device like it sends this note to the to the pay servers and the pay pay stores that and so pay can spend that money on behalf of the user to cover the transaction that Visa is making. >> But we can only spend it by sending it to Visa or sending it back to the user like we can't extract that money.

>> Okay. Okay. But still I want to like let's continue to walk. So I I think you shared it's USDC. It's So that's where it's like a stable coin, but like you kind of said they there and it was confusing cuz it's like when you use the card, does Visa send something saying, "Oh, we now like have something." Do you see do you sort of see my confusion? I really want you to walk through like exactly what is happening with one transaction because >> Yeah. Like I like you also kind of switched between card and mobile. Like I think the initial one was like client side mobile, but like if you're using a card, is the card making the proof? Is Visa making the proofs? Yeah, I'm just kind of I'm confused.

>> Put another way, if you had to verbalize what the sequence diagram was of like each interaction, what would it what would it sound like? >> I'm going to go through like really slowly and like really like so, okay, so you tap the card on the machine >> at a terminal that sends a request to Visa. Visa forwards the request onto us and they say like does this user have the money? Now if we say yes to Visa like they just allow that transaction to go through and then they come they actually come a week later >> to come and like actually claim the money from us. So they'll be like hey like are you author so it's called an authorization. It's like you're authorizing users to spend up to certain amount of money. The whole card program network by the way is completely nuts.

Like people can overcharge. that you can authorize for like $10 and they can just like go in and be like, "Oh, actually I want to charge $20 and that you just have to accept it." So, there's like all these different systems that you kind of have to play with when you're dealing with a Visa card network. Uh that's part of where the complexity comes from. >> But let's just say it's a normal flow, right? Like so we've authorized, they've sent a request to us, we say, "Hey, yeah, like the user has the money. How do we check that the user has the money?" Well, ahead of time, the user when they've got the pay card, the phone is communicating with our servers and they are like sending this proof basically that they have the money that they can send the money.

>> Got it. >> And so we have this like note on our server and we can actually execute the proof on our servers >> and we do that during the authorization process. So the request comes into us, >> we hold that request. we do a proof on the pay network to say like hey like move this money into another non-custodial place that like basically in Visa's >> right as the charge happens so even though Visa is coming a week later >> on your side like to the user their fe their funds are gone they're out of their account >> and so the the the idea is that the ZK allows for certain rules to to take place so that it can it can still be sent back to the user cuz it could be refunded >> so we still need something but we want the user to not be able to spend that

money at that moment because we got to protect that money. It's kind of in escrow at that moment in time. >> And then once Visa tells us a week later like, yep, like everything looks good on our side, then we can move the money all the way to Visa or if not we can send it back. >> Cool. Okay. I think that really helped. >> Okay. >> Yeah. Thank you. >> Sorry. and and the connection between these two then like on your side you're dealing mostly with like ZKPs within the pay network but like the connection point to Visa is these non-custodial entities but that Visa can actually call like Visa can trigger >> we we do it on behalf so we're taking the liability risk but we know that everything is safe because we're doing that transaction on chain so we know that like there's no risk like Visa

doesn't care about that they just care that like pay as an entity is going cover the money that that someone's spending on the card. >> And they've already kyced their users, so they feel or like the users of this card. So, they're not worried about the funds being from like sketchy sources. >> Well, they're they've done Yeah, they've done two things. They've kybded Polybase Labs. >> Mhm. You guys >> they have also we've also been audited by Visa. So, this is a fully like audited and Visa approved system that we've built. >> Yeah. So when you authorize a transaction, you actually make a contract, it's part of a contract between Polybase Labs and Visa that if you say yes to a transaction, you have to send Visa the money.

>> I see. >> If we don't send Visa the money, they can come after us and collect that money. >> Okay. >> So that's why we have to be extra vigilant and make sure we're doing that proof at the exact time that the authorization is coming in. >> So the user can't double spend. They can't tap and then send a pay link at the same time. >> Yeah. Yeah. Yeah. Interesting. >> One question. You you mentioned like you have the liabil like it's sort of like in some ways you're kind of lending the user money and sort of like holding the liability that you own to Visa at the same time. Is there ever kind of like a race condition though like what you're describing where say the Visa network is like much slower than normal or like the payment doesn't go through where somehow

the pay link plus the Visa trans like like how do you deal with kind of like that type of issue cuz I could imagine there's like almost race conditions where like Visa is too slow to process but you've already processed the onchain piece or vice versa. How how do you kind of deal with that or and or like chargeback type of behavior? >> Yeah. So I mean in the case where the user is too slow and like we've already processed the the transaction, >> we can just send that back to the user. So like we have the capability to send them the money back to the user at that point. It's like held in escrow until >> Visa give us that final decision to to do that. And as I said we if we aren't able to do the onchain transaction in time, the transaction would be declined.

So like obviously our goal is to ensure that we can always do it in that in that period of time so that it's not declined. >> Okay, cool. And then how how do you deal with with chargebacks cuz like you do have to handle that as like one of the edge cases like is there anything special about dealing with that in the in the ZK sense? That that was sort of more my question or is it just like it's just a kind of invalid escrow return to state before type of behavior? Yeah, I think in that specific case like it's it's just like a a separate process where it's it's kind of a bit more of a a flow where Visa gives us the money and we just mint some money on our network from that money and we send it to the user directly. It generally only goes

that way like as a chargeback back to the user which is a net positive for us in our network and for the user. So Visa just like says oh like you gave us this money but here's it back here's the money back. >> Okay, cool. If you really if if you really want to get confused. >> Yeah. >> What happens when you go to a restaurant, your bill is $100, you tip $20, but the first authorization they charge for was actually only $100. So we we all know this dance, right? You go to the restaurant, they give you the bill, you give them the card, they swipe the card, you come back, you add the tip, they go back.

>> Oh, yeah. >> I'd like to say this is a dance you only do in America. Like no other country has this dance. Every other country is like you authorize for a certain amount and you pay the amount like >> just US is like oh no you can just like >> it's true that's funny. >> Uh and then if you want to get even more confused sorry I'll point because these are all edge cases we had to deal with and didn't realize like how complex these fiat networks are but not to like poo poo on the fiat networks like they're complex for a reason. So for example, you have refunds, you have partial refunds, you have a completed transaction that can later be refunded versus an in progress transaction that can be refunded within a certain time frame. So there's all these like weird

edge cases and money flows that actually are quite challenging to deal with when on the other side you have a non-custodial and immutable like system. >> Wow. >> So yeah, that's a lot of the complexity. It's it's something that I think when you first think about crypto cards, it's actually really easy to do a crypto card on a public network >> because basically the the whole account is public and so like anyone could just see all the transactions which is really beneficial for reconciliation obviously really bad as a consumer >> and so all of these challenges and all of these like fundamental things we had to build was because we have a private UTXO based payment network on the other

side, but it's a huge moat for us because there no other crypto card provider can just like slap on privacy. It's it's simply not possible. You have to fundamentally design it that way and then all these authorization flows with Visa, they have to be updated and that I mean Callum can speak to it was a massive undertaking. So actually like maybe walking people through the design of why you chose a rollup and like how you kind of designed that to meet those goals because I I I think like if you think about historical private payments there's just been so many versions of this that people have tried but somehow it it turned out that having some of the flexibility from a rollup was like

important for you for dealing with some of these interactions versus kind of having you know like I don't know I guess it's like somewhat ironic. I guess Visa wrote all these like Zether type of papers historically, right? Which like never got really used for private payments dealing with chargebacks and stuff. Whereas like it did seem like the rollup form factor actually helped you in some ways. And so maybe walking through a the design and b the decisions of like why do a rollup? Why why why did it make it easier for for going from zero to one? >> I mean we at Pay we didn't actually want to build a blockchain at the beginning.

That wasn't really our ambition necessarily. It was to like make payments work. And we looked at all the different things and criteria that we would need to make a payment system work. And to us like nothing else worked than a ZK Validium rollup, right, with privacy enabled in it. And so there are a couple of attributes that you're looking for. Firstly is obviously the privacy element that that you need. And I think as Sid mentioned like it's very very hard to overlay privacy on an existing public chain because they're so designed to be public. It's like you know even with tornado cache you have to have this whole relay system to enable these private transactions to occur because the moment you're interacting on

chain you're using an address and you're you're exposing some information about yourself. Even IPs can be tracked, right? Like in terms of okay, this particular IP is updating this particular account in a frequent way. Oh, they're in they're in this location. Oh, this is like probably this person, right? And so there's all these different ways in which you can like leak privacy out of yourself. And so having a UTXO model, which is really the only way to have true privacy, was really important to us. I think when you're dealing with privacy, like a rollup also just makes sense. Like I kind of said say to everyone like if you're dealing with a privacy system, you'll almost certainly need a Merkel

tree. I I I think it's like it should just be assumed baked in that you're going to have a Merkel tree because almost all of ZK is reasoning about some piece of information that exists. It's like you're never you're never actually doing computation to get an answer. You're doing computation to assert certain things against some data that exists. So it's like, okay, this data exists. Do I have enough money? Am I old enough? Am I do I have this authorization? Do I have this token? And so any ZK framework you should use should just be baked into a Merkel tree cuz that's just the assumption that that's what you have to use. And the other one is performance. So I know it's not sexy and I know it's like some people uh you know, well, we've solved we've solved performance in in crypto.

So like don't you worry about that. Like for me like it's like I think we really haven't solved it in dealing with these massive payment networks right like doing 10,000 transactions per second of ZK proofs >> having something where you can have a system which is highly refined for using ZK like our transaction times the reason we can do it in 1 second the reason that we can do the transaction whilst waiting for the visa authorization is only because we have our own network and we control our own block time and we can verify a proof proof in 0 point so 7 milliseconds or or less to verify a proof on a network to verify a proof any other chain takes an enormous amount longer because it's not optimized for

that use case right so even on things like Ethereum in fact we tried to launch originally rolling up to Salana and I like Salana and I think Salana's great but it just wasn't set up for ZK especially at the time so you you couldn't fit a verification of a proof on one block in Salana like it would overflow the like the block. You had to split it up and put it into like five or six blocks. And so yeah, like that that was kind of the reason for going with the design uh that we went for. I would say is like the privacy element, the performance element. Yeah. And I think I'll I'll insert like one or two more things. We're asserting that this is the only way to build a usable private payments network, right? It's a pretty big like

>> like assertion. >> Mhm. >> But we have 15 years of proof that every other way doesn't work. >> People have tried like insane like types of weird architectures and and things like that. No one's ever built a private payment product that like my family and friends can use. And no one has ever built it to connect to Visa. And I'll make another assertion here. Doing that will take, I think, other people at least two years, if not more, because it's just incredibly hard. You have to make these trade-offs that, you know, are are uncomfortable. You have to really focus in on just usability and not get distracted by the hype of the

next like trend that's going to happen. Right now, yes, it's stable coins and payments, but like next year it's going to be something else and all the stable coin chains will be abandoned and people will move on and raise other rounds. >> So like and there's there's no proof there's no evidence that that's not going to happen. In fact, all the evidence points to next year there's going to be a new trend and all these chains will become ghost chains. >> And we for 2 years have just been working on this even though it's been unsexy. And for the foreseeable future, until billions of people are using self-s sovereign digital cash that's private, we're going to continue working on this. And I think we're one of the few teams that can actually say we're going to do that.

>> So, actually, you bring up this the stable coin chain thing with, you know, obviously with all these people kind of like Circle and and Stripe launching launching their own chains. What do you think the failure mode of privacy is for a new L1 versus an L2? This is kind of what I was trying to get at I guess in terms of like the design decisions you made right? >> You know, obviously you gave an example of like, hey, maybe like the memory allocation on the L1 is not sufficient in the way that like you couldn't, you know, execute a full verification in a single transaction or like the op codes aren't optimized for doing this in like an efficient way in some some sense. But I'm kind of curious like what you think

the like L1 versus L2 failure modes are and sort of like what some of the harder things were to get right that you think will will inevitably much be harder if you had to start from scratch on a new network. >> I think I'll mention one like overview item and I think Colin probably has like good details on this. So the overview item is I think there's a big difference between corporate stable coin chains and everything else. So with Circle, with Stripe, those two chains are going to be tremendously successful. They don't really have to convince crypto Twitter.

They don't have to launch a token. They don't have to do anything. They will be fundamentally and inherently successful because these companies control massive amounts of flows. >> The thing is all of these stable coin chains are built for bulk settlement. In bulk settlement, you don't need privacy and or if you have a corporate chain, Circle can just provide the privacy. >> Yeah. Like an exchange. >> In a trad exchange sense. >> So, I don't think there really is a failure mode for Tempo. I don't think there's a failure mode for Arc. I think they're just going to have tremendous amounts of funds flowing through there.

I think the question we have to ask ourselves is, is that going to create self-s sovereign digital money for people and bring the power of controlling your money from institutions back to people? Cuz at the end of the day, that's what all of this is about. It's about a power play >> to take power from institutions and give it to people. >> That's literally for the last 15 years, that's what this should have been about. Um, and I think the answer is no. With those corporate chains, all the other stable coin chains, I think it's a big question on do they have the real conviction to continue building this in the coming 5 10 years, which is how long

it's going to take to roll this out to billions of people when all of them only launched once stable coins became sexy. >> So, I think you just have to think about that and reason about that. It's up to the listener to decide. But uh I would also say on those like those corpo chains like I imagine that that they're going to do a great job of like helping big companies like learn how to be on chain and then they're going to see like oh like actually we can do the real thing and they can like instantaneously move themselves over. It kind of reminds me of the early internet days, right? Where all these universities were like wiring like having their own internets or the companies would have their own internets and then it was like oh like actually it's much better if we can just connect

with everything else right like rather than being on this like protected corporate chain. Um and so I do think like this it's going to be a stepping stone for a lot of companies to kind of get their feet wet in crypto and in blockchain technology and then they're going to move across to the real thing. You guys didn't address the one thing though, which is like will they preserve privacy in your corpo chain. It's right now just like a promise, right? Like, oh, we'll have some private transactions, but I actually don't think their incentives are really aligned for for them to really ever have privacy.

So, like that was more what I was trying to get at is like do you think they will ever actually be able to really offer private transactions in the same way you are or do you think actually there it's more like lip service? I think the clear answer that I can give is no. I think the real answer is more nuanced in that they're not going to be able to win corporate clients if they tell a CFO of a Fortune 5000 or Fortune 500 company, by the way, like your payments are like fully public because they're going to find out. So, I think right now it's a tool to say yes, we have it. Like I read the ARC white paper. There's all of three sentences on privacy and it basically says, "Yeah, we think we're

gonna use tees, but don't worry, it's going to be modular and we'll think about it later." >> Like, you can go read it right now. I swear to God, that's what it says. >> And I think the point is to just have air cover to win these enterprise contracts and to convince other institutions to work with them. To be honest, they'll figure it out, right? They'll do some TE system. They'll do some probably not ZK because it's just too hard and it doesn't fit with EVM, but they'll do something, right? Or they'll do they'll do like proxy accounts or smart contract bulk settlement accounts or whatever. This is weird ways to get quote unquote privacy.

But no, I don't think they're going to have self sovereign digital cash privacy. And to be honest, I don't think their customers, their real customers are going to even care >> until it's too late. >> In the case of these stable coin issuers though, will you will those stable coins end up in pay eventually? Like, do you interface with them potentially in the future? I mean, you're already interfaced with USDC, so you are maybe it's not your you're not issuing it. I'm guessing you're getting it from somewhere else, but it's like, >> yeah. >> Yeah. Would you import that? Because on the issuance side, I mean, pay doesn't care. you can still have the private payments using those assets even if they've been issued by some public chain because it's not like the people who are

always using them have like gone through the steps of like generating these stable coins. >> That actually brings us back to the L2 L1 point a little bit because that distinction between an L1 and L2 I always find a little bit weird because people make such a big deal out of it like are you an L1, are you an L2? Are you an L3? And it's like it's really such a small >> You're an L3 actually, aren't you? I mean it depends whether you call Polygon an L1 or a side chain or an L2, right? Like it's it really dependent. But actually a rollup is really just a ZK bridge at the end of the day. So if you have your own security, so what makes you an L1 is security, right? Like if you have your own security, you're an L1. And and whatever you do to other

chains is a bridge. >> If you take the security from another chain, you're a rollup. That's the the primary difference between those two things. And so I think longterm the goal is for pay to become bridges to these other L1s and and for for us to be able to access the liquidity on any of these other chains because then you can just seamlessly bridge it on because we can we can verify the proofs on any EVM chain. >> You can effectively turn your L2 or L3 into an L1 by adding this security layer on top. Right? And that's what the token is going to enable. So we'll take the sequencer, we'll decentralize the sequencer, there'll be a token that powers that decentralization and then

all of the instead of being a rollup, we become a ZK bridge to all these other networks. >> And I think your your question was like what is the model for assets moving across these networks? So something I imagine will happen is Tempo will eventually host an asset that's like a payment receivable asset from Stripe, right? You could imagine they're going to like tokenize their payment receivables. They're going to put them on Tempo and there's going to be some cool like DeFi stuff you can do with that. You can actually just wrap those tokenized deposits or tokenized receivables on the pay network.

>> Mhm. >> You could do that today if we just built the bridge to the Tempo and then we just added a config on our side to allow that token type. And so that's very simple for us. We we don't Yeah. We just view ourselves as like the destination layer where you can actually use assets on chain in a reasonable and like private and usable way. Where those assets originate from, what economic security is on other chains versus our chain. Like that's all I think a distinction, but it doesn't really make a difference. I I think the reason I'm bringing this up is like if you go through ARC or Tempo like they they explicitly state that they need their own L1 often times justified in some ways by like privacy

and like validator reordering right like basically if I distilled everything down to two things of like why launch your own from scratch those are like the two main >> it's being able to like work with a validator set in the case you have to do like roll something back and privacy >> yes that's basic like as far as far as I can summarize >> my understanding like that's basically the only two things they care about. So like not a blockchain >> and in some ways you're like yeah in exactly in some ways it's like kind of yeah >> the one thing >> and so I I guess like the reason I I think that's interesting is like that notion is being called like L1 sufficiency or L1 necessity like you need to be an L1 to do that but at some

level you're not you're not even like an L1 then right like to your point earlier is like it does feel like it's a little more like kind of a centralized POA >> it's just a database. Yeah, it's a database. >> Can we be honest about this? Can we just really be honest about this? It's a database with the air cover for stripe to say, hey, like don't worry, it's a blockchain so you can trust us and it's going to be neutral cuz if they did that on a Postgress server, people would like not trust it. >> People only trust the Post or they're not even Postgress. What are the what does JP Morgan run? Like Oracle or some weird thing inside of a Cobalt server or whatever, right? Like people trust that.

People are like, "Okay, when JP Morgan says it's in their database and it's this amount," everyone's like, "Great." Like, "We believe that." >> Wow. >> If Stripe did it, uh, some people would believe it, but a lot of people wouldn't. And so, what a blockchain allows them to do is to compete with a banking ledger for li legitimacy. But I think anyone that's been around knows that that is purely a control play and has nothing to do with technology or capability. M and that privacy component though just going back to what you're saying Tun this like idea that one of the reasons you do the L1 is also for this privacy I mean in discussing it it sounded like privacy will probably be an afterthought like how are they currently planning on offering it like just by

being a blockchain does not give you privacy it's like pseudo anonymity but like >> I think the thing is you're never going to have privacy from the validators in all of these setups right >> privacy from the validators okay it could be privacy from the public but not from the validator. >> Exactly. Fundamentally, you're going to be able the validators can either collude or depending on the architecture individually decode the transactions before they reach the TE, right? Like so I don't really see how you're going to have end to end privacy. You're going to have this kind of like it's private when I send it. Perhaps it's private to the public posted chain, but like the validators can definitely should be able to read. Maybe not easily, like maybe they have to do a bunch of work to do it, but they should I my suspicion is

like that's sort of the the threat model. >> I think I think the validators aren't going to have any incentive to do this because they're all Stripes friends. >> What incentive to offer privacy? >> No. No. To decode >> to like if I'm a validator on Stripe's network and the fees on the network are paid to me. Likely, first of all, that's not going to cover like the fees are so low that it's actually not going to cover computation costs. So, I'm doing it just to like build some kind of relationship with Stripe or whatever. I'm not going to shoot him in the foot by like selling that data or decoding that. >> Yeah. The difference is more like if a government came and was like, oh, we think this is secretly a entity controlled by a sanctioned entity or whatever, right? Like >> I think like you basically run into the

like, okay, like our only compliance tool is like having the validators decrypt everything. >> And they could. >> Yeah. I mean, in that case, like they would be legally compelled to do so. I'm just saying that like that's what I mean. It it it feels like the L1 is not really necessary for for this type of privacy. It's just like a cover type of thing. >> I think it would just be kind of like if Stripe was like, "Oh yeah, we're going to use Ethereum or like we're going to use Salana." It would just be like it wouldn't make sense because institutions could just directly use Ethereum or Salana and they would have already if it was valuable to them. So I think like it would be a non-event or like a nonproduct for them to do that. And so like they have to create some product. They have

to create some thing new that exists and the only reasonable thing to do is clone EVM. >> Isn't the reason that they launched also just cuz everyone looks at Tether and goes like I want that. >> I mean there is tr there is truth to that. But if you look at the graveyard of stable coins, I'm not sure that there is a way to summit Mount Mount Tether. It's it might be the world's most inhospitable mountain. I want to go back to the pay system, the pay system itself. And you had mentioned earlier these edge cases and all of these things that you built to manage them, but you didn't actually say how you do it. So like I don't think we need to go through each one, but I would love

to check out how you're doing one of them. Cal, thank you so much for earlier like walking through exactly what one of those things looks like, like a transaction and how quickly and what's happening and it's a week later. This is really good, but what about that case where what did you like pick pick a really complicated one and then tell me how you actually solved that >> specifically for the card program? >> Yeah, >> let's do like partial refunds. That's a fun one. >> Yeah, something like that. You had mentioned a bunch of like weird edge cases. I like them. >> Okay, partial refunds. So, for a partial refund, it's actually interesting because in a in a card program, you get basically two different things. You get a refund if it happens within that 7-day period. So, as I mentioned before, you get the authorization and then you get

seven days later like Visa says, "Yeah, everything went well and you can clear it up." >> But like what happens when you go back to the store and you want to like get a refund on the eighth day or the 9th day, right? Cuz most stores will actually give you a refund 30 days later. >> So, it's gone through and Visa's been paid. >> Everything's everything's done. And so, from Visa's perspective, they're like they forget about that transaction as if it never existed. >> You can't touch it. You can't change it. It's ledgered in their system. It's like it is actually a true kind of blockchain thing from their perspective. Like you cannot change it. >> Immutable. Okay.

>> It's immutable. Yeah. It's it's immutable. If you want to do a refund, they're just like, "Oh, hey, like this company wants to send some money and they don't like tell you that it's like actually a refund. They're just like it's a negative transaction." So, obviously, you have to detect that like, "Okay, this is negative money. They're sending me some money." You then have to show like, okay, like this is that's the same vendor as I had before. Okay. Like linking that up. You also have to think like does this make sense, right? Because you can also get a refund to a completely different card and that's a valid thing to do, right? Like so you can go to a hotel, pay with one card and then be like well I lost that card like I actually want it. So that would be a high risk scenario where you would have

to think about like whether you want to allow that transaction to go through and there's a different risk factors and and vectors that you want to look at there about whether you authorize that transaction. Again, we only get say at the authorization. So, we have to like make a really quick sharp assessment as to whether we think this is a good transaction or a bad transaction during that 1 second period. >> Yeah. Would partial refund just be like Visa sends your escrow account money and then you guys have to figure out where it goes. Is that kind of how you deal with it? So a partial refund is actually like what we would consider a true refund, which is that in fact they just really just send a new transaction through and just be like, "Oh, hey, the the amount changed." Like they don't really they don't tell you any like new

information with it. They're just like, "Oh, hey, look, this is the amount we're charging now." And they can do that within that 7-day period until they complete. And that completion can take anywhere from like one day or it can take like up to two weeks. So it's it's a variable period and we obviously have to manage that. But if it's within that that period before completion, they just change the amount and then they're like, "Okay this >> within the seven days, they just change the amount." But if it's after that, what do you do >> again? They just give you the money. They just like, "Hey, like this transaction just came through and it like they don't link it with anything else that's happened. They're just like, "Hey, like we're going to give you some money."

>> But how do you I mean, this is kind of going back to that question of like which part of the system is private. Like how do you know which part of the Merkel tree to reimburse? I know that's not how it works, but like Yeah. How do you actually then move those funds back to the correct address? >> Yeah, so we have like like I guess like an address system that we can use to like send funds back to the user. The address system doesn't mean anything because we can't see any addresses as I mentioned before, right? Like address is like a weird concept. So basically when the app pings online like we have an ID that we use that we associate it with a KYC car user and when the app comes online it basically says like hey I'm this ID and they send a proof. One of

the cool things is like we don't actually use like passwords or anything else. We we send a proof for authentication. So like the the phone does a proof to be like hey I want to log into the system and it's like I know this private key that's the proof is like the most simple proof. It's literally just like private key hashed is the address and they send that through and they're like, "Okay, this is my address. We link that address with the KYC, but that's not linked to anything on chain that we can see. Like we can't see any addresses on chain, >> but you are sending sort of funds back and forth." Yeah. >> Is there ever a case where you end up like basically the question I'm kind of leading towards is like is there ever a case where like you've put more in to

something and you're actually earning off that thing? Does that ever exist in this system? So, I think your question was like in this card settlement system, does that exist? And the answer is no. Okay. >> We don't like mess around with trying to like optimize yield on these like, you know, we have like $100 for half a day, we're trying to get yield on it type stuff. >> That really only works at like bank scale >> and make meaningful money. So, and I don't think we want to do that anyways. >> What we are going to launch is the ability to earn yield. We haven't announced through which protocols or methods, but and that's going to be really a really cool announcement and so we'll hold off on that. But yes, yield is coming.

>> Can we walk through the mechanics though because I do think it's kind of important for people to understand like I'm on the rollup. I have private assets but I'm going into like a public yield bearing pool or public yield bearing set of assets. So there has to be some shielding and like sort of pooling mechanism maybe like tornado looking in some way or not like how how do you envision the kind of like I have shielded asset I go into a pool and then I go to a transparent public pool that's earning yield and then I kind of come back and I you know like walk us through that process because I do think that is something that is novel that a lot of existing ZK stuff hasn't really done.

Yeah. So I mean anything on pay network is effectively pulled. So the USDC that we hold is pulled on Polygon. So we use Polygon USDC. So it'll be the same effectively we'll do the same for the asset that we use for the yield bearing token. So all of the money that's on pay network is actually pulled into one pot. So when you want to bring on that yield bearing token onto pay network, it gets added to a pool and once it's on pay network, there's no visibility as to like which specific user has how much of that pool.

>> I think one one thing that's really interesting about our position is there's a lot of other apps out there who potentially want to do a card program and they need to make money from that card program. Like our vision is much bigger than a card program. Like a card is one component of being a non-custodial bank and that's really our goal is to is to provide all the services and things that you would expect. >> Wow. >> Um and so I think our long-term goal is really not to make money on the card program. It's it there's so there's many other ways to our network will generate funds for us without us being having to do that. So yeah, you know, things all the fees that you would normally pay and all of the things like interchange for example, like we're going to give that

back to users. So I think yeah, like there's a lot of things that we can do because the way we've positioned. >> It's funny you say that about the card cuz actually one of my questions was a little bit about the competition on the card front. I think pretty soon after you launched, there was another card that rolled out with like the same color from another network who maybe won't be named, but I wondered kind of like what differentiates you, what keeps people on it. And maybe I'm a little focused on this card and you're saying it's well, it's it's this is just one component. >> Yeah, it was funny that and by the way that it wasn't a real launch like someone posted a few like graphics of branding. Uh, but they're like, "Oh, like a card." And then I don't know why they said also like privacy on there cuz

they said it's going to be no KYC and you can't do a real Visa card without KYC. You can do you can do gift cards by the way. >> Yeah. >> Um, but like the UX around gift cards is like really bad >> and they're very limited on where you can use them. >> Anyways, so back to your question, >> what's the differentiator? I think it's it is privacy and fundamentally that is ZK >> and like we've mentioned it's really hard for other people to like add this in as a feature and so I think it's a very large moat for us >> and I think as like more and more people start using crypto like in their daily lives it's going to come to a head where like there's going to be a moment like just like we had with online data

privacy uh and Facebook like using data to do like election you know data analysis and and propaganda and all that kind of stuff like Cambridge Analytica that's going to happen in crypto and it's it's inevitable. >> Yeah, >> it's it's so easy to index and we already have Google indexing multiple blockchains. Pretty sure Facebook is doing that too. I've heard whispers of this. I don't know for sure given they do have blockchain talent kind of there. >> They used to. Yeah. >> Yeah. >> I mean Google does now but Facebook used to. >> Yeah. From what I know the team is very small but they've still like had those people there. And and by the way, I've mentioned this once or twice, but I want to like really mention it here. Today, stable coin payments are financial

transactions that are fully public and visible on chain, >> right? Like send USDC on Ethereum and whatever. >> According to GDPR and other data privacy laws, financial payment data needs to be protected in a way that it is not public. That's like literally like written in GDPR. It's law in the EU and it's law in many states in the US. >> Yeah. >> I don't know how anyone's reconciling those two facts. >> And so the big question I would pose is are stable coins even legal without privacy?

>> Because once they're stable coins, they're not like these funny assets with value that fluctuates. It's considered a financial transaction only, not like a purchase. >> Yeah. It's it's a pay. If I send you a stable coin, that's a payment >> and if it's fully public or someone's enabling me to make this transaction and is fully public, they're not sufficiently protecting the data for a payment system, which is something that's required by GDPR. >> Just want to put that out there and like stew on it and uh think about what that means. To be fair though, like I feel like if we're being bluntly honest, most of the world doesn't really follow the European definitions of anything

anymore. And like 99% of stable coin growth is like Asia and the US nowadays. So it's like it's kind of like everyone kind of laughs at Europe on this and like kind of says go back to rewriting your 500 different laws about stable coins that are inconsistent with one another. For better or worse, this is true. GDPR is such a road to hell paved with good intention. >> Yeah. Yes. >> Like it was like it's such a good idea. Yeah. We should protect the privacy of the users and what it ended up being is just like a mess and it doesn't really >> I think I think GDPR was great. They should have just dropped cookie banners.

>> Then we wouldn't be as annoyed by it. Yeah. >> Like if they just dropped cookie banners, I don't think any consumer would bat an eye about like anything GDPR related. But yeah, like to to your point there, like yes, I I agree with that. But given that these payment systems built on top of stable coins are global and they do interact with European consumers and coupled that with like other countries have started putting in similar laws. Uh like I know for a fact that India just recently in the last 6 months put in a similar data privacy protection law. Uh you're going to start seeing that in more and more sophisticated countries in Asia and stuff like that. So yeah, maybe a GDPR is a bit laughable right now, but you it's still law. You still have to follow

it and it's illegal if you don't. >> So we are at time and we're going to wrap up the show. I actually had a few other topics I wanted to talk about with you folks like doing privacy in 2023 when it was like very unpopular. Why did you do it? or the sort of ZKID, something we've talked about a lot on the show, I feel like starts to overlap a little bit with what you're talking about where the KYC lives somewhere else and you have these attestations basically ZKPs proving that you're allowed to be in a space. Yeah, it's just there's there's a bunch of topics that I feel like pay kind of touches on.

We didn't get to, but hopefully we get to do it in some future episode or session or something like that. But I want to say a big thank you for coming on the show, sharing with us the story of pay, the focus on private payments, how you've built it, kind of the complications and some of this other conversation about like the general space. Yeah, thanks so much. >> Yeah, thanks. Yeah, thank you for having us. It was great conversation honestly. >> Thanks for coming on. You know, I think somehow people always think payments is like the easiest and most boring application of blockchains, but yet it's still the one that every few years someone is like, why can't we fix payments? So, it's uh it's it's always good to to kind of see something

tangible and also in a fun color that I can get behind. >> Nice. All right. I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Hector, and to our listeners. Thanks for listening. [Music]