The Evolution from ZKP2P to Peer with Richard Liang

0:00Welcome 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. This week I catch up with Richard Liang from Peer, a project formerly known as ZKP2P. ZKP2P initially came out of an event that we hosted called ZKHK Lisbon, and we last caught up on the show about two years ago. In this episode, Richard walks me through how the product has been iterated and expanded since we last spoke, starting with ZK email proofs on Venmo receipts, moving to ZKTLS, and most recently they're switched to TEs. We discussed the reasoning behind each shift, including the trade-offs around privacy,

1:01trust assumptions, speed, and the idea that some use cases only need short-term privacy rather than permanent guarantees. We covered the rebrand from ZKP2P to Peer, state of ZK adoption more broadly, and how the team is using AI internally today. Hope you enjoy. Now here is my interview with Richard Liang from Peer. Today I'm here with Richard Liang from Peer, a project that was formerly called ZKP2P. Welcome back to the show Richard. Thanks for having me, and I'm excited for round two. Yeah, so we actually had you on the show two years ago. We were talking about ZKP2P. I'll add the link to that in the show notes. We knew you actually as one of the projects that came out of ZKHK Lisbon. I think in that episode we talked a lot about forming the company, forming the project. We talked a lot about the forming of the team, the ideas that you had, building it out, and sort of your first iterations. Back then, you were

2:05primarily using ZK email, and I think mainly the Venmo system. I became an investor soon after that episode, I think. I feel like we have a good snapshot that I'm going to share in the show notes, but I would love to use this interview to catch up with you. I know that you've gone through a bunch of different iterations, but the product you've done a rebrand. I'm excited to start. I think maybe a good starting point would be to go back in time a little bit to that product. What has happened since? What was your thinking back then and how has that evolved? What were the different iterations you took along the way? A lot of things have definitely happened since then. Back then, in 2024, we were running a lot of experiments and trying to push the frontiers of what we could build with ZK in consumer applications. Back then, we were proving that you have actually sent a Venmo payment and received an email confirming you've sent a payment to someone else and using

3:12the DKIM signature of an email and using ZK to prove that and then submit that on-chain in order to do some action. In our case, to release some USDC, effectively, it's an on-ramp transaction. I remember it was this two-way transaction. On the traditional side, you were sending money. Money was being transferred over Venmo. Then on-chain, money was being transferred in the other direction on-chain. It was all connected through this ZK email glue. Exactly. The first step was a seller of USDC on-chain wanted to receive something in Fiat and Venmo. They locked some USDC into a smart contract. Later on, a buyer comes in and basically says, hey, I want an on-ramp. How the buyer does it? They pay the seller directly on Venmo and use a receipt of the email as proof to unlock the smart contract

4:15directly. In fact, then, you talked about, I don't know if we had ZK email on before or after. I can also take up that episode with I use, but it was brittle. It was cool, but I just remember the conversation being something like if Venmo changes the format of their email, your system breaks, which is problematic. Exactly. It actually did happen. Oh, really? I don't know how soon after the episode came out. That then, but yeah, that happened. But luckily, I think we were moving into alternative methods. Yeah, so what happened next? Where did you go after the ZK email? Did you end up just sort of shelving that and being like, this is cool, but we need something more sturdy? Do you still use it somewhere? We're looking at the other kind of like provenance proving, authenticity proving kind of solutions out there at the time. In particular, we were looking at TLS notary and a lot of the proxy ZK proxy work that reclaim, I think opacity, Pluto, back then were working on as well.

5:19Because we knew that one day, yeah, ZK email could break. Yeah, and did, apparently. So talk about that transition over to the ZK TLS stuff because we've also, over the years, covered that quite extensively. So what you're kind of like a user of that technology? How did it work? How did it not work? What happened with ZK TLS? So the main ridleness came from the email template changing and we needed to move to a more stable kind of solution. And the solution was basically to prove API responses instead of emails. And API responses, especially private ones that like VEMO, whatever cash app all these Fintech platforms have are way more stable and they don't change. So that fixes a lot of the brutalness issues that we're running into while building kind of consumer application. And in particular, I guess ZK TLS used, yeah, a lot of the like privacy preserving techniques

