The Evolution from ZKP2P to Peer

9 Sept 2026 · 46:01

On the Zero Knowledge podcast, Anna Rose talks with Richard Liang of Peer, formerly ZKP2P, about the project's evolution from ZK email proofs linking Venmo payments to onchain USDC, to ZKTLS and now trusted execution environments. Liang explains the trade-offs around privacy, speed and UX, why ephemeral privacy suits TEEs, and Peer's expansion into payments and more currencies.

Speakers

Topics

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this [music] podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise [music] to change the way we interact and transact online. This week I catch up with Richard Leang from Pier, a project formerly known as ZKP P2P. ZKP P2P initially came out of an event that we hosted called ZK Hack Lisbon, and we last caught up on the show about 2 years ago. In this episode, Richard walked 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 their switch to TEES. We discussed the reasoning behind each shift, including the trade-offs around privacy, trust assumptions, speed, and the idea that some use cases only need short-term privacy rather than permanent guarantees. We cover the rebrand from ZKP to peerto-peer, the 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 Leang from Pier.

Today, I'm here with Richard Leang from Pier project that was formerly called ZKP2P. Welcome back to the show, Richard. >> Thanks for having me, Anna. 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 ZK Hack Lisbon. I think in that episode we talked a lot about, you know, 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 primarily 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 with the product. You've done a rebrand. So yeah, I'm excited to start. Um, I think maybe a good starting point would be to like go back in time a little bit to that product. What has happened since? You know, what were what was your thinking back then and how has that evolved? What were the different iterations you took along the way?

>> Yeah, a lot of things have definitely happened since then. Back then in 2024, we were uh running a lot of like experiments and trying to push the frontiers of what we could build with uh ZK in like consumer kind of applications. >> Mhm. And yeah, back then we were proving that you have actually sent a VMO payment and received a email, confirming you've sent a payment to someone else and using the DKIM signature of a email and using ZK to prove that and then submit that onchain. Yeah.

>> Um in order to do some action and in our case is to release some USDC. So effectively it's kind of like a on-ramp uh transaction. Yeah, I remember it was sort of like this two-way transaction, right? Like so on on the sort of traditional side, you were sending money like money was being transferred over Venmo and then on the onchain money was being transferred in the other direction on chain and it was all connected through this ZK email glue. >> Exactly. Yeah. So the first step was a seller of USDC onchain wanted to receive something in fiat and VMO. So they lock some USDC into a smart contract and then later on a buyer comes in and basically

says, "Hey, I want an on-ramp." So how the buyer does it is they pay the seller directly on Venmo and use a receipt of the email as proof to unlock the smart contract directly. >> Yeah. And back then, I mean, you talked about I don't know if we had Zika email on before or after. I can also dig up that episode with Aush. But it was brittle. Like it was cool, but it was like I just remember the conversation being something like if Venmo changes the format of their email, your system breaks, which is problematic right?

>> Exactly. It actually did happen. Oh, really? >> I don't know how soon after the episode [laughter] came out. Okay. Back then, but yeah, that happened. >> Damn. >> Um, but luckily, I think we were moving into alternative methods. >> Yeah. So, what happened next? like where did you go after the ZK email? Did you end up just sort of shuffing 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 provenence proving authenticity proving kind of solutions out there at the time. M >> in particular, we're looking at TLS Notary and a lot of the proxy ZK proxy work that Reclaim, I think Opacity Pluto back then we're working on as well

>> cuz we knew that one day Yeah. ZK email could break. >> Yeah. And did apparently. >> Yeah. >> So talk about that transition over to the ZKTLS stuff because we've also, you know, over the years covered that quite quite extensively. So what you're kind of like a user of that technology. How did it work? How did it not work? Like what happened with CKTLS? >> So the main brittleleness came from the email template changing and we needed to move to a more stable kind of solution. >> Mhm.

>> And the solution was basically to prove API responses instead of emails. and API responses, especially private ones that like VMO, whatever, Cash App, all these fintech platforms have are way more stable and they don't change. >> Um, 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 ZKTLS used yeah a lot of the like privacy preserving techniques that ZK email has uh 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 in your product and which with which payment providers basically? Yeah, because like Yeah. All I knew back then I think it was Venmo 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 ZKTLS, what happened like where was it being used? >> It was used as a replacement for ZK email >> for us. So instead of the user providing a receipt of a DKM like signed email from VMO, it was still VMO but the user

