# ERC-8001: Verifiable Intents for AI Agents | Kwame Bryan ERC 8001 - Channel: [Ethereum Denver](https://streameth.org/ethereum-denver) - Date: 2026-03-09 - Duration: 19:24 - Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum - Watch: https://streameth.org/watch/yt-aGIDGeBIqik - YouTube: https://www.youtube.com/watch?v=aGIDGeBIqik ## Description πŸš€ Get Ready for ETHDenver 2026! πŸš€ We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2026β€”it’s going to be epic! 🌟 ## Transcript All right, after learning a lot about how blockchain agents can work in agentic commerce, now it's time that we shift gears a little bit towards verifiability, especially when it comes to AI agents and intents. Today we have with uswami Brian who will be presenting ERC8001. The cool thing is that he himself is the author of it. So if you have any questions related to this particular ERC, keep your questions ready for the end and we'll obviously bring them up on stage.wami, are you ready? >> Over to you. >> There you go. >> Thank you. >> Hello. Uh my name iswami. I am an independent EIP author. I wrote ERC 8001. Um it became a standard ERC in December of last year. And um I'm hoping to just uh give you guys an introduction to what we're trying to do. So basically if you kind of look at it like everything needs coordination and ERC 8001 is built to uh standardize how agents protocols coordinate on chain and if you kind of look at it at the broad scope of how the agentic commerce works you would have 8001 for coordination um 8004 would uh handle like identity registry and then you'd have x42 for payment So every transaction that we've ever done has required some kind of coordination. If we look at you know desk swaps, lending, yield farming, uh voting on a DAO, uh game movement, my background is in blockchain games, um task for agents, bridges or multi- signature. there's all some kind of coordination and somewhere somehow either on a back end or some man-in-the-middle someone had to sequence someone had to verify and settle uh one of these in one of these steps. So what is the current like coordination framework look like right now? Well, basically it's ad hoc, it's fragmented, and we have to put a lot of trust assumptions into it. And the further we go with u agented commerce, humans are going to be outside of this loop. We're not going to be in the like in the in the middle. Agents are going to be coordinating on their own. They're going to be signing their own transactions. They're going to be managing their own wallets, and they're going to be managing their own tasks. So, every protocol has coordination. This is nothing new. Um, but if you wanted to do something with unis swap, a compound, each has their own bespoke way of handling coordination logic and none none of it composes. So if I was an AI agent and I wanted to do things between a compound or morpho or something like that, there is no standardized way for for that it to do it and different agents wouldn't be able to coordinate together in order to uh do some of these um agent commerce tasks. If we want to look at a multi-party um a trusted intermediary, say we have three agents that need to act together. Um now we have to add in a trust assumption like a relayer or some kind of centralized service to broker this idea. On the uh third part, we have no standard uh proof of agreement. So if two agents uh agree to coordinate there's no onchain proof and if there is a dispute um they're not resolvable. So if we look at 8004 on its own what if these agents don't agree? What if there is something that that goes wrong? There's no way to dispute this. It's basically the funds are transferred from one agent to the next and there's no way there's no recourse from that. Now this whole idea of 8001 and the coordination framework is based on intents and there are um standards like 7521 and 7683 and these were great for single initiator flows but in the world of agent commerce we have multiple agents that are working that agree that coordinate and multi-party um coordination was the main reason why we designed the standard. Um, taking it back a little bit, uh, we do a lot of blockchain games and we have these agentic NPCs that were, you know, programmed to know their environment. They were programmed to know the distance between a player and the agent itself and to be able to change their state. But once we um started adding giving them their wallets and working with things like 6551 and a lot of our games and they had their own ways of being able to do different things. We came to this whole idea of well they can do this on their own but what if they want to communicate with a player or on a grander scheme? What if agents or NPCs wanted to coordinate on their own or to, you know, do a swarm or um sell items or to maybe help a game player out? Like, how do you solve those types of problems? And 8001 was was our idea of doing it. So we're very grateful to the standards that had done the single initiator flows because if it wasn't for these particular standards um we wouldn't have been able to build upon it and do 8001. So where does coordination break down? Well, anywhere where you want to coordinate uh something, say in a yield strategy, you have three agents that want to rebalance between a morpho and comp um simultaneously. Currently, right now, what happens is that an agent would basically broadcast this out and then we would hope that these other agents kind of follow suit. We have no idea if they do. Most of the times they don't unless you have some kind of intermediary that is you know handholding a lot of this stuff. So currently within the blockchain space we have a lot of trust assumptions and we are handing off a lot of trust to uh servers that are holding private keys to do these middle grounds. Now in the agent commerce world if a server broke down that's holding this EOA this whole flow would basically end and these onchain transactions wouldn't exist. Um proc cross protocol liquidation here we have liquidator the oracle settlement agent must act in lock step. Uh today we have custom off-chain messages um which is kind of the standard right now. We have race conditions that basically uh come up and then we have MEV at every step. Uh billions of dollars are be currently being lost to MEV. Now I'll be totally honest and upfront. ERC80001 does not solve MEV. We don't claim to. What we do is mitigate it because 8001 has a a base coordination layer and then the standard itself has um adapters. is based on modules. So you can add a private privacy module that would help with MEV. You can add all different types of modules to handle anything that you want. So if you look at the the standard which is final at this point, it it goes over that. Dell multisig. Now I do love Nosis. No, we I use Nosis. We all everyone here uses Nosis, but it's a single initiator flow. What if you wanted to add um extensions on top of how Nosis does things? You currently can't do that. By integrating 8001 that gives you this ability. So instead of thinking of a world currently in Ethereum where we are just talking about transactions, we are now thinking of a new programming paradigm within Ethereum where transactions are driven by intent and not by an actual transaction um construction itself. Uh gaming which is our background um you have four players that commit moves in a turn-based game. Today the game server basically decides this the order and players trust the server and if you look at the history of Ethereum um the reason why Vitalic came up with Ethereum itself was with you know a woow um you know World of Warcraft and having losing his um you know assets. So taking into account ERC 8001 basically solves this as well. So the reason of this talk ERC 8001 it's named the agent coordination framework. Now when we started thinking about what an agent was everyone here that communicates or interacts with a web 3 wallet is an agent. The difference between an AI agent and an agent like ourselves is that an AI agent is p has its intelligence through like an LLM, but anybody who interacts with the blockchain is an actual agent. And that's a very important thing to uh to remind ourselves because as we get into this agentic forwardthinking world, humans and agents are going to be working, transacting, and communicating and coordinating all together. So there's not going to be a real um differentiation between something that is power an um an agent that is powered by an LLM and an agent that is powered by good old human creativity and imagination. So how is this basically broken down? At its core, it's it's minimal. It's a single chain primitive with multi-party coordination. An initiator proposes an intent. So if you think of an intent like um you we're here at ETH Denver, you meet up with someone that has a great idea. You guys want to talk about business. The coordination is hey let's meet after this talk at this booth in 30 minutes. That's the intent. Um the proposer initiates this intent and then there may be a group of um agents or people um that agree to this. they all sign their asitistation. So the the first uh intent is an assetation that's signed by the initiator. All those the parties that want to agree sign their version. So of that agreement and after that all the um uh people who are coordinating have signed then that is being ready and then it can be basically executed. So for the type data we use EIP712. Everybody is familiar with that. When you sign a transaction and you actually see exactly what you are signing that is EIP712. We use smart wallets because agents work really well with smart wallets. And you know it's not uh uh to take away from anything else but we all know that there's an EOA somewhere when we're dealing with this stuff. Um we have monotonic nonses which just means that there's always a unique non so for protecting against replay and things like that. It's modular by design. So you can add any other type of primitive um trust registry which we uh are currently using 8004 for registry but say you wanted to do trust or you wanted to do privacy modules you can extend and add that as an extension on top of ERC8001. So we designed the whole core of E80001 being forward thinking because we just don't know what's going to happen in the future. But we do know that there's going to be a base component that is never going to change. And it it's MEV resistant. It doesn't stop MEV whatsoever. And um Mev there is good parts to MEV um which I there might be some backlash to that but it keeps the blockchain honest and it keeps the developers who are doing things honest as well. So there's three main components to how ERC 8001 there's the propose as I talked about earlier. You propose the intent that is kind of like the agreement. The acceptance part is where all the agents either powered by LLMs or by humans themselves accept this and after everyone has signed their portion of this agreement it becomes executable and then it can be executed. There's uh four main kind of components or stages of it. There is none, there is a proposed ready and then executed. So the standard itself is really really simple and is meant to be really really simple. There should not be you know a huge amount of compre complication to coordinate um you know operations on chain. So here's the three primitives but it's one standard. We have the agent intent as we mentioned before an initiator signs the type data intent speci specifying the coordination type. This could be, you know, going out for lunch or um the actual um agreement or contract itself. The participants are sorted um uniquely. There is the expiry or how long this intent should last for and then an opaque payload hash. And then you have like you know some of the properties that are a part of this and we have another slide that shows this as well. So you have the payload hash, the expiry, the nons, the agent ID, which if you're familiar with H004, um that's kind of like tied into it. Uh the coordination type and then the participants. Then we have the acceptance assistation. So each participant signs their own version of this. So you have the um initiator who says this is what we are planning to do. And then each of the participants sign their version of this agreement. there and it references the that intent and when all accept accept it the intent is ready for execution and then there's the intent hash the participant the nonsex expiry the condition hash and then of course the signature and then we have the coordination payload this is the actual coordination data itself it's opaque to the core and at execution the payload must hash to the payload hash and your defy strategy your game move or agent in task lives here or however you want to basically define it. So you have like the version, the coordination type, the coordination data, the coordination hash and additional metadata if you want to have that associated with it. Okay, so this is the hello world version of how ERC8001 works. It's very very simple. the interface. You have the proposed intent. You have your uh coordination payload and the signature. We have the uh accept intent which has the intent hash and the call data. And then we have the function for the execute coordination which has an intent hash, the coordination um uh data and then some call data as well if you want to have that um associated with it. The second part here is the actual the u coordination payload. The first part is the coordination type which is really defines what we are coordinating. We have the participants who must agree. We have you know Alice and Bob here but this could be you know a group of people. Um we have the coordination data here. We just have hello world but this could be a game move. This could be a DeFi strategy. This could be basically whatever you want it to be. We have the unique naunt which is going to be incremented to uh prevent replay and then we have the deadline which is the expiry. So in step one we have Alice proposes we have the coordination type which is the greeting type. We have our participants which are Alice and Bob. We AI encode hello world. The nons here is one. And then we have the um the block timestamp. And then we have our proposed intent with the payload and Alice's signature. Now me as Bob, I'm the one who's um agreeing to this or wanting to interact with it. I accept this intent and I sign my version of that. This is now proposed to ready. All participants have signed and then at this point anybody can execute. And then we have the result here which is the get greeting and it would be hello world from Alice and Bob their addresses. So the key insight here is that each um parties cryptographically agreed before executing either both signatures are valid to execute or nothing happens. There's no trusted intermediary needed. We don't need a server. We don't need any other outside things because the intent is the agreement. That is what we're signing. And if we agree to that, then we can execute this transaction. So if you want to take it a bit further, you can kind of look at it as um like a atomic swap would be um advanced part of the hello world here. And a complete audit trail is here and who agreed to what and what they agreed to. So, uh, we came up with 8001 and it was an agent coordination framework and we were really stoked about the work that the team at 8004 has, um, worked on because it kind of added the extended layer that our small team wouldn't be able to do. So here we have the discovery agent a reputation with 8004 propose the coordination with 8001. The participants accept with 8001. We execute with either 8001 or 4337. Settle the payment with X42 and then post feedback back with um X um ERC 8004. So everything needs coordination. Now there's a standard. We have 8001 on Ethereum um SIP uh 037 as a coordination standard on stacks. We have our SDK um that you can get uh just from mpm. Our smart contracts are available on our GitHub. It has an atomic swap. It also has a bounded execution example as well. And we're currently working with the ENS team to do the um ERC 8107 with is the ENS trust registry. Get involved on Ethereum magicians is still in the early stages. And my name isWami. This is a ERC8001. And thank you for ETH Denver for allowing us to be here. That's it. Thank you.