6:21that ZK E-mail has that we liked. And it was a new technology that came out back then. So we were really excited to test it out and push the frontiers on that as well. What did you use it for? Like, where was it used in your product and with which payment providers basically? Yeah. Because like, yeah, all I knew back then, I think it was VEMO and USDC. And then it was also, what was it? UPI? Yeah, UPI. It was the Indian INR payment rails. Yeah. Okay. So once you started playing with ZK TLS, what happened? Like, where was it being used? It was used as a replacement for ZK E-mail for us. So instead of the user providing a receipt of a DKM like signed email from VEMO, it was still VEMO. But the user now generates a client side, I guess, proof that I did called this VEMO API, got a response on it and able to prove that the response contained

7:22like certain fields like that now, the recipient, the timestamp, stuff that is required to unlock the USDC in the smart contract. And did it work? Yes, it worked better than VEMO. There was still obviously some hiccups with new tech. But yeah, switching to API responses is definitely a lot more stable. But at the same time, it was still using, I guess, client side ZK proofs. So, growth 16, running in your browser. And then that could differ quite a lot depending on how powerful your laptop is. Did you feel like was there a flowed out? Like, was there noticeable UX issues because of that? It actually improved off of ZK E-mail if we were proving ZK E-mail client side. I think how long that took was like nine minutes to prove the email circuit directly in browser. So, when we were back using ZK E-mail, we were proving it server side, which was kind of cheap. That took 20 seconds. And with ZK TLS, it was probably around that interval too.

8:25I see. But you were actually doing it on device. Yeah, exactly. That was the change. Okay. But then, are you still using ZK TLS today with some systems? No, that's another time jump in our journey. The big... Okay, maybe tell me what happened in between. Feel free to just go chronologically if you want. But yeah, I'm really curious where that gets also swapped out and why. So, we stuck with ZK TLS from basically the start of 2025 to a couple of months ago. A year and a half, I would say. And yeah, we were able to add a lot of different payment providers powered by this exact mechanism. But yeah, at a certain point, like up until a few months ago, felt that we needed to get a lot more reliable. If we were to get a lot more non, I guess, crypto-native users using us. And that's kind of where the switch came in.

9:26Dun dun dun. Where did you switch to? What did you switch to, rather? I don't know if I can mention on this podcast that we did make a switch to TEs. That we currently deploy ourselves. So, it's entirely our own infrastructure now. So, is this no longer a client side? I'm trying to picture what the flow looks like now. We still use Venmo as an example. I don't know if there's a more relevant one. Yeah, Venmo is probably the last one. So, somebody has funds on Venmo and they're going to send it somewhere in order to get USDC on chain. What is happening? Because I do remember and I will again recommend that listeners who haven't listened to the first episode. Please do because we do go into more detail about ZK email exactly. Can you walk us through the sort of user path in the new system? Yeah, before I do that, I'll mention one nuance about ZK TLS as well. We did talk about the user still generating client side ZK proofs. But in ZK TLS,

10:31those proofs are actually not being sent directly on chain to unlock the USDC in the smart contrast. They are actually as well as all the ZK TLS systems. The proofs are being forwarded to a tester proxy in the middle. I remember that the proxy actually verifies the proofs and attaches a signature on top that then can be verified on chain. I guess the reason for the tester in the middle in ZK TLS and also in T's that I'll go into is that there has to be an intermediary proxy in the middle to a test to the web too, like the off-chain API call. That is not possible without someone like a service in the middle because there are no signatures on API responses. That's true for ZK TLS and T's. Let's do that flow maybe. Let's use T's and I know we're skipping over the way that ZK TLS

11:34worked with it. I'm just curious to hear how you're doing it today. In the T flow that we have, the VEMO buyer of USDC, they come in, they make the payment still the same as all the previous flows. Now they basically log in to VEMO to intercept the API response. With that session material, they encrypt that session material with the tester or the T's upload key that only the T holds. Once that session material is forwarded to the T, the T, the crypts it, validates the authenticity of that connection by replaying it and then lastly it attaches a signature and sends it back to the user that can be used to unlock USDC. I see. I guess the question I did have was, is ZK completely stripped out? It sounds like it is? Is there a proof anymore? Yeah, there's no ZK proof anymore. There is an attestation.

