Agentic AI - Master x402
Master Agentic AI — Live Series · 1:02:17
Kevin Jones explains x402 payments and demonstrates Google A2A agents buying LLM inference through BlockRun with ampersend spending controls. He also shows how Spritz configures paid bookings and agent API access, then discusses starter kits and agent discovery.
Speakers
Topics
From Master Agentic AI — Live Series, hosted by dev3pack.
Transcript
Yes, I will I will tell you when it's all good. It's just on Zoom on the side. >> All right. No worries. Yeah. Got to get one pump on top. Okay. So, let's wait 3 minutes
for starting. All good. I don't know why it's putting like error
generating preview. So this right? I think it's because of um Twitter right
now who is working with OBS. I think they cut the access because like looks like I can't put any stream key or whatever. Um It's weird. Are you you're you're using Riverside or No. >> Using what? Sorry. >> Well, are you using Riverside or are you just doing it directly from your software or how are you doing it? >> Uh with OBS Studio. >> Oh, with OBS. Okay.
>> Yes. And so actually, yes, it's like I can't access the sitting side uh with Twitter, so that's pretty weird. Um but all right the right will put the recording uh on X like with YouTube link anyway. Um but sad very very sad. >> Yeah that's that's unfortunate. Maybe if you tried to well know because you have to you have to use the streaming key.
What if you tried to go generate a new streaming key? >> I I can't do it. I can do it. That's why >> I wanted to modify that. Um, but yeah, I can do it. So, all right. Uh, anyway, we can't uh change that. Thanks. Thanks X. My god, they have done a lot of literally. But all right, that's fine. We will do um a good uh x tweet about it after and uh and let's see
that's it's okay anyway. All right. So sorry the stage is for you. So I actually for those who are there um so the goal today is more to talk about um X402 protocol uh which is something I very use from now especially not only just in in in web3 but in general and so it's great to deep dive into it because uh during this this month we will have couple of session more on the aentki stack um and so for that um X402 is well used. So just um we will have some some
insight from uh Kevin today about what this but also like use cases behind it and with some mini workshop um like how to build with X402. So yeah, don't hesitate to ask any question. It's really like beginner friendly. So yeah, just to let you know um and and yeah. >> Awesome. Cool. Thank you so much Selene as always uh really pleasure being here and thank you so much for having me. So hello everybody my name is Kevin Jones. I am a developer relations engineer working at Edgen Node. So I work um uh for one of the main companies that creates uh created the graph protocol.
I'm also the founder of a application called Spritz which I'll talk about a little bit about later and also Genesis which is a developer community. Um I see some familiar faces in the crowd so thanks so much. Uh so we're going to be focusing today about talking about XRO2 uh like kind of what it is, how it came about and then also more specifically uh we're going to dive into like some use cases of how you could build on it. Um one will be kind of like a hands-on workshop and then a real quick implementation of how we actually uh integrated this stuff into spritz. So without further ado, let's let's dive right into it. So, uh, let me go and share my screen and close this up and make sure we're on do not disturb.
No one bothers me. Okay, cool. All right so so X42 is uh interesting because it's one of these uh actually HTTP status codes that's actually been around for like a long time, right? X42 uh is a reimplementation on not a reimplementation but it's kind of like a protocol that's been like wrapped around this existing uh error code that has actually been sitting there for a while. It's actually funny if you go to M MDN um you'll actually see here that says the status code is reserved for future use. So like someone was actually really like thinking you know beyond uh back when they started creating these status codes uh back in probably the 90s. I
don't know exactly when it was, but it was a long time ago. Um, and the idea was that they knew there was going to be a way where you had to monetize um, HTTP resources. And uh, so it's a little bit of a interesting thing. And uh, recently, well, I shouldn't say recently, we have seen a surge in agentic commerce, right? Or like concepts of where agents maybe could come do commerce, right? Um, and we're seeing the rise of AI agents in general trying to operate autonomously. Uh, and so Gartner actually estimates that, uh, by 2030 that there'll be $30 trillion in purchases made via AI agents, right? So,
XRO2 is actually a perfect fit for this kind of uh use case because it allows an agent to have its own private key and essentially sign transactions or yeah, basically make purchases over this HTTP 402 uh protocol um and get access to information that it other words otherwise would not need have access to. like everything in payment uh systems today is very much like you need to swipe your card and put in your little pin code or you need to put in your zip code and there's a lot of like human interactions that happen and there's not a lot of systems that are built uh for something like an AI agent.
So again, XRO2 came out of this kind of idea that that crypto native payments could be a solution to trying to get access to and and not just for agents. We'll go into some other examples, but it is the most common use case right now because an agent might need to get access to some data or it might need to call an API. Um, and you know, previously like you were working with like API keys. And another promising thing about X42 is it goes to try to uh replace the API key, right? instead of charging and doing this kind of like um tallying of requests via like an API key, we can just do that that finalization right away using XRO2. So
X42 is very like simple in terms of like uh implementation. It doesn't take a lot to kind of uh add X42 to an existing endpoint. As you can see with like this little snippet, it's really just like a couple lines of code. And this will basically allow you to start accepting payments for what would normally be like an API uh key that you would have to get. So there's uh a bunch of different layers to XRO2. We'll kind of go over these real quickly and then we'll kind of dive into um uh a little bit more of like the the white paper and like how it works. But generally speaking, the idea is that you have buyers and you have
sellers, right, that want to get access to or make HTTP requests uh over HTTP. Um, and this could be uh like a client paying for access to content like uh data like something like on the graph or it could be uh paying for access to call an API to make some kind of like update on something. anything that you could do over an API could be uh turned into an XO2 payment. Um and then there's a couple different specs that have risen out of this.
There's HTTP uh V1 and then there's also V2. So that's important to understand. Uh there are some slight differences. Um and you can provide uh XRO2 access uh for different like means of data. So you could have a HTTP asset that again is like an API that you want to give access to and you want to require payments for that. You also could have an MCP server that is running all of your APIs. So it's one single MCP that kind of like manages access. Um if anyone doesn't know what an MCP is, it's a model context protocol. It's like a way for agents to get access to data in a more
consumable way versus something like an API which can be varying. MCP is a very specific protocol. Um and then also Google A2A or agent to agent and this is the idea that well in the future agents will be talking to each other. So we'll actually do a workshop on A2A today and we'll show how that works. But in the future like one agent will need to pay another agent, right? It's not necessarily an agent talking to a server. It's an agent talking to an agent and then that agent maybe is talking to a server, right? So there will be multiple layers of access for data in the the agentic future and this is kind of that that additional kind of
thing and that's I think that's the future. Um and then there are different schemes. So, like the most common scheme is the exact scheme. And that that's like if you go to the store and you want to buy some candy, the candy costs, you know, five cents back in the 50s. Now it's probably more like $5. Uh you give the $5 and you get your candy. um something like a deferred scheme which is something that is uh edge of node has been working on is a idea that maybe you could like not necessarily settle the payment. So it's a way to do like credit on the blockchain by providing some kind of mechanism to defer payments. So maybe
you have like a a candy shop that you go in every morning on your way to work and you always buy a candy bar. So maybe you don't need to like pay him every time. You just kind of take the candy and then at the end of the month you tally that up. This is that like deferred scheme. So there are these different schemes you can use inside of Xro2. Um and then we also have like different chains like XRO2 can be on any chain. um you know so the most commonly obviously is going to be Ethereum because that's uh where the creators of it uh which is which is base um have have probably the most traction salon is actually very popular as well um and then you can move like any asset like a
lot of people think like oh xro2 is only for stable coins that's not the case you can move any kind of asset across xro2 so it's very generalized the pro the spec is very open and Uh you can also like set the terms of like how you want to like like do that how you want to like exchange like what what's the what's the way the person needs to settle right and this is like EAP 3009 which is like Ethereum signatures versus you know Salana fee pays or permit 2 which I'm not sure what permit 2 is I guess it's just a different um uh maybe it's something with AVAC I'm not sure but anyways this is kind of the layers of 402 if you
think of from a protocol spec like kind of laid out. Um this is how an X42 transaction actually looks. So um you can imagine me I'm an AI agent and I want to get access to let's just say I want to get access to the current swaps on unis swap. Like I want to know exactly what what swaps had the most volume in the last five minutes, right? So I would like say oh I want to get access to that that data. I would make a HTTP request to an X42 enabled server, right, that is probably running something like the subgraph MCP server that has access to that data and it would reply and say, I can get you that
data, but I need to pay to get it, right? So, it would give me a 402 and it would say exactly what I needed to do in the response header of like where I need to go, what chain I need to make the payment on, what asset, how I need to settle, like all the spec stuff that we talked about here is embedded in the response to say, "Hey, all right, well, you need to go and make this payment and then when you do, you need to like sign off the payment and send it to me in an additional header, this X payment header." So then I I say, "Sure, no problem." I sign that and then I send it again. When I send it again, it takes my signature and all the embedded uh data
inside of that uh header and it forwards it off to what's called a facilitator. And the facilitator's job is just to verify that everything is is good and do the transaction and make sure that uh it's going to be able to be settled, right? um uh on the blockchain, right? If I don't have a balance, obviously it's not going to let me do that, right? So, it's going to verify and check everything. Then, uh it's going to go out um and you know do the actual settle settlement of the transaction again. And then it's going to come back to the server that originally said, "Hey, you need to pay for this with a header that says, "Yep, he paid and it's confirmed. It's been
settled." And then that server is going to give me the data that I need. Right? So, it's very very simple. It's similar to it is HTTP essentially. Um, and we're just basically allowing access to that information based off this kind of XRO2 payment. Um, there's a lot of tools to make it easy to to build on AI right now. Um, there's like thousands and thousands like AI, we're in such a golden era of like building. Um, you can really just build anything very simply. Um, I would advise you to try out like Amperson SDK.
Um, this is just my first like or my really quick five minute show on it. It's basically an SDK that helps you build XRO2 powered apps. And we we currently support Google A2A and we also support um we have an MC MCP implementation that you can use fast MCP to build an MCP server and then we also support HTTP. So it's it's a good all-around kind of toolkit. It's very lightweight and it's in Python and TypeScript so you can kind of make make your decision on how you want to build. We'll actually show this off today just because um it's pretty easy to use and stuff like that. So um oh one more slide. Sorry I missed this one. What is the the uh Aerson SDK? Again, it's it's a implementation of Python for Google
A2A and and it has uh embedded with it what's called the agent development kit, which is Google's agent development kit that lets you do agentto agent uh communications and testing. So, it's this cool little kit. We also support MCP and HTTP over TypeScript. Uh it has smart account integration. So, what's cool is you can um hook it up to smart accounts to do the uh more advanced signatures um for smart accounts and it works with the amperand uh UI to basically do like guard rails which we'll we'll talk about here in a sec.
Um, and it comes with all of the client and the server components. And it has this this cool pattern called a treasurer pattern, which is basically like guardrails for like spending. Like you can imagine when you give an AI agent a private key, things can go wrong drastically, right? Uh because if it has too much money, you know, it could well spend it all on like an endless loop. And we'll we'll show that in a little bit. Okay. Um, so if you want to get more information about X42, what do you do? Well, the first thing is you should check out xro2.org.
There's a link to the white paper. Uh, I know not everybody likes to read white papers. This one's pretty good. It's got a lot of really good diagrams in it. Explains the protocol in very very very detail. Um, it's just kind of like some stats on their website. Um, yeah, some information about how to get started, facts. There's also a blog that they do. And so if you want to understand like XRO2 version two, there's a good blog that just came out last December that uh is still very relevant. I don't know what ecosystem is. Oh, ecosystems like partners and people kind of working in the space. Uh which is pretty cool. Uh and yeah, so let's let's kind of dive into this. So I want to start by doing a
demo. And um the demo that I'm going to do is using Empress SDK and it's going to be using um a couple different things. It is a Let me go into here real quick. The architecture for this demo is is this. What we're going to show off is an agentto agent use case. And more specifically, we're going to have one agent that's a buyer. So the typical flow for like an uh X 402 is you have a buyer, right? And you have a seller and it's a good chance that both of them could be X2 enabled. And that means that the seller wants to get paid in crypto and the buyer has the ability to make
crypto payments, right? We're talking about agents here, right? Buyer and seller. Uh in this scenario, we're going to use Google A2A, which is the uh agent to agent framework, right? By Google. We're gonna use XRO2 to make payments. And the data that the seller has access to is actually an LLM query. So, what's cool about this, I don't know if you guys have been following all the stuff with like Open Claw and like, you know, we have like a lot of different like services that you can get for like LLM interference. like you can just go directly to like Google Gemini or you can go to you know whatever claude uh or you can use something open router which is really useful because you can like
kind of get the best price and like kind of have this like additional uh value and like finding other other models. It's easier to configure. Blockr run's pretty cool because it allows you to pay for your insurance with XPro 2. So, we're going to have our agent that is a seller that's selling access to the LLM to Block Run. So, normally you might need an API key for something like that, but we're going to completely not need the API key because we're going to use X42.
So, we're going to have the buyer, the seller making uh communications over X42, and then the seller and Blockr run will also do X42 settlements as well. So in this scenario, the seller is accepting X 402 payments and the blockr run API is also accepting 402 payments. So the buyer will try to get access to uh the seller. The seller will say, well, if you want access to this LLM, you need to pay. The buyer will pay. Then the seller will say, well, I need to go out to the block and actually run the LM insurance, but I also need to pay. So it will make a payment and it will pay. So there'll be two payments and then we'll get all that come backing come back to our uh uh user here which
is the buyer who just cares about figuring out what the answer is. Okay. Um this code is not live yet but it will be live soon. Um we're going to this is actually like the very first time we've we've publicly done this demo. So it should be out um probably by the end of next week. Uh and I'll make sure that we get that shared with you guys. Um so again we already talked about what uh the single request looks like. I think we know that uh let's just talk a little bit about here about what it looks like in actual code. So um generally speaking you know when you're using something like um an SDK we try to abstract much as much as possible. So in in these
scenarios we're not actually looking at the XRO2 code. We're looking at this very very high level configuration of how the uh uh SDK needs to be configured. And in this case, most of the time we're dealing in two things. We're Oh, I hate when that does that. Hold on. Sorry. Uh we're dealing with a smart account address, which is a public key for a smart account. If you don't know what a smart account, a smart account is basically a um smart contract wallet. So you you might have an externally owned account on your phone or on your on your laptop on your browser. A smart account is a soft uh a sorry a smart contract wallet and what
it allows you to do is it allows you to like send payments from it um with some kind of additional logic which is very useful. So when we create a buyer for se for basically um buying the um uh LLM inference we need to pass in the public address the private key which is the you know how we sign the transactions and then the API URL for amperand. So, the reason why we're doing this, and I just want to mention this uh because it's a little confusing at first, is the cool thing about ampers is it allows you to require that something has to come back from the API before it actually makes
the payment and signs the payment using the private key. So, this is kind of like the the most powerful thing about this demo is in order to for the agent to sign and make a payment, it needs to go to Amperson and make sure that it has the ability to do it within its rules. So, it allows you to set up rules for your agents payments. Okay, that's pretty much the TLDDR. Um, and then here we have the Blockr Run API client. So this is where blockr run itself is um configured. So in this case we're have the base URL for the uh LLM and you can notice here that API key is XRO2 and
that's saying that there is no API key. We're not using API keys. We're only using XRO2 which is really cool. Um, and then this last one is just like how we have our agent configured, which is like, hey, you're a useful AI agent, and then it has things like the price, like how much does it cost, what network that we want to accept our payments on, stuff like that. Um, okay. So, let's try to run this demo real quick, and I'll kind of show you uh what we're working with here. So, we're going to first run, so again, it's an agentto agent demo. So, we're going to run the seller first. Okay.
The seller is a Python application because it is Google A2A, right? So, um, one how Google A2A works is when you spin up an agent, you that that agent is listening on a specific port like this and you get this agent card. It's kind of like if you're familiar with well, it's like it's like discoverability feature. So if you are trying to find an agent, you can kind of browse through all of the agent cards and you can find one that is matching what you're trying to get access to. So you can imagine in a world where you have like thousands of AI agents running inside of your infrastructure, it might get hard to
find them. This is where like you'll learn this next week. I believe you're going to learn about ERC 80004, which is like a registry and like uh stuff like that, but this is very specific to Google. Okay. And this allows you to build a bunch of agents, run them in a cluster, and then allow them to find each other easily by like these cards. So, we have our agent running on port 801. It's up and it's ready to go. And this is the block run agent. So, this is the seller agent. This is the one that has access to the LLM. It has access to the test net right here which has access to the open AI GPT OSS 20 bytes or I think that's 20 bytes. Um and it has a wallet
address so and it has a base price. So this particular agent is charging a fraction of a cent 0.002 um to be able to run LLM inference. Right. So then I can come down here and I can want run a query against it. Okay. So I can say all right same thing we're going to run this Python app which is also a Google A2A app. Run this script or this Python script which we can look at in a little bit. But in this case I want to be the buyer and I want to send in an LLM prompt and the question is what is 2 plus two? Pretty pretty simple, right?
So let's do it. Let's go ahead and ask. So, at this point, I I'm going to have two agents talking to each other using um this interference. So, here it goes. It's basically going out. It's finding the thing and then it's going to come back with the uh answer hopefully. Let's see. It's a little slow. >> There we go. >> Just to let you know, I managed to fix the stuff for the live stream. If you want to go live for the demo, feel free to let me know.
>> You you want to go live on X for the demo or >> Yeah, sure. That's fine. Yeah. So, just just one minute. Um and we're good. If you want to start uh maybe just >> Yeah. Yeah. Yeah. I can I it'll be a good good reviewer, too. So, I'll stop this agent for now. Yeah, that's a good idea because I think this is definitely still a little confusing. And so yeah, I can kind of briefly Yeah, let me know when you start. >> Yes, sure. >> I can have some coffee. >> Okay, so create broadcast X.
>> See if there's any questions while we're waiting. Oh yeah, someone calling out my web three privacy now. All right. Um, yeah, happy Friday the 13th. It's crazy. I always get scared on I like what's going to happen on Friday the 13th. I always like feel like something bad's going to happen. Yeah, if you have questions, please let me know. Um, so for the the demo we're going to do is going to be on basolio. So currently amper send only is supported on basolia. XRO2, you know, will work on any chain. Um the main thing is we're doing smart accounts on XRO2 on base uh or sorry we're doing smart accounts on base and uh we do some
like auto topup stuff with the accounts and so that's the current chain we support. We're going to be adding more soon. >> Okay. So feel free to let me know when you will be uh ready uh when you I just switch the same. Uh let me just check on X if all good. >> Mhm. No problem. >> Yes. Yes. Are goods on X. So I can um uh just guess what you want to start with like with the demo I guess. So here it
>> Sure. >> Okay. So let's go. I will tell you when all good. >> Okay. >> One question if I may ask quickly. H are we supposed to follow up or you are just going to do it for us to to see it? >> Um well, so this one's not public yet, but if you guys um want to to do this on your own, um you it's really up to you. We're we're going to release this publicly next week, I believe. Um and so once it's available, I'll give it to Selene and then she can give it to you guys or I'll I'll put it in the Telegram
chat. I know you guys have the telegram chat. I can drop it there. >> Great. Awesome. Thank you. >> All good. We can start. >> All right. Here we go. X42. X42. You guys missed the first part, but we're going to dive right into the demo right now. Okay, cool. So, uh, we're going to be talking about specifically the ampersand and blocker run integration that we are going to be unveiling next week and we're going to do this demo. Um, so basically the TLDDR and the demo is again we have a buyer and we have a seller and agent in an agentto agent architecture. So if anyone's not familiar with Google A2A again it is this agentto agent uh architecture where agents can talk to each other pay for stuff using XRO2 and kind of uh yeah
operate autonomously right that's that's the dream goal right and so in this architecture of this demo we'll have a buyer and a seller agent and the seller specifically is selling access to Blockr run AI so blockr run AI you guys have probably heard of you you know, open router or you've probably heard of uh, you know, the individual providers like Gemini or Claude. Blockr run is awesome because it allows you to pay for your LLM inference using X42. So, in this scenario, we'll have a buyer talking to a seller. The seller will also need to pay for his data that he's getting from Blockrun. So, the buyer pays the seller,
then the seller pays Blockrun. So, there's two different X42 transactions that happen. and settle all of this with no API keys. That's like the most important thing to think about here. No API keys, all XRO2. So, we talked briefly, I'll just mention it here. We have this idea of a of a single XR2 transaction. Um, in one request, the buyer wants to get access to the LLM. The seller says, "Sure, you need to pay 0.002 cents or dollars, uh, which is a fraction of a cent." the buyer signs and makes the payment uh via the you know xro2 standard. The treasurer uh checks to make sure there's not a daily limit.
So in this scenario we're using ampersend which amperand is our uh management platform that allows you to control spending. So we're basically going to issue a private key that has a it's kind of like giving a a a teenager a credit card. you know, we only want to give them a small amount, right? We're going to give the buyer like a little tiny $100 tally or something. Uh, and so this treasurer pattern allows us to set these limits and then the seller also needs to send the data to block run to get the LLM interference completed and it needs to make a payment. So, same thing. And then the LM response comes back and then the seller gives the response to the buyer.
So it's this proxy solution for agentic uh communications over xro2. That's the beauty of xro2 is it's all uh proxy level http um payments. Okay. So we have outbound payments. Um in this case we have the the seller paying blockr run. So we have the same configuration kind of in both scenarios. when the buyer wants to sell the uh when the buyer wants to get access to the LLM interference, it needs to pay the seller and it has certain rules. Same thing goes for the seller. When the seller wants to pay Blockr run, it has these certain rules that need to be uh
controlled via this API. So you can think of this as the the credit limit, right, that the that the agent has. We pass the private key and the public key and then we have the access to the open AI and what's important here is there's no API key right we are using all X42 um and then yeah then we have this like very last inbound which is the buyer paying the seller same similar thing the difference is that we are specifying what LLM that we care about um and we want to use what network that we need to pay on how much we need to pay and the pay to address. So this is all stuff
that's handled via the SDK which is really really useful. Okay. And then this is what a treasurer looks like. I didn't talk about this earlier but this is very useful. So the again the treasurer you could think of it as like the gatekeeper for how the agent is allowed to spend his sign his payments right with ampers we control that right using this special API and it has its credit card information or not has credit card it's private key information uh just like a normal agent would and but instead we uh make it pass through the treasurer right here. Okay. All right. So let's do it. So this is a Google A2A application. We're going to spin up a the seller first. So Google uh
A2A is primarily written in Python. So this is a Python application. We're going to pass the seller flag. So this agent is selling access to the blockr run LLM. And what what what we're going to get here is the public address for the agent, what network it's on, what network it wants to get paid on. Uh let me move this real quick. Okay. What network it wants to get paid on. Um what uh the API is for the LLM, what LLM it wants to, you know, sell basically how much it costs to make queries and the port. And then we get this well-known card, right? This is like the
discoverability layer for Google A2A. And so it's up and running. Okay. Uh now we're going to make one simple simple query. So we're going to do uh Python examples as a buyer and we're going to send in what is 2 + 2. Okay. Answer. So we should at this point what's happening is the buyer is saying oh I want to figure out what 2 plus two is. It's talking to the seller. The seller says you need to pay me. it is going to go back and create a signature uh for the request. It's going to resend it. Then the seller is going to say, "Cool. Now I need to go to Blockr run." Blockr run is going to say, "I need a payment." It's going to sign, send the payment, and all
this is going to get verified on chain. And then all the data is going to come back from the LLM and come all the way to the client, which that's what happened right here. We got 2 + 2 equal 4. Okay, so it is working. We have this agent talking to this agent and this agent is talking to Blockr run. And the important thing to note here is that we have no API keys. No API keys. This is all done using XRO2. So um I want to just go up here and take a look and show right here. This is the payment stuff which is super useful. So we have the again we have the scheme was exact.
The chain was based Sapoleia. The amount required was 2,00 I think in this case it's guay or no it's it's it's with the lowest denomination valuable value which is 88 decimals I believe which is 0.002 002 cents or $2. And it has the resource that it needed to get access to, how much it needs, uh why it needs to make the payment, uh the type of data that's coming back, uh who the payment has to go to, what the asset is, and the this is the spec specifics about the asset, what what the token uh name or token is, the token symbol,
uh and what version. And then here you can see where the validation happened. So this is where we actually verified that the payment was successful and it was true and the payer was validated. So we we validated that transaction. Okay. Um and you can see that it happened twice. So we have the payment to the seller and we have the payment to the LLM. Okay. So there's two X42 transactions that happened here. Okay. So um what we can show real quick is let's just go to uh stage so API sorry staging.ampers.ai AI. So we have two environments for
ampers. We have our production endpoint and we have staging. Um they're currently uh you have to like request access for production. I think the stage is open. Um but if we come over here and look at our agents with activity and we go to I think it's Suzy the seller and Zack the buyer. Yeah, it's these ones. So, we can open up these. So, I have two agents in this scenario. Um, this is the seller that's selling access to the LLM. Okay? And this is the buyer that is access uh requesting access to the LLM.
So, we have these two kind of like uh things here. What I can do is I can control spending on these. So I can say like oh I want to control and I only want him to spend a penny. Okay, just for the sake of demo. So he can only spend a penny and the seller who's trying to access the LLM also can only spend a penny. Okay, so this is the the cool thing about Amperson is you can have these keys and you can like control their spending. So I've created these control guardrails for the buyer and the seller. So now if I come over here and rerun my demo, but in this case I'm going to run a load test instead, which
is a bunch of requests. I'm just going to send the same thing over and over and over and over and over again and let it run. And what we're going to get is a bunch of transactions that were successful, but then we're going to just get failures because we're essentially using a percent to control with that treasure pattern, right? So, here we go. We got like uh some settlements happening. And there we go. So, we were able to do two transactions uh but then the rest failed because of the spending limits that were imposed.
Okay, so this is the kind of cool thing about uh agent spending is you can literally just give an agent a private key, allow it to transact. Um but at the same time with something like amperand is you can kind of control those guardrails and again this was all LLM queries. So, this is like a perfect um solution for something like open claw or you know something where you want to give it access to do a bunch of stuff but you don't want to go out and give you a $100 bill at the end of the day right one.
Okay. Uh so we got about 15 minutes. What I want to do is show one other real world use case that so that that's a very like kind of a technical use case of like what the architecture of XRO2 transactions should look like. Uh but more specifically what like how how else can we use this in a real world scenario? So I mentioned earlier that I'm also uh the creator of Spritz uh co-founder of Spritz and really what we have here is a it's just a chat application but it has some interesting features that we might want to monetize with XRO2. Okay, one of the first things is let's say I want to
uh let someone communicate with me uh and create a call. I want to be able to sell my time, you know, through the platform. So, uh, if I come over here to settings, I have kind of all my little settings here. Um, but more specifically down here, I have this calendar, right? So, I've hooked up my Google calendar to Spritz and it has access to my full calendar, very similar to Kalanly, if anyone's ever heard of Calendarly. And I also have these availability windows. So, I have like Monday through Friday from 8 9:00 am to 5:00 pm central time.
I'm in Texas and they're all active and the windows are all working. Then I have this uh chat enabled scheduling chat functionality. And what I can do is I can have my own custom URL here and I can say cool let's meet uh I like building applications on Ethereum and I can do a free consultation whatever this is just for me to give to my friends or like people I'm co-working with or whatever but then I can also have a paid session right so I can say well I'll actually meet with you for you know 120 minutes and it costs I don't know 50 USDC right and I choose what network that I want to receive my payments on.
I'll use base and then I can choose my address. So this is the address I'm connected with. So it's already there and I can save. So this is a perfect example that like maybe I at some point want to allow people to just schedule time with me. Um this would be they would try to call the API and when they tried to access it they would say well it's fine but you need to pay. So let's let's just try it and see. Uh, obviously I'm not going to pay $50 to myself, but let's just see what it looks like. So, here we have like let's meet with with Grexle. I have the free and then I have the paid. And I haven't tested this in a little bit, but uh because it's not it's kind of a beta feature, but let's see.
So, let's say I wanted to do a call for I'm gonna have to go to the next week because I'll be in Yeah, let's do the 26th. So, we click that. It's going to cost $50 USDC and I go can schedule a call at 9ine right here. Say like what what do you want to do? Well, Kevin uh edge node.com talk about scripts and then hit this button. So, uh I don't have enough balance. So, you can see it failed. But if I had my wallet connected, which I do, and I had a balance, then I could pay this $50 over XRO2 and then it would So it this is a XRO2 in in the middle of the proxy
that's just saying, well, in order to make this final pay like you know acknowledgement, you need to pay. So that's one use case that we have in spritz. Another use case that we have is our agents. So, inside of Spritz right now, this is also a beta beta feature, but you can create an agent that has access to specific tools. And so, here's an example. Like, let's say we wanted to create an agent and we wanted to call it uh subgraph expert, something like that. Uh we could give it a p personality. We could make it a public agent that people can find. We'll call it the graph. And we'll give it some tags. blockchain
data. I don't know. Let's put a few tags and create it. And then I can take this agent and where is it at? Uh oh my god, did it create it? Yeah, here it is. Subgraph expert. And I can give it access to special information, right? So, let's give it access to graph node, which is a markdown uh sorry, a git git repo. And let's also give it access to uh the graph.comdoccks and can we can ingest these kind of like endpoints, right? So we're like building an AI agent inside of spritz and indexing these into its knowledge base,
right? And then we can also monetize it. So let's say that I want to uh we we support adding MCP servers as well. So if you have like a subgraph MCP server configured, you can add it here. If you have an API configured that you want to have access to, like maybe you want to give it a certain API URL, you can add it. And then you can um enable or disable web search, whether it has access to it knowledge base, but more specifically on the bottom here, we can give it XRO2 API access.
So you could set up an agent all using no code, give it a MCP servers, API servers, access to whatever its knowledge has and then you can monetize it here. So we have this a way to u do a global payment or pay per tool. So you can say like all right well I'm going to charge a penny every time someone calls this agent or right now we only support USC. Um and you can share see where you want to uh accept the payments. And so now if I save this this this agent is uh configured and it's right here and we have integrations to show how to test
it. So if we were to try to do it now, let's try to curl it. Let's see. There's a uh example code. Here we go. Let's see what it does. So here we have this this this example curl to query it. Let's come over here. Let's try it out. It's going to say, "Well, that's great. You can get access to that data, but it's going to cost you one penny payment required." So, it failed, right? So, this is a another use case. If you're building agents that have access to data or have access to something, then you can enable XO2 for those agents.
Okay, cool. I will stop there and I think this is a good time to to stop and answer questions that people might have >> since uh for or the demonstration uh for for the moment no question but don't hesitate um like maybe uh I have one just about the name like maybe because it's not like sexy at all say x402 like if you have to rename um this protocol Well, like do you have any name in in mind?
>> Oh, because they're saying X2 simplify. >> Oh, yeah. XRO2 is a little bit hard to say. It's a little chunky. Uh, I guess it's very developer friendly. Um, I don't know. That's a tough one because uh yeah, there's so many like existing payment protocols that are like web two-ish, like you know, Stripe. Uh, what are these other ones? Um, yeah. I don't know. I don't know what I would call it. I'd probably call it uh Zap. I think Zap's a cool one. I was actually gonna create a wallet called Zap. Like Zap would be very like catchy.
>> Zap. >> All right. All right. Yeah. So, as I mentioned at the beginning, like there's some um projects right now that are integrating X402. Um like I know anaton has been run recently by it foundation and Kevin you were mentored there like uh do you have any kind of project in mind that that is coming up through this agaton um I remember one uh but not in this agaton like probably I will just talk about it because it's related to students so basically uh it was an agent that was there just to negotiate
prices like to access resources. So when you were students it was cheaper to access resources than if you are like a user classic user already rich let's say um so this kind things like this that can be great I remember they uh it was like um just an agent you were uh asking okay I want to get access to these resources it was like a report about I don't remember which on um but it was a paid one and so the fact that they were uh students it was something that um including ZK behind it but I mean they
were able to to to understand that people behind uh was student and so just providing a discount a real discount uh just because they were students. So there's like a lot of use cases to be honest into X402. Uh so yeah, I think that it's something that we will explore a lot during the upcoming months anyway. Um and uh and yeah um maybe uh could you uh go through the starter kit um like which starter kit we can use basically to build a agent especially um maybe I remember Nad was doing like has
built something. Yes. Yes. Uh this one as well. Um but Nad bu build built something like a starter kit and yeah I remember sky for as also like an extension about it. Yeah maybe go through. >> Yeah I I don't know. So uh okay so I know of a couple. So, if you want to get started like quickly and easily and you don't really know much about Ethereum, there's this XRO2 that was created by Carlos uh at the build guild, I believe, uh that is an extension. So, you can basically do um you know a scaffold installation and you just do E at the end and the next row two. So, that's
one. There's also agent zero which is specifically focused on ERC. Uh is it this one? I think it's this one. Agent zero. I don't know if that's not the right one. Uh, agent zero ERC804. I don't know the URL. So, this is Marco Dasi's um, uh, project. It's basically an SDK that gives you access to Oh, here it is. Ag0.xyz XYZ um which gets you access to building agents that are ERC 80004 enabled. Um I guess the benefit here is that he is one of the core contributors on ERC 80004.
So if you're building an agent with agent zero, you can kind of guarantee that it's going to be able to handle all of the functions to do registration and work with the protocol. Well, um, we're probably going to add a a way to make it easy to work with agent zero with the ampers SDK. That's another one. Obviously, I talked about that earlier. If you go to edge nodes GitHub, there's ampers. SDK. Um, I'm trying to remember what Nat's uh AI starter kit is. Do you remember what it's called? >> Um, it's for the route to starter kit, I guess.
>> Oh, yeah. So I think his name is Natter exposed >> on GitHub. Yeah, it was on GitHub. >> Yeah, I think his name is uh Natter on GitHub. Yeah. Oh, here it is. >> Yeah, >> dabbit. Dabbit 3. I always forget what is GitHub. Um yeah, so I haven't used this one, so I can't really speak too much to it. Um let's see. It looks like it's been around for a little while, but it hasn't had updates in a while. So, I love Nat, but I think he's really busy guy and so I just don't know if this one's, you know, up to date. Um, but I think it's maybe it's a good starting point to toy around with. You know what I mean?
>> And I remember one just phase like one or two two days ago. Uh, I mean, it's a good good um resource to go through. Uh, it's like aic wallet from CDP. Yeah, they just released that Aentic wallet >> on coin coinbased developer platform. Oh, yeah. Yeah. Yeah. So, yeah, they they're they're doing something uh they're actually doing something similar to what we're already doing at Ampersend, but um yeah, they're trying to do like hosted wallets. I mean, technically, you don't need something like this to build agents. you can just use like uh basically embedded wallets with
Coinbase. So you can basically like hook up their CDP um stuff and you can just do your own embedded wallets. I think this is a yeah a little bit different. Let's see here. So this one has uh standalone wallet. Okay. So, I guess this one can call MCP tools. Yeah, this one's specific to base. >> Yeah. So, I think if Yeah. So, I think there's definitely some things where it's interesting, but >> Yeah. I don't know. I don't think you want to build something that might just only be for bass. Yeah. I don't know. I
need to look at it a little bit more. I know it just came out like this week. So >> there's couple of question on the chat. So maybe if you want to go through it. >> Yeah, for sure. Absolutely. Um right let's see here. Is the agent identity tied to Google layer or could it work with decentralized IPs too? Um, so I think in like a Google A2A architecture, um, this is just for like if you're running agents inside of your own infrastructure, how they kind of like find each other.
I think that you would basically add any kind of like additional identity like there's no reason that Google A2A agents can't also be registered with ERC804 and that is the mechanism for finding each other. Um it's just think of the the agent cards as just how they kind of uh find each other, right? And the Google A2A is just a a way for them to like orchestrate each other and and find each other. Um can we use spritz for normal actions like tool type calendar can do ages video calls? Uh yeah so right now like spritz is can hook up to any MCP server pretty much any API. Um it has access to
your calendar. So, one of the things you can do is you can have like an AI agent that you can send to anybody and just be like, "Hey, can you can talk to my assistant and he'll schedule time with with you and you can literally say, hey, like schedule a meeting for me and it will be like, sure." And it will fetch the calendar and do all that stuff. Um, and so that's very very useful. Um there's also access to like um uh events databases in there and you can like uh you can work with spritz to like create custom agents. So if anyone needs a custom agent, let me know. Uh for like events or whatever.
Um yeah, the there's a good So also for the spritz stuff, if you go to docs.spritz.hat uh I'll put it in here just so you have it. um that has all the specifics of like what you can do with the agents. Let's see. I think that's all the questions. Yeah. Yeah. There was basically Yeah, I think got all the questions answered.
>> All right. All right. All right. So, thanks a lot um for the session and sorry at the beginning. Sorry. Oh, no worries. >> So, on the on the live stream, we skipped the explanation of X402, but that's all good. Like, everything will be on on YouTube anyway. All right. >> Yeah. And and I was going to say if if anyone has not check out Spritz, go to app.sitz. And there I created an X42 channel for us to talk in. So, come in there and let's talk about X42.
It's my last initial. >> All right. All right. So just to let you know for everyone so the next the next uh session will be with vis from Foundation about ERC 8004. So yes still some weird weird name for everyone we entering into the space is like horrible. Anyway um but uh yeah we will talk more about agent reputation so next time. All good. All right. Thanks a lot everyone.
>> Bye.