The Trustless Agentic Economy with ERC 8004 and x402 | Jake Hall

Okay, I think we're on the air. Today we will talk about AI will talk about AI agents. First of all, I want to say that I can't do this live. It's quite late for me quite late for me , so I recorded it in advance. But we're going to dive into this topic really deep.

We'll get into the technical details, quite seriously, to be honest . About how to create AI how to create AI agents using the latest innovations in AI and Web3. In particular, we will look at how to create agents that can earn money and pay each other. AI agents that have their own identity in a decentralized ledger, the blockchain. As well as the latest technologies for communicating with such agents.

So, let's move on to the three main pillars that we will look at. As I mentioned, the first is the identification level. This is the ability to identify AI identify AI agents, know their location, and trust them. As we move to an “ move to an “ agent network” and interact with AI more and more often, we already use ChatGPT every day. This is the AI ​​agent in our browser.

Companies are now releasing special agent browsers. Very soon, within a few years, companies will open up access to AI agents. And our AI agents will communicate with other AI agents. We need to know exactly where they are. Is it on a web server?

Or somewhere else? We also need to know how to trust them. And blockchain offers a great way to do this in a decentralized way. We will analyze in detail how blockchain provides this. Another thing you need is a level of communication.

You should be able to communicate with the AI communicate with the AI agent programmatically, as a human or as another AI. That is, using certain communication channels communication channels . For example, through HTTPS . For example, through HTTPS requests, POST requests, or similar methods for AI similar methods for AI agents. And finally, a payment level is needed.

You need to be able to pay the AI ​​agent, because sometimes it performs tasks that require payment. So, you should be able to pay them off. Again, blockchain offers a really, really good solution for this. So for each of these levels, we'll look at the technology that's becoming the most important right now. At the identification level, we have the ERC-8004 standard.

At the communication level— Google's A2A is now an open source protocol. I think it's owned by the Linux Foundation now, but "agent- Foundation now, but "agent- agent" is a kind of communication protocol for agents. And finally, regarding payments—we will look at XPRT. I'll jump right into the code because I think seeing it in practice will help you better understand the theory behind it. If you want to participate and take a look at this repository we will be working with, scan this QR code scan this QR code .

I'll leave it on the screen for a while. This QR code leads to the GitHub repository with all the folders and source code we will be working on today. Good. So, let's move on to the code. And the first thing we're going to look at is more of the agentic aspect of communication.

We'll quickly review the A2A quickly review the A2A . One of the repositories, one of the folders that you see here in the root directory—that's A2A agent. Just to quickly see what a real real agent looks like, essentially you have a server that hosts the agent. And each AI agent, according to the A2A specification, has an agent card. This agent card, all these types and APIs can be found in the A 2 A-JS/SDK repository.

There is also a version for Python. But each agent has a card that tells what the agent does, where he is, what skills he has, capabilities, for example, streaming. Streaming is the same word- by- word flow of messages that you see when communicating, for example, with ChatGPT. It doesn't appear as a whole block at once. It is transmitted gradually.

So, it tells you whether the agent is streaming, what the default input and output modes are, and various data points that allow the client to understand exactly how to work with that particular AI particular AI agent. So you implement this class and then host it on the server. In this case, we host it on an Express server. I don't want to go into too much detail, as we'll actually look at this in the context of payment this in the context of payment . But this is essentially the fastest and easiest way to start a server that is compatible with the agent- agent- agent protocol.

And right now, all that's happening is that every time the graph sends a request to the AI ​​agent... a request to the AI ​​agent... It's inconvenient. This should be a "Hello World" greeting. Uh-huh.

Whenever a request is sent, all that happens all that happens is a response with this message. So in this case, it's very simple, but usually, and we'll see this in the next example, this would be used with a real AI with a real AI agent. As for the client agent. As for the client connecting and sending a request to the agent, you again have the helper functions and types coming from this A2A JS SDK. And all you need to do need to do is create a client that connects to the agent card.

You hand over the agent card there and just send her a message. And again , in the case of an AI , in the case of an AI agent, this would essentially be your prompt. But this is just a very brief overview of A2A. I want to show this in practice, namely in connection with the X402 protocol. So let's now move away from the topic of agents for a bit.

We will focus on the X402, just the X402 and what just the X402 and what it really is it really is . X402 is a web protocol that makes it very easy to accept crypto payments, such as stablecoins. It makes it very easy to accept crypto payments on existing web servers existing web servers . Let's say you have a web server with business web server with business logic. And I want to get myself back on screen again because I think it looks a little more interesting that way.

Let me... Let me... Let me move all of this. Give me a second. That's it.

So, this is what I have . So what does X402 do...I just got rid of that. X402 provides a way to accept payments for an API that you might have, for business have, for business logic, your intellectual property—something valuable, by allowing you to wrap it in a payment middleware layer. This means that when someone wants to access your resource or business resource or business logic, they need to pay you a certain amount in stablecoins.