12:38I see. Is the only thing remaining? How does the user actually intercept this VEMO session material? Are they using your interface that's behind the scenes VEMO or they in VEMO specifically and they're actually active in there? In our case, they directly use VEMO, but on desktop, that requires installing the peer extension plugin. In the extension, there is that ability to intercept incoming web requests and be able to offer a much better UX for the user. The alternative is the user basically has to inspect Chrome developer tools directly and copy and paste. Which is probably no good. Is peer then a new within the VEMO ecosystem? Is it something that a VEMO user can see and can find in a store or how do they get it or do they have to manually install

13:40it? No. Basically, what we're able to do with peer is not work with any of the underlying payment platforms in order to generate proofs. It's all user driven in that the user installs, I guess, the peer extension. The user initiates a login to their own VEMO account on web with the extension and then the user generates that attestation or calls that attestation themselves. Okay. So the extension is grabbing what you need in order to unlock it. But for the user, would the flow feel quite easy once that extensions installed? Yeah. So the extension is purely, I guess, on client side for the user to give them better UX. So we do try to do a lot of things that basically after you install the extension, you don't need to care about anymore and see it anymore and it's entirely headless. So further, like, second, third, fourth on-ramps, the user doesn't

14:41even need to know the exact mixes. No, cool. Okay. So that's kind of describing the way that the T is now incorporated. I do want to ask kind of like, what's gained and what's lost? Like, have you lost privacy? You no longer have the ZK proof? I don't know. Like, maybe it wasn't so private before either, but can you talk a little bit about like those that trade-off space and like, what do you feel you like lost? What did you gain? So the main difference is that now the user basically has to trust the T to preserve privacy for the end users, like session, the most session. And they're trusting your T's, right? Like, T's that your server, like, you're running them, not it's not like the T on the user's device. Yeah, yeah. Exactly. We're using AWS Nitro. So you're basically trusting AWS to protect their T's got it. Okay. So the trade, that's sort of the negative like, now or T's, the hardcore cryptography, ZK people won't like that because T's get broken sometimes. And, but what do you gain?

15:49Like, why do that? You're underlying, I guess, privacy assumption changes, but the same privacy still exists where no one else can see your session material except for, I guess, the third party box. But we do gain a speed in that we go from like 20 seconds to generate ZK TLS proof to like 300 milliseconds essentially. Okay. And we also gain a lot of programmability that can talk about more in that you can do a cool new flows with T's that are not possible in ZK. Yeah. ZK. Yeah. Where does the attestor live? Does the attestor live in the T that you run? Yeah. A tester lives entirely, I guess, in the T. Okay. And what, what is it? So I'm just trying to picture like, what is it doing? Is it sort of like getting this session material from the user and then checking it or doing something with it and then sending something back to the user or does it go directly on chain? Yeah. I don't fully know

16:51what that attestor looks like. So does the same things as the ZK TLS attestor in that it receives that material? But within the T.E. since it has the private key to decrypt, it decrypts that material season tire plain text, I guess, and then replays, I guess, that API call into like VEMO servers. Okay. So the T will know that, hey, like this connection is authentic. And then we'll also like kind of redact a go out of the response, response stuff and attach a signature to it. So it only signs on like amount recipe and timestamp stuff like that to ensure like we have enough stuff to that the user can then submit the signature directly into the smart contracts. Does the attestor send something back to the user? Yeah. Yeah. It attaches the signature. Okay. Like it's just, I think it's just ECDSA something that is easily verified. And then that signature is passed by the user on chain to unlock smart contract or to create an action of some kind. Yeah. Cool.

17:55Okay. So the trade, the only tradeoff you shared for the T's is like, it's a T.E. But in rebuilding it, like was it a ton of work to do? Did you have to rethink a lot of the architecture? So the architecture is actually simpler than a proxy like with ZK attached. You shift a lot of assumptions from like cryptographic primitives to like the actual, yeah, the hardware are you're securing it, but the actual programming of it is actually simplified. So we're actually more confident that there's less bugs in the T.E. But was it hard for you guys as a company to let go of ZK? Like I'm just kind of curious what went through. Like what kind of conversation was happening? I mean, you're founding story definitely had ZK in it. And you sort of were on the ZK train. So yeah, was it hard to do? Yeah. We were all in on ZK and ZK primitives for basically the