now generates a client side. I guess proof that I did call this VMO API got a response on it and able to prove that the response contained like certain fields like the amount, the recipient, the time stamp, stuff that is required to unlock the USCC in the smart contract. >> And did it work? Yes, it worked better than than there was still obviously some hiccups, >> okay, >> with new tech, but yeah, switching to API responses definitely a lot more stable, but at the same time, it was still using, I guess, client side ZK proofs. So, Grath 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 slowdown like was there noticeable UX issues because of that? It actually improved off of ZK email if we were approving ZK email client side. I think how long that took was like 9 minutes to prove a email circuit directly in browser. >> So when we were back using ZK email we were proving it server side >> which was kind of cheat >> that took 20 seconds >> and with ZKTLS it was probably around that interval too. >> I see. But you were actually doing it on device. Yeah, exactly. That was the change.

>> Nice. Okay. But then are you still using ZKTLS today with some systems? >> No, that that's a I guess another time jump in our journey. >> The big Okay, maybe tell me what happened in between. Feel free to just like go chronologically if you want. But yeah, I'm really curious where that sort of gets also swapped out and why. So we stuck with ZKTLS from basically the start of 2025 to I guess a couple months ago. Um so >> 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 um if we were to get a lot more non I guess cryptonative users uh using us. And that's kind of where the switch came in. >> D where did you switch to? [laughter] What did you switch to rather? >> I don't know if I can mention on this podcast, but uh we [laughter] did make a switch to tees um that we currently Yeah. Deploy ourselves. So it's entirely our own infrastructure now. >> So is this no longer client side? Like I'm trying to picture what the flow looks like now? Like should we still use Venmo as the example? I don't know if there's like a more relevant one.

>> Uh yeah, Venmo is probably the best 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, but before I do that I'll mention one nuance about ZKTLS as well. Okay, >> we did talk about like the user still generating client side ZK proofs, but in ZKTLS, those proofs are actually not being sent directly on chain to unlock

the USDC and the smart contracts. >> They are actually I get as well as all the ZKTLS systems, the proofs are being forwarded to like a tester um proxy in the middle. I remember this >> and then the proxy actually verifies the proofs and attaches I guess a signature on top that then can be verified >> uh on chain. >> Okay. >> And that yeah I guess the reason for the tester in the middle in zkls and also inte that I'll go into is that there has to be like a intermediary I guess a proxy in the middle to attest to the web 2 kind of like the offchain API call and that that is not possible without like someone Yeah. like like a service in the

middle. Um because there are no signatures on API responses and yeah that's true for ZTLS and TE's. >> So yeah, let's do that flow maybe. So like I let's use TE's because and I know we're maybe skipping over the way that ZKTLS worked with it but I'd be curious I'm just curious to hear how you're doing it today. So in the TE flow that we have the VMO I guess buyer of USCC they come in they make the payment still the same as all the previous flows but now they basically log in to VMO to intercept the I guess the API response and with that session material they encrypt that session

material with the like the tester or the TE's upload key um that only the TE holds >> and once that session material is forwarded to uh the TE. The TE decrypts 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 USC. >> I see. And I guess I mean the question I did have was like is there is ZK completely stripped out? And it sounds like it is like is there a proof anymore?

>> Yeah, there's no ZK proof anymore. There is an attestation which >> I see >> is the only thing remaining. >> How does the user actually intercept the this Venmo session material? Like are they using your interface that's like behind the scenes Venmo or they in Venmo specifically and they're actually active in there? So in our case they directly use VMO but on desktop that requires installing I guess the pure extension plugin and in the extension there is that ability to intercept incoming I guess web requests.

>> I see >> and be able to offer a much better UX for the user. >> Cool. The other alternative is the user basically has to inspect like Chrome developer tools directly and copy and paste it >> which is probably no good. >> But wait, so is Pier then like a new is it like within the Venmo ecosystem? Is it something that like >> a Venmo user can see and like can find in a store or like sort of a Yeah. How do they get it or do they have to like manually install it? >> Uh no. Uh so basically what we're able to do with pier is not work with any of the underlying payment platforms.