So, this is great for implementing micropayments. A good example of this being used in the real world is real world is Cloudflare. Cloudflare is one of the main contributors to the development of X402. They are part of the X402 fund. And Cloudflare is discussing implementing pay-per- view.

That is, when you go to the virtual Financial Times or another quality news platform, you can either purchase a subscription or pay per request using the X402 protocol. See how simple it is. This is potentially another way to generate income. This is also especially true for AI agents, right? Where an AI agent can scan these data sources, use them for its own training, but still pay a fee.

Let's see how this looks in practice. I've told the theory, but let's see it in action. For a developer who wants to set this up, it's very simple. It looks a little less appealing now. But that's because I have the Agoric A2A code here.

Let me show you what it looks like in another repository. I'll move on to the X402-Hedera. I'll come here, where everything is a little tidier. Let's move on to examples. This is an implementation of X402 for Hedera an implementation of X402 for Hedera .

You can find it on Hedera-dev X402 Hedera. If you open servers and go to express and go to express server, you will see that you can simply take an existing express server with all the endpoints: GET and others. These can also be POST requests. And all you need to add is this intermediate layer. So you go to the XW2 express library, import this intermediate layer, and for any endpoint that you want to start getting paid for using, you just specify it in this intermediate layer.

So, for example, here, the GET endpoint, get Hedera Hash USDC, would cost, uh, one- tenth of a cent. And in those 15 lines of code, we have now effectively restricted access to those two endpoints. Um, and it really is that simple. This, this, this is very convenient for developers, which is why it is becoming more and more popular. Now we have configured our A2A server, as you can see here we have an "agent- we have an "agent- agent" server.

This code looks quite similar to the one I shared earlier. And, uh, do-do-do. I lost my mind. Sorry about that. So we have agent-agent logic here.

And then we configure it to run on this Express server through the A2A endpoint. This is a POST endpoint. And we're basically saying, "Okay, I'm going to use that middleware shell for payments to wrap the A2A server." And I will say that every time someone interacts with this server, it will cost them one tenth of a cent. So, to summarize: we're creating an agent- agent- agent protocol server right here.

We have our agent card. We create our agent executor. And we configure it using all the utilities and aids that A2A provides. Uh aids that A2A provides. Uh , then we use this app builder.

set up routes method to say, "Okay, we're registering our AI agent with this A2A endpoint." Although, of course, it could be anything. This could be, for example, a test agent. It could be anything. Um, and right before that, we use a middleware helper function with X402 and say, "Okay, every time someone wants to do a POST to this A2A endpoint, they'll have to pay one- tenth of a cent."

Um, and with that, we can now move on to the client and start interacting with it . So before we do that, I want to provide a little more context on the architecture of the X402. So, there is another interesting player in the X402 architecture — it is the facilitator. And in essence, the facilitator helps to separate the tasks of blockchain logic and business blockchain logic and business logic. So, as an engineer, as a developer an engineer, as a developer who has your own product, you want to start monetizing it.

You don't really need to worry too much about blockchain. The only thing you as a developer need to specify need to specify is the facilitator URL and where user payments should go , i.e. the payment address. And with this, you don't need to perform any blockchain any blockchain transactions because essentially all of this is delegated to the facilitator.

So, the facilitator in our case—we're going to run it locally. But the facilitator is responsible for first verifying whether the transaction generated by the client is generated by the client is indeed legitimate. And then, once that's done, it will complete the transaction complete the transaction , that is, actually execute it. So, we have this facilitator we have this facilitator who is responsible for this. But I just wanted to mention this facilitator.

This is a very important part of such a research architecture. It separates the actual blockchain execution on a different server, and multiple users can connect to the same facilitator. Many people can connect to the same thing . From the client side, we will do a quick code review. This is in...

yes, for those who want to know where the files for this are. All of this is inside the X402 folder. And if you go into the TypeScript examples, you'll see that we have an Express server, a facilitator, and an Axios client. And what this Axios client does is...It just simulates an actual request to the endpoint.

So, in this case, we're going to make a request to our server, which hosts the AI ​​agent. So, we're making a request to the server here. We use the auxiliary payment interception function from X402. And we create our signer. Our follower is apparently a Hedera account.

We have an RPC request. This is actually just the request body that is sent to the server, as the agent- agent- agent interaction uses the RPC protocol. It uses more than just a typical REST API. It uses RPC and JSON, just like JSON RPC requests. And then we just send this JSON RPC request to our endpoint .

And then we see here that we are simply conveying the logic. Let's see this in action. Let's see how it all looks together. So, on each of these endpoints, on each of these servers that I run, I, I, I will double-check everything. But I have, oh, I have my facilitator, so I'll run PNPM dev to deploy it.