18:56first two years. But I think as ZK primitives and proving time get faster, it's actually very easy for us to switch and use a different primitive. We're already like very primitive agnostic in our like smart contracts. And we basically used all the primitives out there today. Yeah. And I think it's just the matter of like, can we offer the same UX to our end customers and users? And without like sacrificing a lot of the trade offs that ZK has today. Do you feel like, I mean, just in the industry, there's been like this shift towards the users towards making things easier, like kind of at times at the expense of sort of a decentralized system or at the expense of privacy. What are the pressures that you guys were experiencing? And I'm not saying because I do think you still have some of those things. You still have privacy. But like, yeah, are you, did you, did you start to sort of change your philosophy somewhere along this journey? We're like, we've always been pretty practical on, hey, like what's available today and how we

19:59can maximize like what we have today into serving our users. Like when we made the trade off and switched over to TEEs, we, or I guess when we switched over to TEEs, we felt like the trade off wasn't that big for users. A lot of our existing users were like, I guess, transacting like $500 or less, not like securing like billions on a ZK blockchain, for example. And furthermore, with our exact flow, users are like, just need a framerale privacy. So none of like the like a long like serving kind of permanent like privacy, like guarantees are like stored directly into TEE. You basically only need like one second of privacy to ensure that like the VEMO endpoint is a test it, for example. When we felt like the trade offs were like really not that big at all. Yeah, I've heard about that word. It's like, I feel like we have covered this on the show before. This idea that if you are doing sort of like a very short term private action,

21:00something where it's like in and out of a system, you're not really worried if like down the line that information gets leaked because whatever you needed that privacy for, it's kind of finished. Whereas if you have these like long term privacy kind of items like ID or your balance on a blockchain or yeah, I don't know like how much you paid your employees like these things that if they were discovered even in the future, it would be bad. You don't want the and like there's a record. There's like a trace that could be seen. Yeah. In those cases, I feel like these more ZK like full privacy like no exception. I feel like people really have a strong case. But in those examples where it's short, I feel like a lot of the T cases that we've spoken to people about end up having a bit that feature that they're a little bit more about like that. What did you say this or a femoral? A femoral privacy. Yeah. Yeah. So what we're proving is basically the session. Again, so the session with the session cookie with the request headers, they only last like

22:05traditionally and like these banking websites probably like 10 minutes. So as long as someone is not next to Tee listening for that exact like one second of like request replay in the Tee, then we're pretty safe. As well as like a lot of the stuff that we do are like traditional, I guess like APIs which have their own session limits, rate limits and also protection. Whereas like a lot of the, I guess ZK in crypto are like yeah, like blockchain, securing large balances that are not reversible at all. So I guess the traditional like side channel text and Tee's don't really apply to I guess what we're doing. So like let's theoretically say the like T's are completely broken open and someone is able to look inside during that one minute window. What would they do? Like what would it do? Could they get the attestation output? One thing they could do which they're able to do is read I guess exactly what we're proving, which is hey, I like can see you're like you transfer like

23:11this guy 500 euros. For example, on Revolut. Typically, I guess in these banking fintechs, like the right endpoints is like secured by like a OTP or a 2FA. So like even if they took the session material, they can't really transfer funds out. And even if they could, then I guess it is like off-chained fiat. So you can just call your bank to reverse the transaction. Yeah, true. But could they technically like theoretically intercept the attestation or the attestors output? Do you know what I mean? Like the thing that the user needs in order to unlock on chain? It will be in memory so they would have to be able to inspect directly what's in flight as like none of the attestations or signatures are stored anywhere. But yeah, they would be able to I guess use that signature to unlock. But everything that we've kind of built within the protocol is that like it's committed to during like when you start the order. So the actual signature would just I guess unlock