>> Okay. >> Uh in order to generate proofs and it's all userdriven in that the user installs I guess the pure extension. The user initiates a login to their own VMO account on web. >> Uhhuh. >> With the extension >> and then the user generates that attestation or calls that attestation themselves. >> Okay. So like the extension is kind of grabbing what you need in order to like unlock it. But like for the user, would it would the flow feel quite easy once that extension's 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 it anymore and see it anymore and it's entirely headless. So further like second, third, fourth onraps, the user doesn't doesn't even need to know the extension exists. >> Oh, 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 know, 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 TE to preserve privacy >> for the end user like session VMO session. >> They're trusting your TE's, right? Like TE's at your server like you're running them not it's not like the TE on the user's device. >> Yeah. Yeah. Exactly. It's we're using AWS Nitro. So you're basically trusting AWS to protect their TE's. >> Got it. Okay. So the tra that's the sort of the negative like now we're TE's. The hardcore cryptography VK people won't like that because TE's get broken sometimes and but what do you gain like why do that? your 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 ZKTLS proof to like 300 milliseconds essentially >> okay >> and we also gain a lot of programmability that we can talk about more in that you can do cool new flows with TE's that are Not possible >> in ZK. >> Yeah. ZK. Yeah.

>> Where does the atttor live? Does the atttor live in the TE that you run? >> Yeah, the atttor lives entirely, I guess, in the TE. >> 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. Like I don't fully know what that a tester looks like. So it does the same things as the ZKTLS tester in that it receives that material uh but within the TE since it has the private key to decrypt it decrypts that material sees entire plain

text I guess and then replays I guess that API call into like VMO servers. >> Okay. >> So the TE will know that hey like this connection is authentic. Mhm. >> Um, and then we'll also like kind of redact a lot of the response response stuff and attach a signature to it so it only signs on like amount, recipient, 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 tester send something back to the user?

>> Yeah. Yeah, it attaches a 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 a smart contract or to create an action of some kind. >> Yep. >> Cool. Okay. What is so the tra the only trade-off you shared for the TE's is like it's a TE [laughter] 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 >> okay >> a proxy like with ZK attached you shift a lot of the assumptions from like cryptographic primitives to like the

actual yeah the hardware how 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 [laughter] TE. >> Cool. But was it hard for you guys as a company to let go of CK? Like I'm just kind of curious what went through like what kind of conversation was happening. I mean your 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 first 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. Um, we're already like very primitive agnostic in our like smart contracts and we basically used all the primitives out there today >> and I think it's just a 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 CK 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 cuz I 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 can 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 TES we felt like the trade-off wasn't that big for our 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 Uh and furthermore with our exact flow users are like just need ephemeral privacy. So none of like the like a long like serving kind of permanent like >> privacy like guarantees are like stored directly in the tea. You basically only need like 1 second of privacy to ensure that like the VMO endpoint is attested for example. >> And we felt like the trade-offs were like really not that big at all. Yeah, I've heard about that where 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, something 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 is 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 te 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's what did you did you say this or >> ephemeral >> ephemeral privacy. Yeah. >> Yeah. Yeah. So what we're approving is basically the session again. So the session with the session cookie with the request headers, they only last like traditionally in like these banking websites probably like 10 minutes. >> Um so >> as long as someone is not next to TE listening for that exact like 1 second of >> like request replay in the TE, 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 blockchains securing large balances that are not reversible at all. >> So I guess the traditional like side channel attacks in TE's don't really apply to I guess what we're doing. So like let's theoretically say the like TE'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 can see you're like you transfer like this guy €500 for example on Revolute. Typically,

I guess in these banking fintexs, 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 like transfer funds out. >> Mhm. >> And even if they could then I guess it it is like off-chain fiat. So, you can just call your bank to reverse the transaction. >> Ah, true. But could they tech like theoretically intercept the attestation or the atttor's output? Do you know what I like the thing that the user needs in order to unlock onchain >> it would be in memory so they would have to be able to inspect directly what's in flight as like none of the test stations or signatures are stored anywhere >> okay

>> 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 funds for the user Is the onchain 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 pier 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 USCC on a layer two where I'm based. Okay. Uh right now and yeah we pier 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 subversive kind of cyber punky like you're going directly onchain and directly offchain without a middleman at all. >> Yeah. Except for this at tester, but the tester is sort of a dumb middle. It's not like a It's not like a exchange where everything's 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 atttor >> that could be coming. And yeah, a lot of like the extra like edit index exchange in order to KYC with they store 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 Revolute, Venmo? Like those 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 yeah the VMO users, the Revolute users, they've already passed their like pretty strict KYC. >> Mhm. >> And all the transfers within our system are kind of within their ecosystems. So it's very closed looped. Um nice >> and we as a result we don't need to do anything extra. Yeah. What are all the platforms you actually inter like that you work with? So we just mentioned Venmo and Revolute UPI. Did you end up continuing that or did you stop that?

