The Trustless Agentic Economy with ERC 8004 and x402 I Ed Marquez
ETHGlobal·Tue, Jun 9, 2026, 12:00 AM
In this workshop, Ed Marquez walks through the three foundational layers needed for a trustless agentic economy: identity (ERC-7804), communication (Google's A2A protocol now under the Linux Foundation), and payments (X2X). He frames the vision of a near-future agentic web where AI agents discover, communicate with, and pay each other autonomously, and demonstrates how these three open protocols together enable that economy. Ed does live coding demos showing each layer. For A2A, he shows how agents expose an agent card describing their skills, capabilities, and streaming support. For X2X, he demonstrates how just 15 lines of middleware can gate any Express endpoint behind stablecoin micropayments, using Cloudflare's pay per crawl initiative with publishers as a real world example. He walks through the facilitator architecture that separates blockchain execution from business logic, then combines A2A with X2X to create an AI agent that charges 1/10th of a cent per stock summary query. For ERC-7804, he covers the three registries: identity (NFT-based), reputation (score-based feedback with optional IPFS or HCS-stored details), and validation, explaining how server agents authorize clients to leave signed feedback, creating verifiable reputation that lets autonomous agents safely discover and trust each other. 00:00 Introduction 00:11 Three Pillars of the Agentic Economy 02:26 Technologies: ERC-7804, A2A, X2X 02:49 GitHub Repo Walkthrough 03:33 A2A Agents and Agent Cards 05:14 A2A Client Setup 06:00 Introduction to X2X Protocol 07:12 X2X for Micropayments and Pay Per Crawl 08:19 Implementing X2X Middleware 10:00 Combining A2A with X2X Payments 11:47 X2X Facilitator Architecture 13:33 Client Side X2X Integration 15:30 Live Demo: AI Agent with Paid A2A Endpoint 17:14 Verifying the Transaction on Hashscan 17:54 The Trust Problem in Autonomous Agents 19:46 Introduction to ERC-7804 20:58 The Three Registries: Identity, Reputation, Validation 22:23 Validation Registry Explained 23:16 Live Demo: Registering an Agent on ERC-7804 24:38 Minting the Identity NFT 25:54 Setting Agent Metadata and Trust Mechanisms 27:47 Reputation Feedback Flow 28:39 Authorizing Feedback with Signed Tokens 29:34 Feedback URIs: IPFS vs Hedera Consensus Service 31:20 Closing and Discord Call to Action _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ✅ *Follow ETHGlobal* X: https://x.com/ETHGlobal Website: https://ethglobal.com YouTube: https://www.youtube.com/c/ETHGlobal _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Are you interested in Ethereum development and entrepreneurship?_ 👉 Sign up for the next ETHGlobal event: https://ethglobal.com/events 🎁 Get exclusive access and perks with ETHGlobal Plus! https://ethglobal.com/plus 📣 Want us to throw an event in your city? Tell us where! https://ethglobal.com/city _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Transcript
We're looking at how you can create AI agents that can earn revenue and can pay each other. AI agents which have their own identity on a decentralized ledger, blockchain. Um and also the the latest technologies for how you can communicate with AI agents. So, let's get into sort of the the three pillars that we're covering. And like I mentioned, the first one is this identity layer.
Um it's the ability to actually identify AI agents, know where they're located, but also know whether you can trust them or not. Uh as we sort of go into this agentic web, where we're interacting with AI agents more and more often, we are obviously using ChatGPT basically every single day. That's an AI agent inside of our browser. Now, these uh companies are also releasing agentic browsers. And very soon, definitely within the next few years, we'll see companies expose AI agents.
And we're going to have AI agents communicating with other AI agents. We need to know exactly where they are, where they're located. Are they on a web server? Are they on this or that? Um and we also need to know how can we trust them.
And obviously blockchain gives a really nice way of doing that in a decentralized way. We're going to get into exactly how blockchain enables that. The other thing that you need is you need that communication layer. You need to be able to speak to an AI agent programmatically, either as a human or uh an AI agent speaking to an AI agent. So, that that's using sort of your your communication rails, like a HTTPS uh request, for example, post request, whatever, similar when it comes to AI agents.
And finally, you need to have a payment layer. You need to actually be able to pay the AI agent. Uh or not always, of course, but there will be times when AI agent wants to do something for you. Uh, and it's going to require a fee. So, you need to be able to pay them.
Again, blockchain gives a really, really good solution to that. So, for each of those layers, we're going to be covering the technology which is emerging as the as the most prominent as at the moment. On that identity layer, we've got this ERC 8004. On the communication layer, Google's A2A is now an open source protocol. Uh, I think it's by the It's actually owned by the Linux Foundation now, but agent to agent is sort of the communication protocol for agents.
And then finally, for payments, we're going to be looking at XPRL 2. And I'm going to going to get straight into the code uh because my idea is that actually by seeing it in practice, we'll be able to um by seeing it in practice, you'll be able to sort of better understand the actual theory behind it. If you do want to take part and you do want to have a look at this repo which we're going to look into, uh have a look at that QR code. So, I'll leave this on the screen for a while. Uh, that QR code will take you to the GitHub repository with all of the folders and and all of the source code that we're going to be working on today.
Okay. So, let's now go over to the code. And the first thing that we're going to be looking at is more just on that agentic Uh, we're going to be looking more on that agentic communication side. So, we we're going to be quickly skimming over A2A. Uh, one of the repos, one of the folders that you'll see over here uh right at the root is this A2A agent.
So, just to sort of really have have a quick look at what an actual agent to agent uh agent looks like. This is basically it. You've got a server where the agent sits on. And uh every single AI agent, according [clears throat] to the A2A spec, has an agent card. So, this agent card, you can find all of these um you can find all of these all of these types and all of these APIs from the A2A-JS/SDK repository.
There's also one for Python as well. But, every single agent has this agent card, which basically uh tells you what the agent does, where it sits, uh what its skills are, its capabilities. Kind of do streaming. Uh streaming is that sort of mess that word by word uh messaging that you get when you're talking to ChatGPT, for example. It doesn't come out all in one block.
It's streamed out. So, this tells you whether the agent does streaming, default input modes and output modes and the various sort of uh the various data points, which would allow a client to understand actually how do I deal with this particular AI agent. Uh so, there's you you sort of implement this class and then you host it on a In this case, we're hosting it on a on an Express server. I don't want to go into this into too much detail cuz we'll cover it actually within the context of the payment stuff. Um but, that's basically the most quick, easy way you can spin up an agent-to-agent compatible server.
And at the moment, all that happens is whenever a request gets sent to the AI agent via the That's awkward. Uh that should be hello world. whenever a um whenever a request gets sent, then all that's happening is it's just responding with this message. So, it's very straightforward in this case, but typically and what we'll see in the next example is we'll see it being used with uh with an actual AI agent. Uh for the client, the thing which is connecting and sending the request to the agent, um again, you've got sort of helper functions and and types which come out of that A2A-JS-SDK.
And all you need to do is you need to create your client which connects towards the the agent card. You pass in the agent card over there and you just send it a message and again with an AI agent that would be the sort of prompt essentially. But that's just a really quick coverage on on the A2A. Where I want to show it in practice is actually I want to show it in practice with regards to the X402 protocol. So let's now take a bit of a step away from agents.
We'll just focus on X402 We'll just focus on X402 and actually what it is. X402 is a web-based protocol which makes it very easy to accept crypto payments like stable coins. It makes it very easy to accept crypto payments on existing web servers. So say you've got a web server with business logic and I want to put myself on the screen again cuz I quite I think it's a bit more engaging. Let me uh Let me Let me move this stuff around.
Give me a second. Um there we go. So how about that? So what X402 does I'll just go over there. What X402 does it gives you a way to take payments for an API that you may have business logic, your IP, your your intellectual property, something which is valuable and it will allow you to wrap it with a payment sort of middleware layer.
Basically meaning whenever someone wants to try and access your resource, your business logic whenever anybody wants to wants to try and access it, they need to pay you a an amount in stable coin. So you can think of it as really great for enabling things like micro payments. And a good example as to where this is being used in the real world is with Cloudflare. Cloudflare actually one of the main contributors to X402. They're part of the X402 Foundation.
And Cloudflare they have uh they're talking about doing things like paper crawl. So, actually going to let's say the Financial Times or or a or a very uh high-quality news platform and actually going, "Okay, either you can buy a subscription or you can actually pay per use, pay per request using the Xr2y protocol." You see how easy it is just now. Um and it'll be potentially another way to generate revenue. It's particularly relevant for AI agents as well, right?
Where you can actually have an AI agent crawl these particular data sources, use it for its own training, but pay a fee. Uh so, let's take a look at actually what that looks like. Again, I've I've given sort of the theory, but let's see it in practice. So, um for a developer who wants to actually set this up, it's really easy. Um now, it doesn't even look It look It looks a bit uglier over here.
Uh but, if we that that that that that's because I've got some Agentyc A2A code. Um but, let's actually Let me show you what it's like sort of uh in another repo. So, I'm going to go to Xr2y-Hedera. So, if I just go over here where it's a bit tidier, uh and we go to examples. Actually, this is our Hedera's implementation of Xr2y.
You can find it at hedera-dev/xr2y-hedera. And if you go to the servers and we just go to the Express server, you'll see that essentially I I I've got the you you just take your existing server with all of these endpoints of get endpoint, a uh yeah, various get endpoints. This can be post endpoints as well. And all you need to add is this middleware. So, you go to the Xr2y-Express library, import that middleware, and any one of the endpoints that you have that you want to start receiving pay per use payments for, you just specify inside of this middleware.
So, for example, over here, the get in point the get Hedera-USDC is going to cost uh 1/10 of a cent. And with these 15 lines of code, we've now actually gated these two endpoints. Um And it's really that easy. It's it's it's very very developer-friendly, which is why it's sort of been picking up in adoption. Now, what we've done is we've set up our A2A server uh as you can see over here, we've got our agent-to-agent server.
This code looks quite similar to the code I was sharing earlier. And um uh do do do lost my train of thought. Sorry about that. So, we've got um the agent-to-agent logic over here. And then we're setting it up uh so it's sort of living on this Express server at the A2A endpoint.
This is a post endpoint. And we're basically saying, "Okay, I'm going to use that payment middleware wrapper to wrap the agent uh A2A server." And I'm going to say, "Every time someone interacts with that server, it's going to cost them 1/10 of a cent." So, just to sort of recap that, we've uh we're creating an agent-to-agent protocol server over here. We've got our agent card.
We are creating our agent executor. And we're configuring it using all of the utility sort of the the the helpers that that A2A provide. Uh we're then using this app builder.set up routes method to to say, "Okay, we're going to register our AI agent at this A2A endpoint." I mean, this this could be anything, though.
This could be um test agent, for example. It can be whatever you want. Um and then just before it, we're doing this middleware taking the using the middleware helper function from X402 and saying, "Okay, anytime somebody wants to post to this A2A endpoint, they're going to need to pay $0.01 per cent." Um And with that, we can now go over to a client and actually start interacting with it.
So, before we do that, I want to give a bit more context around the X402 architecture. So, there's another interesting uh player in the X402 architecture, which is this facilitator. And essentially, the facilitator helps separate the concerns of the actual blockchain logic and the business logic. So, as a engineer, as a developer who's got their own product, you've got your own product, you want to start monetizing it. You don't actually need to really worry about blockchain too much.
The only thing that you as a developer need to specify is what the facilitator URL is and where you want the user's payment to go to, the the pay the pay to address. Um And with that, you don't you don't actually need to do any blockchain transactions because essentially, what happens is all of that gets outsourced the facilitator. So, the facilitator in our case, we're going to run it locally, but the facilitator is responsible one for verifying the uh verifying the transaction that is generated from the client is actually legitimate. And then, once that's done, it will settle the transaction, so it'll actually execute it. So, we've got this facilitator, which is responsible for that.
Um But, I just wanted to sort of mention that facilitator. It's very important part of that sort of X402 architecture. It separates that uh separates the actual blockchain execution on a different server, and many people can connect to that same facilitator. Many people can connect to the same one. On the client side, we just do quick sort of code.
This is in a Uh yeah, for those of you who want to know where the files are for all of this. Uh it's all inside of the x402 folder. And then if you go to examples TypeScript, you can see we have the Express server, the facilitator, and the Axios client. And what this Axios client does is um Uh it it just simulates the actual querying of the endpoint. So, in this case, we're going to be uh we're going to be querying our server, which contains the AI agent.
So, we're querying the server over here. We're using this with payment interceptor helper function from x402. And we're spec we're creating our signer. Our signer is obviously a Hedera account. Um we've got the RPC request.
So, this is actually just the request body that gets sent to the server, because agent-to-agent uses RPC protocol. It doesn't just use a typical REST API. It uses RPC and JSON JSON Uh yeah, like a JSON RPC request. Um and then we're just yeah, we we we're just posting that JSON RPC request to our endpoint. And then we can see over here we're just sort of passing the logic.
Let's see it in action. Let's actually take a look at what this sort of all looks like pieced together. So, in each of these uh endpoints, each of these servers I'm sort of running So, I'll I'll go I'll go over it again. Um but I've sort of I have got my facilitator, so I'm going to run pnpm dev to spin up my facilitator. And obviously I've got some environment variables configured.
If you go through the replay, you'll be able to see that uh yourself. Um I'm going to spin up the server, the the server which has the agent-to-agent endpoint. And just quickly, what actually is this agent doing? So, if we take a look at our agent, we can see that like in the first example, we've got this agent executor. We've got this execute function.
But this time we're actually doing something a bit more meaningful than just responding with some hardcoded text. We're actually invoking an AI agent that we have. Uh so this AI agent, very straightforward. I mean, it's technically not even an agent, it's just an LLM. It randomly picks a stock from the Nasdaq exchange and then gives a summary on the company.
So, it's very straightforward. Uh we are taking the user's request, the text that the user sends, the client sends, and then we are generating the response. Uh and that's what then we're responding back. So, this is what's going to cost 1/10 of a cent. Uh and then on the client side, what we're actually sending is we're sending the this question or this this uh prompt, "Tell me about stock."
Uh so, if we We've got the facilitator running, we've got the server running. Now I just need to do a test of running this script at pnpm dev as well. And we'll see that the we get a request we get a response from the agent saying, "Agent message, uh sure, let me randomly select a stock from the Nasdaq exchange, DocuSign." Giving me some information about that. And we can see that actually it's also uh the transaction's also been executed successfully.
So, if we go over to our If we go over to our um There it is. If we go over to our hash scan, we can see this transaction ID, and we've sent 1/10 of a cent to the uh Oh, there we go. Yeah, 1/10 1/10 of a cent USDC to this recipient account, which was specified as the pay to account. So, it's pretty cool. It's pretty cool.
Basically, what we've done is yeah, we we've set up an AI agent, which is able to receive a payment using the A2A protocol, uh and a client, which also could be an AI agent, is able to pay pay it. And this is really powerful. Um but you might be thinking, "What about the trust?" Uh which is sort of what we were alluding to earlier. If these agents are autonomous, obviously this is a very controlled environment where I've got the agent A2A server.
I I know that it's uh I I I know that it's safe to use because I built it. I'm also the client. But what if we're in this futuristic world, which probably isn't too far away, where AI agents are have got a lot of freedom, a lot of free reign, a lot of control. They can discover other AI agents. There's the the they've got the ability to connect.
Uh I've got an AI agent, which is working on my behalf, and it knows everything that I sort of need to do day-to-day. Maybe it's a business agent. It knows exactly when my meetings are. It knows exactly um who I need to speak to. Maybe it starts doing some research on this client.
Maybe it goes to this data broker, where the my AI agent goes to this data broker agent, which knows which sells data about other people, just like sort of what Facebook and that do. Uh I'm I'm totally spitballing here as well. This is a not really thought of this use case before. But my AI agent needs to be able to know that if it pays this AI agent to tell me about the business opportunity or the the this talk which I'm going to. Um my AI agent needs to know how to that it can trust and that actually this AI agent which it's dealing with is going to provide value.
And that's where
[clears throat]
that's where ERC 8004 comes in. So, ERC 8004 at its sort of most fundamental uh at at its sort of most fundamental thing it's just a set of smart contracts. Now, I'm going to quickly find this um give me I need to going to dig around quickly for this uh um article. Uh do do do do let me find a very good article which I should have pulled up before. Um Hopefully I can find There we go.
I've got it. So, here's a really uh brilliant um Okay. There we go. So, this is a really great article which sort of gives high-level overview of ERC 8004 what it actually is. And as it says over here it's a standard that defines a framework for autonomous agents to identify each other, to find, evaluate, and interact with each other trustlessly.
So, it's got these three registries, this identity registry, this reputation registry, and this validation registry. And each of these is the composable primitives which a developer is able to then build on top of um to actually create applications that enable agents to trust each other. So, the identity, as I sort of briefly mentioned earlier, uh the identity gives the agent an ID. It's actually an NFT. And with it, it's got this schema which can point towards maybe your agent to agent card if you've got an agent to agent uh agent.
Um and then it also has this reputation registry. So, essentially, we're going to get into this. I'm going to do a quick demo of it. But, you can then map reputation onto your AI agent onto the identity so that when I go to use this data broker agent, for example, I can actually look my agent can actually look at all of the reputation, all of the feedback that's been given to then decide whether it wants to trust it. And then finally, you've got this validation registry.
Now, this isn't always uh required. Um but, this is essentially I I I like to think of it a bit like the reputation for the reputation. It's just making sure that this reputation which is given to the particular AI agent isn't totally botched. It's not a It's not a botched job. It's not fake.
And the validation actually goes, "Okay, is the reputation does the reputation feedback actually cover any carry any weight?" Um I've not really looked into validation too much, but it's definitely important because it's very easy to just uh totally falsify the reputation uh registry. But, as it says over here, the sort of entire uh the the entire framework is very unopinionated. It's It's just gives you the primitives to build on top. Um but, let's have a quick look at actually what it looks like.
Again, we've got snippets inside of this code repo. So, if you go over to this time, if you go to the 82A, no, sorry, the ERC8004JS folder and you go in here, uh you can see that we've got this Hedera test script. Test Hedera. Uh obviously I've installed everything, I've built everything. Uh but essentially this test Hedera script, it goes through those steps of registering an agent and then uh giving it feedback.
So, we can sort of see it bit by bit. We'll also run the scripts. Let Let's maybe run the script first and then we can go through it sort of one by one. So, I'm inside of that repo and I'm just running PNPM test. That's triggering this uh script to run.
So, we've got an agent owner, which is going to be registering the AI agent, uh which is actually the AI agent that we just created. So, we can see, for example, uh over here, we're just setting up our EVM addresses. We are registering our ERC8004 client. We're specifying the registry's Hedera. We already have our own deployed registries.
You can find this on the uh you can find that on the ERC8004 smart contracts on GitHub. But we're using this ERC8004 client. This comes with a lot of methods that we can use to interact with the registries. We are first of all registering the agent. So, what this is doing, uh we can have a look at the transaction hash.
What this is doing is it's going to be invoking the uh it's going to be calling the identity registry. Oh, surprise. Uh Uh, where do I Let's put this over here. So, this is going to be invoking our identity registry over here. Uh, and it's just essentially minting an NFT.
That That's all it is. And the owner is the one who actually registers it. So, the the account which I've set up this client where where it has the sign up, that's going to be the owner. Now, we can then get the agent ID in that response. And then what we can do is we can actually set the metadata of our AI agent.
So, after creating it, we then get this agent ID. And with that, we can generate the metadata over here, which is a uh, it it's a standardized schema. And you'll see that we pass in the endpoints. So, we've got the name, we've got the description. Uh, we've got the endpoints.
It's an A2A endpoint, and this just points towards our This just points towards our agent which we've set up. Uh, so if we go over to our server, you can see that we have this agent card, which is what we deployed earlier on. That's what lives inside of the XPRL 2 Hedera repo. Uh, and it's specifying all of the trust mechanisms. In our case, it's just reputation, but you can also have further trust mechanisms which relate to the validation part.
Um, and importantly, inside of this registrations array, we then point back to the agent ID on our identity registry. This is really important because this makes sure that the agent uh, is that's registered on the smart contract is actually the right agent. It's not like someone's just randomly registered an agent which doesn't belong to them. This actually proves that okay, this agent does belong to me. Now, that's then essentially added to the metadata of this agent ID.
That metadata, it can be a hosted on a web server, it can be hosted on IPFS. You can really do whatever you want there. Uh there's sort of no no uh must do's, but we're setting the metadata. Uh and then yeah. Once we set the metadata, uh we're then testing around the feedback.
So, I'm going to sort of explain the feedback now going over to our agent uh example which we had over here. Where essentially what happens with the feedback is when an AI agent or when a client interacts with a server, so now in our case it was over here, we had this um we had this script which was acting as the client and it was interacting with this agent-to-agent server. When that initially happens, what should take place is the AI agent which is on the server, the AI agent on the server should authorize the feedback to be given. So, they're going to call this uh create feedback off method, which essentially goes I'm going to let you, the client who's just spoken to me, I'm going to give you the ability to leave feedback on my reputation registry. And you can see that it specifies the feedback giver.
So, uh it's not just anyone who can give the feedback, it's only the person who's sent the request. So, user will send the the client will send the request saying I want to uh pay 5 USDC to to to get your endpoint, to get your business logic. And then the server AI agent will go, "Okay, I'm going to now give you authorization to actually leave feedback on my registry." And then with that, they'll sign it just again to make sure that it's actually been authorized by them. And then the feedback clients uh the client which is going to give feedback is able to actually give feedback using that feedback signed authorization uh token, essentially.
So, that feedback is is a score of uh 0 to 100, and you can also give a feedback URI. So, this is quite interesting, this feedback URI. It basically allows you to enrich the data that gets given to the AI agent for the on their feedback registry. Um and the ERC-8004 docs over here, it talks about using IPFS. Uh so, here it says you can use um We've got this feedback.
So, give feedback um which accepts a file URI points to an off-chain JSON containing additional information and its uh hash to guarantee integrity. Now, obviously, if you're just taking feedback and you're just chucking it and then that feedback lives on a web server which can be which can be changed, you're going to want to obviously hash it so that uh on the smart contract it has the hash so you can see if someone ever changes it, well, actually, that's been changed because the smart contract has the hash. The hash is now different. Someone's obviously altered and tampered with it. Uh but, the docs over here, the EIP, also mentions that you can use IPFS.
And in which case, IPFS is deterministic, you can't change it. Um and in that case you don't need to use the use the hash. Now, IPFS still has its own problems cuz you need to pin it on IPFS and there's a chance that it gets lost. So, actually with this example, there's an interesting implementation which uses HCS, the Hedera Consensus Service, which is on chain and allows you to put the reputation on chain as well. So, I think that's a quite nice little nice to have um and definitely a great use case for the Hedera Consensus Service where you can have this uh on chain immutable thing that will never get lost.
Uh and you can use that for the feedback. But, that's essentially and then you can obviously read the feedback. The feedback will get indexed so you can sort of look at it and and then use it as part of your discovery process. But, that's sort of a quick summary in terms of how the ERC-8004 ties in and I think you'll be able to understand why exactly is it important or yeah, if you're going to be having AI agents that are um AI agents which are interacting with each other, they need to have a safe way to to trust each other essentially. But, that's it for me.
I've gone for a bit. I'm going to go back over here. So, I think final sort of call to action, uh join the Discord. Um really yeah, we're going to be really active in in sort of helping out the Discord. We'd love to see how you are using agent-to-agent XPRL 2 ERC-8004 to build some of the most disruptive uh some of the most disruptive sort of applications that are going to be going to be around.
Uh it's really quite an exciting time and and all of these pieces are coming together and and merging very well. So, without further ado, have a great day, everyone. Take care.
Automatic transcript — names and jargon may be misspelled.