24:12funds for the user. Is the on-chain stuff still on Ethereum? Do you still feel like part of the Ethereum community? Or do you feel like you've stepped much more into the banking land? Because it really, I mean, to me, peer, especially with the rebrand, it has this much more like agnostic, like web 3 agnostic or web 2 agnostic. It sort of seems like it can live in both worlds. So I guess there's two questions in there. One is, yeah, is it still USDC on Ethereum? And two, like do you agree that you are sort of starting to sort of shift focus? Yeah, so it is USDC on a layer two where I'm base right now. And yeah, we peer is kind of the bridge between traditional like Fiat land and also crypto Ethereum. We are very much I guess crypto like ethos aligned though. Like the stuff that we're building is very some versus kind of cypher punky. Like you're going directly on-chain and directly off-chain without a middleman at all. Yeah, except for this at tester,

25:15but the tester is sort of a dumb middleman. It's not like a it's not like a exchange where everything is visible and yeah, it's like the sort of private actor. Yeah, exactly. And I guess there are also ways we could potentially, I guess, decentralized the need to have a single tester that could be coming. And yeah, a lot of like the extra like editing, like stuff you have to give to like an exchange in order to KYC with the store. You're basically KYC in plain text. All that is eliminated. It's kept private between the two parties. Yeah. Kind of interacting on the protocol. Although, don't you sort of like benefit from it being interfaced with Revolut Fennmout? Like those companies have sort of done their own checking of some kind for certain amounts. So like any user of those, have they already sort of passed some of those tests so you don't have to do it? Yeah, exactly. So we don't do any additional, I guess, extra like identity checks because,

26:15yeah, the Vemo users, the Revolut users, they've already passed. They're like pretty strict KYC. And all the transfers within our system are kind of within their ecosystems. So it's very closed looped. Nice. And as a result, we don't need to do anything extra. Yeah. What are all the platforms you actually enter like that you work with? So we just mentioned Fennmout and Revolut UPI. Did you end up continuing that or did you stop that? We stopped UPI, but we will, I guess, re-enable it at some point. Okay. A UPI was also built on CK email back in the day. Yeah. Yeah. We haven't enabled it for APIs. But yeah, other platforms, we're still mostly EU and US, I guess, centric with we have like Zell, PayPal, like Chime, CashApp. And then in EU, we have, or UK as well. We have Monzo and 26. Repeloo obviously. And yeah, just a couple more, Alize, I guess. I think mostly is it mostly banks then? It's like banks or money transfer.

27:20Yeah, it's like Vintechs, Neal Banks, where you can make like pure to pure transfers with each other. Are there other, like you sort of hinted at some sort of program, programmability because of this TE. What can you do with peer? The one thing that we've added into the protocol since we've launched TEs is that sellers, like the people who lock the USVC into Smart Contract, they can also encrypt their like session material or they're like Fintech API keys and have the TE read from their balances or their transaction history. So what that unlocks is the buyer comes in, they make the payment to the seller just says before on Vemmo, for example. But instead of them needing to download extension, logging in to their Vemmo account, they just hit the sellers pass transaction history via the attestation or attestor in the middle. And as a result, there's no buyer proof needed. Okay, so the seller basically does the proving because it's

28:24received the funds on Vemmo. Yeah. Yeah, exactly. What is the difference between these two players? Like who are they? Are the sellers, for example, are they more like market makers? Are they like professionals? Both sides are, I would say, like retail. Okay. The sellers are either trying to off-ramp fast into their direct directly into their Fintech account or they're like trying to set a small premium and earn like a small spread when they like off-ramp or like sell their USC. And then buyers are obviously they want to on ramp to crypto or they like are just making kind of a payment as part of like a checkout flow that we built. And then the merchant basically receives the USC on the other end. Do the payment platforms, do they see anything? Do they get any info as well about like what's been executed on the other side? Is there anything that's sent back? So the platforms can definitely just see the transfers between the buyer and seller. Yeah.