>> We stopped UPI but we will I guess reenable it at some point. Okay. >> UPI was also built on CK email back in the day. >> We just haven't enabled it. >> Okay. >> For APIs. But yeah, other platforms like we're still mostly EU and US I guess centric with we have like zel, PayPal, like Chime, Cash App, and in EU we have or UK as well. We have Monzo, N26, >> Revolu obviously and yeah, just a couple more wise I guess.

>> Are they mostly Is it mostly banks then? It's like banks or money transfer. Yeah, it's like FinTech, Neils where you can make like peer-to-peer transfers with each other. >> Are there other like you sort of hinted at some sort of program programmability because of this TE what what can you do with Pier? The one thing that we've added into the protocol since we've launched TEES is that sellers like the people who lock the USDC uh into a smart contract, they can also encrypt their like session material or their like fintech API keys.

>> Sure. >> Uh and have the TE read from their balances uh or their transaction history. So, what that unlocks is the buyer comes in, they make the payment to the seller just as before on VMO, for example, but instead of them needing to download extension, logging in to their Venmo account, >> they just hit the seller's past transaction history via the attestation or tester in the middle. And as a result, there's no pro buyer proof needed. >> Okay. So, the seller basically does the proving cuz it's it's received the funds on Venmo. Yeah. Okay. 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 offramp 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 offramp or like sell their USC. And then buyers are obviously they want to on on-ramp to crypto or they like are just making kind of a payment as part of like a checkout flow that we built.

>> Um and then the merchant basically receives the USDC 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 the seller. Yeah. Uh but they to them they just see that hey it's just a traditional like peerto-peer a transfer >> but they could in theory match that transfer look on chain.

>> Oh yeah. >> Um and yeah do some like timing analysis to see that hey this like these two people transferred this amount. >> What kind of amounts do people actually use pier 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.

>> Okay. >> Um so they could set a upper limit or set a lower limit. Typically, all the transactions have been under 5,000 per transfer. >> Okay. Why don't people use it for bigger amounts, do you think? >> One is definitely the fintech accounts just don't allow like larger transfers. They're like not wires, for example. >> I think VMO has like a $2,500 limit. Okay. >> Uh per user per day, >> but like wise, 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 like these like medium to smaller amounts cuz you can instantly 30 seconds get money somewhere. >> Whereas like if you're transferring like 50,000 100,000 like millions >> like you're you're probably okay waiting like a day with a wire to like a centralized intermediary. >> Yeah. So like a few years ago we had these very active groups like PSSE DK email was sort of like rolling out a lot and being used a lot at ZKTLS but in the last few years like really in the last year or so we've seen a lot of shifts. I mean PSSE I don't know exactly its state but I feel like it got re it got renamed and then it got reorged again. So it has felt like a bit of a contraction right

like it felt like the institutes the organizations as well as some of the companies they've sort of like shifted or pivoted they've sort of changed direction some of them are still doing CK but they also maybe shrank like they just sort of like made a a smaller team but at the same time this is something I talked about in episode 399 of the show where we asked like 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 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. We 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 in the day. And yeah, also great to see like stuff like

Zcash 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 it's grown in interest and use, 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 now going to zero like they're there's going to be used by everyone now and 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 underserved 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 crossber 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

relationship ships >> with like traditional like the traditional PayPal, Stripes, etc. or in general like there's like just a lot of 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 there like I find it pretty amazing when I like open router you can log in with your ETH 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 had always hoped like oh yeah like MetaMask would let you get into your Google account or something 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 cryptoland but now is 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 o like overlap. >> It's been yeah a lot of like interest in agentic kind of payment use cases. Um we've been looking into it a little bit.

We actually did like a little side project with like Andrew on our 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 you're like so your monthly budget of tokens, whatever like whatever your plan gives you, you can sell it for crypto tokens. >> Yeah, I 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 an open AAI, open router, all these different services.

Venice as well, and yeah, sell your excess kind of budget. Um, >> 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 Pier somewhere or is it just like a cool >> So, it uses Pier for the cashing 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 we just did the caching out caching in kind of service around it. The other project built that marketplace where interfaces >> with the API keys.

