Verifiable Micropayments for API Data - Luís Freitas - zkTLS Day @ Devconnect 2025

Transcript

All right. All right. Hey everyone. Everyone's doing great. Um, I'm Luiz. I'm the founder of MC Pay. And we've been doing a lot of MC Pay things. But for this talk, I want to talk a little bit about like how we're trying to verify uh microp payments and the data that people get when they pay for things. Oops. Sorry about that. All right, I think this will work. So, our main product has been we've been building this gateway. You can connect to the gateway and under the hood, we're registering a bunch of MCP servers that

are paid using X42. And the main goal is just to make it very simple for users to, you know, just interact with MCP servers in general. You don't need to maintain multiple connections with just one. Ideally, uh you can get the data you want and pay for it. Um over the past couple of weeks uh since X42 hype uh is real, we got a bunch of transactions and new users and some USC process. This is a very early project by the way like started at a hackathon many months ago, like a couple months ago. Um and we're very happy to share these these metrics and to kind of like show that what we've built works.

Um but the problem is like when people pay for X for things with X42 uh generally you know there's no guarantees that the return data they get is authentic. it's fresh and tempered and a lot of these things, right? I'm not a ZK sort of, you know, um, expert, but we're we're working with experts on this idea. And the idea we kind of had was like, what if we can attach ZKTLS proofs, uh, to the paid responses, so like we can give the user sort of like a guarantee that the data they got is genuine.

Genuine, right? Um, we're we're also thinking about this at the station. If some expert is in the room and wants to discuss this, I'm very happy to do it because uh we want to make sure that what we're doing is correct and right. But this matters because when you pay for things and you get and not sure how many of you in the room have been using X42 or tried or you know like you Okay, awesome. Are you building with X42? Okay, one guy is building. Nice. Um awesome. Uh but you know like when people pay for these things like there's no guarantee that you know they get they make the payment they get some data but it doesn't mean that it's correct right uh if we can make sure that data they get is correct then we can build a lot of things on top of this like a

reputation system um onchain refunding mechanisms all these different things right so with vlayer uh shout out to vlayer nami namit is there uh they've been partners on this journey and the goal is when an agent connects to our MCP uh proxy the MCP proxy there um and they kind of like there's a x42 payment handshake there's a request through the v the v layer not notary to the end the the you know the external resource um this re this zkls proof is generated with both the payment response so like there's a guarantee that some you know the agent paid for this thing and the data they got so then we package this in

the meta field of the MCP response. So the client gets both the data the the zkls proof and well they can then use that later on to prove that they actually got the data from the right resource and so on and so forth. Um all right this demo will be super short but uh again there's two two things that are very important for this to work. when you connect to the MCP proxy you set a header for now XV layer enabled true then things happen and in the end there's a meta response this does not pollute context if you guys are familiar with MCP this is just you know like something that will not pollute context but still agents and clients can still access uh the object and there's a meta

a v layer proof and the next to uh prim response you can use to kind of validate this this response okay and then this demo won't work because but I do have a demo here. I will play this was recorded last night and I'll stop while I'm actually So this is the one one of the MCP servers we have on our registry. Uh it's for Twitter Twitter API instead of paying $200 a month. You can use we're we're charging a few cents um to to access the API just for read data by the way. But the idea is you can connect using an API key. Generate an API key

which I did here. Um, copied the URL. And now I'm going to head over to MCP inspector. Uh, if you guys are building with MCPS, you already know this. This is how we test these these things locally. Drop the URL there. And then set the view layer header here as you can see. And I'm going to try run one of these tools. I'm checking myself on Twitter. Give me a follow, by the way. And yes, so there's a Vlay, there's a response super quick, but you can see closely here. The payment response, the Ver proof, and the actual data.

And then in our payments explorer, you'll find the payment, how much was the blockchain, the the chain, and then also some information we're showing here um for the web proof. Yes, this is it. Oops. If you're interested in all of what I showed as uh we have an SDK and a lot of things for developers to try out, docs.mmcp.tearters layer.

And I think this is it. Um super short, super quick, but thank you. >> [applause] >> I have eight minutes for questions. I'm not sure what you guys are want to ask, but uh let's do it. Anyone? >> Hi, great presentation. Um so are you who's actually doing the payments in in this case? Is user sending the payment or is the V layer responsible for sending payments to the X42 server?

>> Yes, that's a great question. Um in this so right now the setup I showed is we we're using server wallets. So the user when they create this API key they kind of give us permissions to like execute the payment but we proxy the request through the vlayer services. Yes. So like they are essentially a proxy of a proxy to the actual uh external resource. Yeah. Oh, was what we saw in the video real time or because it seemed really fast.

>> It is very slow. [laughter] This was cut I cut I added the video. I don't have internet I would love to show but it adds like maybe 20 to 30 seconds to each request when we enable uh the gener the proof generation. Yes. >> And uh just to just ask additional question to this are you running on B or which which chain are you running on? Um we do support all the EVMs all the EVMS that do have facilitators. Are you familiar with X2? Right. So like the settlement for these payments needs happens on a facilitator.

So like all the chains that do have public facilitators we support. So all EVMs like B most popular EVMs like base uh can't remember on top of my head right now but a few like avalanche I guess ioteex never used but it's it's there. Uh and Salana do support Salana as well. >> Yeah, it adds up. >> That additional latency is not related to blockchain. It's only related to the MCP computation. >> The uh proof the proof generation proof generation. Yes. Yes.

>> Yeah. Exactly. >> I also have a question. So you shown us how we can get a proof the zikk proof that the server return us back what we asked for. >> Yeah. >> And what happens if the server returned something else? The zikk proof will show us that yes the server returns something else. >> Yes. >> But the payment was already done. So >> what can I the payment was already processed? >> The payment is processed as you generate the proof. So it's the okay. >> But what can I do as a client? I send my money. I got back something I didn't ask for because the server was acting maliciously maybe or there was downtime.

>> There's some some compromise here. Yes. Because like what you sent when you ask for the proof generation, you actually sent a signature. You don't send a payment. Basically, you're sending a signature that then will be sent to the external server >> or the resource. And the settlement only happens when the external server is after computes and settles the payment then responds something back and the proof is generated at that point with the the the payment the payment proof that you've well the payment response. Yes, >> that's interesting. And how can this component which is verifying the server's response? How does it know if they responded correctly or if I just got the whale service down page that Twitter was reporting for or like GitHub unicor? Yeah,

>> we are down. >> That's a great question. I I we can we can discuss maybe can we can take a look at stuff. Uh I don't I don't don't know if I have the the full context to answer that. All right, I think that's it. Thank you guys. [applause]