29:26But they to them, they just see that hey, it's just a traditional like peer-to-peer a transfer. But they could in theory match that transfer look on chain. Yeah. Do some like timing analysis to see that hey, these two people transferred the somehow. What kind of amounts do people actually use peer for? Like you sort of mentioned, it's like usually around 500. Is it mostly small stuff or smaller amounts? Yeah, the average transaction size is I think 200 right now. So very small. Do you have a maximum limit? Like do you kind of limit how much you could offboard here? So on the smart contracts, the protocol layer, it's all up to the seller or the depositor of the USCC. So they could set up a limit or set a lower limit. Typically, all the transactions happen under 5,000 per transfer. Okay. Why don't people use it for bigger amounts do you think? One is definitely the Fentech accounts just don't allow larger transfers. They're not wires, for example.

30:33I think Vembo has a $2,500 limit per user per day. But why is you can do pretty big transfers on that? Yeah, that's right. Yeah, it really depends on the platform. Do you want to kind of cap it? Do you want to keep it small? I think what we're best used for are these medium to smaller amounts because you can instantly, 30 seconds, get money somewhere. Whereas if you're transferred in like 50,000, 100,000, millions, you're probably okay waiting a day with a wire to a centralized intermediary. Yeah. So a few years ago, we had these very active groups. PSE, they came email was sort of rolling out a lot and being used a lot as the KTLS. But in the last few years, really in the last year or so, we've seen a lot of shifts. PSE, I don't know exactly at state, but I feel like it got renamed and then it got re-orged again. It has felt like a bit of a contraction. It felt like the institutes, the organizations,

31:35as well as some of the companies, they've sort of shifted or pivoted. They've sort of changed direction. Some of them are still doing ZK, but they also maybe shrank. They just made a smaller team. But at the same time, this is something I talked about in episode 399 of the show where we asked is ZK dead. We also are seeing equal or more interest in the research. So like tons of research papers coming out around ZK. The actual use of ZK is expanding like Google's using it and the EU is using it and it's like in mainstream, you know, Web 2 stacks or whatever. Like it's in all of the major. It's kind of like just a tool in the tool set. So yeah, it's kind of a weird moment where it feels like some of the OG or some of the like ZK energy from the builders that we knew is less and at the same time it's actually more used than ever. Yeah, I think from our perspective, we kind of see this as a positive within ZK. Like a lot of the OG kind of ZK primitives have kind of matured, like they're out there.

32:39We can just use them now without like needing to like publicly talk about it. Yeah, it's kind of just in the background now, which is great. And people can build applications, consumer experiences on top of these OG primitives without needing to run into the same issues that we did kind of back into the day. And yeah, it's also great to see like stuff like ZKash as well. Like the mechanisms, the primitives have matured now. Yeah, and now it's finally being like adopted kind of in a bigger way. In mainstream. Yeah, yeah. Yeah. Totally. What about crypto itself, the blockchain side of things? So like the ZK side, like we just said sort of it's like it's sort of twofold, right? Like it's grown in interest and used, but maybe some of the companies have pivoted or changed. But in crypto itself, like we, I mean, in the last few years, we've had these like incredible, hopeful moments, and then these very tough troughs. Where are you guys at? I think within crypto kind of see that, well, stable coins are not going to zero. Like they're just going to be used by everyone now.

33:42And there's a lot of different use cases that are unlocked by stable coins. A lot of people are talking about like institutional adoption and everything. But for us, we're mostly interested in like the still more like I guess subversive. Yeah, long-derserved areas. We where we can apply stable coins. In particular, like what we're doing at Pierre is serving a lot of the, hey, like the cross-border, like different regions of the world where they don't have like good banking rails. They can, they have to rely on P2P or like kind of merchants who can't get like processor relationships with like traditional like the traditional PayPal stripes, etc. Or in general, like there's like just a lot of the different industries that just can't get these kind of relationships and must rely on P2P systems. And so yeah, we're kind of interested in that with like stable coins. I do feel like, so this is also coming, maybe becoming more apparent. But like a lot of these AI companies and obviously there's these insane moves happening on that side of things. But they're,