And of course, I have some environment variables set up. If you look at the read me file, you can see this for yourself. I'm going to start a server, the same server that has an agent- agent- agent endpoint. And in short, what does this agent actually do ? So if we look at our agent, we'll see that, just like in the first example, we have this agent executor.

We have a function to execute. But this time we're doing something a little more substantial than just a pre- written response. We actually call the AI ​​agent that we have. This AI that we have. This AI agent is very simple.

That is, it's not even an agent, it's just an LLM. It randomly selects a stock from the Nasdaq exchange and then provides a summary of the company. So, it's very simple. We take a user request, the text that the user or customer sends, and generate a response. And that's what we then send back.

So this is what would cost 1/10th of a cent. And from the client's side, we send this question or this request question or this request : "Tell me about the promotion." So, the facilitator is running, the server is working. Now I just need to test running this script. I also run pnpm dev.

And we'll see that we get a request and a response from the agent: "Agent message, sure, let me randomly pick a stock from the Nasdaq exchange, DocuSign." Gives me some information about it. And we see that the transaction was also successfully executed. So if we move on to our...if we move on to our...

There it is. If we go to our hash scan, we will see this transaction ID. And we sent 1/10th of a cent to sent 1/10th of a cent to ...and here you go. Yes, 1/10th of a cent of USDC to this recipient account that was specified as the account for payment.

So, that's pretty cool. That's pretty cool. Essentially, we have set up an AI we have set up an AI agent that can receive payment using the A2A protocol. And the client, who can also be an AI can also be an AI agent, is able to pay for it. And that's really powerful.

But you might be thinking, “ you might be thinking, “ What about trust?” This is what we all hinted at earlier. If these agents are autonomous, of course, it's a very controlled environment where I have a server of A2A agents. I know it's safe to use because I created it. I am also a customer.

But what if we find ourselves in a futuristic world futuristic world , which is probably not far away, where AI far away, where AI agents have a lot of freedom, will, and control. They can discover other AI agents. They have the ability to connect. I have an AI agent that works on my behalf and knows everything I need to do every day. Maybe it's a business agent.

He knows exactly when I have meetings. He knows exactly who I need to talk to. Maybe he's starting to investigate this client. Maybe it goes to a data broker, where my AI agent goes to a broker agent who sells data about other people, like Facebook or the like. I'm just thinking out loud.

I didn't think much about it, it just came to my mind. But my AI agent needs to know that if he pays this AI agent for information about a business opportunity or a conversation I'm going to have . My AI . My AI agent needs to know that it can trust and that this AI agent it is interacting with will truly provide value. And this is where ERC-8004 comes to the rescue.

So, ERC-8004 ERC-8004 is basically just a set of smart is basically just a set of smart contracts. Now I'll quickly find this... quickly find this... give me a minute, I have to look for...um...

the article. Yes, let me find a very good article that I should have discovered earlier. Um... I hope I can find ...here it is.

So, here's a brilliant...Um...Okay, here it is . This is a great article that gives a general overview of ERC-8004, what it actually is. And as it says here, it's a standard that defines a framework for autonomous agents to identify each other, find each other, evaluate each other, and interact without the need for trust.

So, it has three registries: an identifier registry, a reputation registry, and a validation registry. And each of them is a composite primitive that a developer can build on to actually create applications that allow agents to trust each other. So, identity, as I briefly mentioned earlier, provides an ID to the agent , it's effectively an NFT. And it has a diagram that could point to perhaps your "agent-agent" card if you have an agent to interact with. And he also has this reputation register.

So, basically, we'll get to that. I'll do a quick demo quick demo , but you can tie the reputation to your AI agent, to its ID, so that, for example, when I want to use a data broker agent, my agent can look at all the reputation and reviews to decide whether to trust it. And finally, you have a validation registry. It's not always necessary, but I view it as a kind of reputation for reputation's sake. This is simply a guarantee that this reputation given to a particular AI agent is not completely fabricated.

This is not some hack. This is not a fake. And validation is actually checking, "Okay, does this reputation have any weight, does this feedback have any weight?" I didn't go too deep into validation, but it's definitely important because it's very easy to completely falsify a reputation registry. But reputation registry.

But , as said here, this whole structure is very neutral. It simply gives you the primitives for further construction. But let's take a quick look at what it actually looks like. Again, we have code snippets in this repository. So if you go here, if you go into the ERC- you go into the ERC- 804.

js folder, and you go here, you'll see that we have this Hedera test script . Hedera test. Of course, I've already installed everything. I collected everything. But essentially, this Hedera testing script goes through the steps of registering an agent and then provides it with feedback.

So we can see it in parts. We will also run scripts. Maybe we'll run the script first, and then we can take it apart step by step. So, I'm in this repository and I just run PNPM test just run PNPM test . This triggers the execution of this script.