>> Cool. What about you guys? So I have a question about you as a team. What 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 [laughter] the last year. [gasps] Yeah. >> Yeah. We're like six people right now. 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. U me and Sachin are still on team and then we have four other people who joined later on. But yeah, it is it is crazy because we went from four to six people, but we felt

like we like 10xed our 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. All of the above. Yeah. Yeah. >> During the development stack life cycle, do security reviews with it. >> Um, and scattered all across our like product layer as well. We built 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. No, >> cuz the bottleneck is that like I only have a VMO account. I can only integrate Venmo. 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 or 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 offchain side, the payment apps that we can uh integrate and verify authenticity of. Uh on the onchain side, we actually think

it's pretty like solved. There's like a lot of really good bridges like relay for example, you can abstract basically what asset you're using. So we don't Yeah. Our users don't even know you're using base or you're even using >> USC. There's a lot of good experiences that we can build there already. >> Oh, interesting. That's so funny because I 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 built on top of our existing work that allows merchants to accept USCC or any kind of crypto

payments where like their customers of the merchants still pay with every everyday fiat platforms like Venmo uh cash up zel. So the end user does not even need to know hey they're paying like there's crypto in the back end. um they're just paying fiat for a goods and service that the merchant is offering >> and we're able to do a lot of those things with kind of the the tech stack that we built. >> Cool. What's it called? >> It'll be called Pure Pay. >> What is Pure Cash? Is that a thing? Is that live?

>> Yeah. Yeah. So that that's how we branded our like SDK and our I guess our flow for like cashing out. >> Okay. >> 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 these DeFi teams. Zcash teams have integrated it already to be able to cash out, I guess, Zcash directly into fiat >> um 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 Pier can actually just like on offramp to their agents. So a user can use pier fund their agent their agents do like stable coin crypto stuff onchain >> and then when it's time they can cash out back through pier. >> Interesting. >> Um into their like fintech accounts. >> So in this case it's not like you're it's not that an AI agent's really a user of pier. It's just that like the owner of the agent can use pier to get it in there to to give it some access. >> Yeah. Yeah. Unless like you could also give access to the agent your VMO 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. >> Mhm. Yeah. I don't know if we're fully are people fully abandoning all of their private I mean actually we h 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. [laughter] >> I don't recommend that. It's sort of weird. It's very weird for your reputation with like people you actually know. But yeah.

>> Yeah. Yeah. There 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 thinking about that? Does a AI pose a threat not necessarily to like breaking the tea, but like forging some of the attestations? Like could it re reverse engineer what's happening in that tea? 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. Uh in the TE itself it's yeah it's only doing like one thing. It's like making a call to the web two API getting a response and then transforming

that response into a signature. >> Um 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 as a risk. We do run a lot of like security reviews and stuff like that um from time to time. >> And yeah, I I think like one other benefit I guess of us switching from more of these like OG kind of like ZK 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 a ZK circuit, we would have to I guess create a new

circuit that run the like the the trusted like ceremony. >> Yeah. >> And then deploy that again and then if anything changes we have to do that whole process over again where it 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 tea? So it's not like break the tea but like get whatever is in there somehow. Like it's only if they break signatures or something like that, [laughter] right? [gasps] It sounds like you'd have to break some pretty heavy cryptography to do that. >> Yeah, maybe ECDSA. [laughter] >> Yeah.

>> Um or you just you can like hack into Amazon's like data center somehow and then 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 trade-offs, but yeah, as a whole, we're definitely excited. Allows us to like move 10x faster on our road map and kind of see what our users like get get like real time basically like feedback on what we build. And 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, 3 weeks. >> Yeah. Yeah. You sort of you talked about pure pay, but do you have other app ideas or like the sort of comput like using the programmability that the TE enables? I think we're yeah definitely focused on that bridge between fiat the the payment platforms and onchain like stable coins 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 uh solution but yeah overall we're like still very interested in hey like let's get a lot more platforms different countries uh that could use our flow. Mhm. >> Um 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, the rebranding, which we didn't actually talk about, but to me it it seemed like a maturing moment. Like it's just 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 Pier. >> Of course. Yeah. Thanks for the chat.

>> Cool. All right. I want to say thank you to the podcast team, Rachel, Henrik, and Tanya, and to our listeners. [music] Thanks for listening.