34:47like I find it pretty amazing when I like open router, you can log in with your eith address or something like that. Like it's interesting to see these companies that are definitely in the headlines tapping into the things we always wanted companies to tap into in the past, right? Like this is what we wanted. We'd always hoped like, oh yeah, like MetaMask would let you get into your Google account or say like never, probably never going to happen. But some of these emerging companies, yeah, they're experimenting with it. I also think of something like news research, which is coming out of crypto land. But now it's like an agent and then obviously has like a bit of this like blockchain legacy. I do wonder if we're going to not see more of that like overlap. It's been yeah, a lot of like interest in agentic kind of payment use cases. We've been looking into it a little bit. We actually did like a little side project with like Adiron or team did where you can kind of sell your surplus kind of AI tokens for like fiat. Oh yeah, that's so crazy. Wait, what is it? So your like, so your monthly budget of tokens, whatever like,

35:50whatever your plan gives you, you can sell it for crypto tokens. Yeah, I think so the project is was in collaboration with this like project called surplus on base. It's a marketplace where users can basically offer their API key and open AI, open router, all these different service events as well. And yes, sell your excess kind of budget. That's cool for like 90% discount. And people will buy it because it's so cheap. Yeah, yeah, yeah, to get access to tokens. Huh. Is it using peer somewhere or is it just like a cool so it uses peer for the caching I guess in and out of the tokens directly to your fiat account. Does that mean did you have to interface then with the APIs of like the frontier labs? We just did the caching out caching in kind of service around it. The other project built the marketplace with interfaces with the API keys. Cool. What about you guys? So I have a question about you as a team.

36:50What are how big are you today? And yeah, what does development look like for you today? Like has this year been insane? I feel like everyone I speak to has kind of just like rethought everything about the way they engineer the last year. Yeah. Yeah, we're like six people right now. Okay. So two more than when we started. Are you the same people? Is it still the same team or has it changed? No, no, different. Me and such in are still on team and then we have four other people we joined later on. But yeah, it is it is crazy because we went from four to six people, but we felt like we like 10x are like really output. Yeah, with yeah, all the AI tooling and everything that's been going on. Yeah, we use AI very much internally. Are you using it primarily as like security checks? Are you using it to like be your sub engineers? Are you concerned about like external actors using it against you? I guess all of the above probably.

37:52All of the above. Yeah, yeah, yeah, during the development stack, the lifecycle, do security, reviews with it, and scout it all across our like products layer as well. Both a bunch of like AI stuff. And I think we're thinking a lot about how we can apply AI to directly like more protocol level stuff with all the different kind of platforms that we could integrate. Oh, because the bottleneck is that like I only have a memo account. I can only integrate them. But yeah, with AI, there's a path to like really scale up how many platforms we can support. And when you say platforms, do you primarily look at like the traditional payment apps? Are you also looking at different like blockchain environments? Like you just said you're on base with USDC. Would you expand that in that direction too? Yeah, I think we primarily look at the the off-chain side, the payment apps that we can integrate and verify off the thin city of. On the on-chain side, we actually think it's pretty like solved. There's like a lot of really good

38:58bridges like relay, for example, you can abstract basically what assets you're using. So we don't, yeah, our users don't even know you're using base or you've been using USDC. Yeah, yeah, yeah. There's a lot of good experiences that we can build there already. Oh, interesting. That's so funny because I still think very much in those like L2s and like where it lives and like, yeah. What are some new projects that are on the horizon? One project that might be released before this episode comes out is our like pay product. It's our basically our checkout interface. They'll top of our existing work that allows merchants to accept USDC or any kind of crypto payments where like their customers of the merchants still pay with every day Fiat platforms like Venmo cash up sell. So the end user does not even need to know, hey, they're paying, like, there's crypto in the back end. They're just paying Fiat for goods and service that the merchant is offering and we're able to do a lot of those things with kind of the tech stack

40:01that we built. Cool. What's it called? It will be called pure pay. What is pure cash? Is that a thing? Is that life? Yeah, yeah. So that's how we branded our like SDK and our yes, our flow for like caching out of crypto back into Fiat. So it still uses the same kind of mechanism that we built on the protocol, but we just branded it differently. So we can get a lot more kind of DeFi teams. Zcash teams have integrated it already to be able to cash out, I guess, Zcash directly into Fiat privately in a few clicks. Just before when I asked you about like how AI how you're using AI internally, you talked a bit about like how you could use it to build, but like could your users be agents as well? Like what does that look like? Yes, a lot of like users within PIR can actually just like on off ramp to their agents. So a user can use PIR fund their agents. Their agents do stablecoin crypto stuff on chain. And then when it's time, they can cash out back through PIR.