We have an agent owner that registers an AI agent, the same one we just created. So we see, for example, uh, here we're just setting up our EVM setting up our EVM addresses. We are registering our ERC-8004 client. We specify the registry. So specify the registry.

So , we already have expanded registers. You can find it on on ERC-8004 smart contracts on GitHub. But we are using this ERC-8004 client. It has many methods that we can use to interact with registries. First of all, we register an agent.

So what this does is, uh, we can look at the transaction hash. This does what it calls eh it calls eh -eh, it accesses the identifier register. Nothing strange. Uh, where am I...Let's make this smaller.

Yes. So this will access our ID registry right here. Uh, and it's basically just swapping NFTs. That's all it is. And the owner is the one, uh, who actually registers it.

So, the account that I set up this client for and that has a signature will be the owner. Now we can get the agent ID in the response. And after that, we can set the metadata of our AI agent. So, after creation, we get this agent ID and with it we can generate metadata here, this is a standardized schema. And you'll see that we're passing endpoints.

So, we have a title, description, and endpoints. This is the A2A endpoint, and it points to our agent that we configured. If we go to our server, we'll see that we have this agent card that we deployed earlier. This is what is inside the Explorer 2 Hedera repository. Uh, and all the trust mechanisms are listed there.

In our case, it's just reputation, but there may be other trust mechanisms related to validation related to validation . Uh, and it's important that inside this registrations array we point to the agent ID in our ID registry. This is very important because it ensures that the agent registered in the smart contract is the exact agent you want. It's not as if someone just accidentally registered an agent that doesn't belong to them that doesn't belong to them . This effectively proves that, yes, this agent belongs to me.

Now this is essentially being added to the metadata of that agent ID. This metadata can be hosted on a web hosted on a web server or in IPFS. You can really do whatever you want there. There are no strict requirements, but we set this metadata. And so it is.

Once we have the metadata set up the metadata set up , we move on to feedback testing. So, I'm going to explain how feedback works using our agent example that we had here. Essentially, what happens with feedback is this: when an AI agent or client interacts with a server interacts with a server —in our case, it was here—we had this script that acted as a client and interacted with this "agent-to-agent "agent-to-agent " server. When this first happens, the following must happen : The AI ​​agent on the server must authorize the provision of feedback. So, they will call the create feedback off method, which essentially means which essentially means : "I am allowing you, the customer who just spoke with me, to leave feedback on my reputation register."

And you can see that it lists the person who is providing the feedback. So, not everyone can leave this review. Only the person who sent the request can do this. So, the user will send, the client will send a request saying, "I want to pay 5 USDC to access your endpoint and your business and your business logic." And then the AI logic."

And then the AI agent on the server will say, "Okay, I'm giving you authorization so you can leave feedback in my registry." And after that, they will sign it, making sure once again that it was really authorized by them. And then a customer who is going to leave feedback will be able to do so using this signed feedback authorization token. This feedback is a score from 0 to 100, and you can also specify the feedback URI. This is quite interesting, this feedback URI interesting, this feedback URI .

It allows you to enrich the data provided to the AI ​​agent for their feedback registry. And the ERC-8004 documentation mentions the use of IPFS here. So use of IPFS here. So , it says here that you can use... we have this feedback.

So we have this feedback. So , provide a response, uh... that takes a file URI pointing to an off-chain JSON with additional information and its hash to guarantee integrity. Obviously, if you are just getting feedback and checking it, and those feedbacks are stored on a web server that can be modified, you will want to add a hash to the smart contract to see if anyone has made changes, because the smart changes, because the smart contract contains the original hash. If the hash has changed, it means someone has interfered and tampered with the data.

But the documentation here, EIP, also mentions that you can use IPFS, in which case IPFS is deterministic, it cannot be changed . So in that case you don't need to use a hash. Although IPFS still has its own problems, because the data needs to be pinned to the network. And there is a possibility that they may be lost. So in this example there is an interesting implementation that uses HCS, Hedera Consensus Service, which works on-chain and allows reputation to be placed on the blockchain as well .

So, I think this is a pretty nice and useful opportunity. This is a great use case for the Hedera Consensus Service, where you can have an immutable record on the chain that will never be lost. And you can use this for feedback. Actually, that's all. And then, of course, you can read the review.

The review will be indexed, so you can view it and use it as part of the search process. This is a quick summary of how ERC- ERC- 8004 integrates. I think you can see why this is important: if you're going to have AI agents interacting with each other, they need a secure way to trust each other. That's all I have . I started talking a little.

I'll come back here. So, the final call to action: join Discord. We will be very active in helping our community members on Discord. We are interested in seeing how you use agent-to-agent explorer and ERC-8004 to create the most groundbreaking applications that could ever come to light. It's a really exciting time, all these components are coming together and coming together beautifully.

So without further ado, I wish everyone a good day. Take care of yourself.