41:05Interesting. Into their like ventech accounts. So in this case, it's not like you're it's not that an AI agent's really a user of PIR. It's just that like the owner of the agent can use PIR to get it in there to give it some access. Yeah, yeah. Unless like you could also give access to the agent your memo account. Oh, yeah. I guess so. Yeah. Then then it's a full end to end flow. Maybe not the smartest move still. I don't know. Yeah. So scary. So are people fully abandoning all of their private? I mean, actually we have seen in our in our telegram channel, we've seen some like real users, real tell like with their handle where they've clearly like given it over to an agent and it's acting insane. I don't recommend that. It's sort of it's very weird for your reputation with like people you actually know, but yeah. Yeah. Yeah. There's definitely a lot of slop out there these days. Yeah. So I said this in the question around AI, but it's about security and like actually AI attacking your system. How are you

42:09thinking about that? Does AI pose the threat not necessarily to like breaking the T, but like forging some of the attestations? Like could it reverse engineer what's happening in that T? Yeah. I'm just trying to figure out like if you have any thoughts on the on the risk from the outside. I think we try to keep our systems that we built very I guess modular and kind of isolated in the T E itself. It's yeah. It's only doing like one thing. It's like making a call to the what to API, getting response and then transforming that response into a signature. So it's actually a very like one, two, three kind of thing like like steps one, two, three and that's it. We don't like push all the complexity over onto like the product layer as much as possible. Do see I guess AI definitely has a risk. We do run a lot of like security reviews and stuff like that from time to time. And yeah, I think like one other benefit I guess of us switching from more of these like OG kind of like

43:10ZK email, for example, is that we're able to move like a lot faster and react to in case there's like a security incident or whatever. Whereas yeah, if we use like traditional, I guess the ZK circuit, we would have to I guess create a new circuit, the run the like the trusted like ceremony. And then deploy that again. And then if anything changes, we have to do that whole process over again, where we're like introduces latency. Is there any way for like an outside actor though, if they like would they ever be able to reverse engineer what's in the T does not like break the T but like get whatever is in there somehow. I guess only if they break signatures or something like that, right? It sounds like you'd have to break some pretty heavy cryptography to do that. Yeah, maybe ECDSA. Yeah. Or you just you can like hack into the Amazon's like data center somehow. And yeah, are you hopeful or worried about the pace and the impact of AI? It sounds like you're kind of excited about it because you're using it a lot. Yeah, there is obviously for it off, but yeah,

44:14as a whole, we're definitely excited. It allows us to like move 10x faster on our roadmap and kind of see what our users like get get it like real time basically like feedback on what we build. And we're yeah, we're able to do a lot of like cool experiments as well that wouldn't have been possible if we were yeah, without AI. And kind of also takes us back to our initial roots where we were basically running experiments building a lot of proof concepts back in the day, but now we're able to just do that like in one hour instead of like crazy two weeks, three weeks. Yeah, yeah. You sort of you talked about pure pay, but you have other app ideas or like this sort of comfy like using the programmability that the Tee enables. I think we're yeah, definitely focused on that bridge between Piot the payment platforms and on chain like stablecoins still. And we do have like ideas we could potentially build around like this flow. Yeah, of course, like one one is pure pay with our merchant checkout solution. But yeah, overall we're like

45:15still very interested in hey, like let's get a lot more platforms different countries that could use our flow. Really want to be able to support like every currency, every fintech account in the world. Cool. Well, yeah, congrats on sort of going through these different iterations of the rebranding, which we didn't actually talk about. But to me, it seemed like a maturing moment. Like it's sort of like leveled you guys up a little bit. So yeah, congrats on that. And excited to see what you're what's coming next for peer. Of course. Yeah, thanks for your chat. Cool. All right, I want to say thank you to the podcast team, Rachel, Henrik, and Tanya. And to our listeners, thanks for listening.