iTranslated by AI
re:Invent 2025: Convergence of Web3 and AI - Autonomous Payment Systems with Stablecoins and AI Agents
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden, high-quality information more accessible. The presentation featured in this project, which operates under that concept, is as follows!
For transcription articles from re:Invent 2025, please check the information compiled in this Spreadsheet. Please take a look.
📖 re:Invent 2025: AWS re:Invent 2025 - Web3 + AI: Agents that mean business (DAT318)
In this video, AWS Senior Solutions Architects Arvind and Joshua Smith, along with Eric Rappel, Head of Engineering at the Coinbase Development Platform, explain Web3 and digital asset payments, specifically agentic payments. Starting with the basic concepts of Web3, the video introduces AWS Blockchain Node Runners and the AWS Public Blockchain Data program, which provide support for blockchain node operations. Eric explains the open-source payment protocol x402, which leverages stablecoins, and details how it realizes internet-native payments using the HTTP 402 status code. x402 currently processes 70 million transactions, enabling micro-payments with an average transaction value of about 80 cents. Joshua demonstrates how to implement an architecture where AI agents autonomously perform payments by utilizing Amazon Bedrock's Agent Core Runtime and Agent Core Gateway in combination with Nitro Enclaves and Coinbase's AgentKit.
- Note: This article was automatically generated while maintaining the content of the original lecture as much as possible. Please be aware that there may be typos, omissions, or incorrect information.
Main Content
Opening Day 5 of re:Invent: An Invitation to Web3 and Agentic Payments
Good morning. Welcome to day 5 of re:Invent. First, I would like to thank you for choosing to spend your Friday morning with us. You are truly passionate individuals. There is no other explanation for why someone would want to hear about Web3, payment protocols, digital assets, and agentic payments on a Friday morning. I'm not sure if I would have made it here myself, but I applaud your curiosity.
In addition to my gratitude, I am very excited today. This is because our customer, Coinbase, is joining us to share their initiatives regarding agentic payments on AWS. Before we begin, I would like to understand a little bit about the composition of the audience here. I walked around and talked to a few of you, and it seemed like some have a background in Web3, while others do not. Understanding the composition of the audience helps me know how much time to dedicate to that.
Could I ask for a show of hands? How many of you are actively developing in Web3? I see, very few. I will take some time to provide an overview of Web3 and digital assets so that you can better understand the topics that follow. Now, my name is Arvind. I will be co-presenting this session with Joshua Smith, a Senior Solutions Architect at AWS, and Eric Rappel, Head of Engineering for the Coinbase Development Platform.
So, what are we going to talk about today? As promised, I will start by providing an overview of Web3. I'd like to take a little more time than initially planned to build a foundation for everyone regarding what Web3 is, how AWS views it, our perspective on Web3, what kind of workloads exist, how we address the requirements of these workloads, and our future plans.
From there, we will move on to what digital assets can do for payments and why that matters. Afterwards, Eric will take the stage to talk about x402, an open-source payment protocol. And then, Josh will talk about how to implement agentic payments on AWS by leveraging the x402 protocol that Eric discussed and the foundational capabilities of AWS. Does that sound good? That is what you can expect from this session. This is a level 300 session, so in addition to the overview I will provide for the curious, I will also dive a bit deeper into code and implementation.
AWS Perspective on Web3: A World of Decentralization Beyond Cryptocurrency
Now, regarding Web3, what does Web3 at AWS look like? What is our perspective? When I say Web3, how many of you immediately think of cryptocurrency? More hands went up this time, right? There is good reason for that. Cryptocurrency has probably been the most popular use case for Web3 over the past decade. Therefore, when people say blockchain or Web3, they immediately think of cryptocurrency.
What I want to convey here is that our view of Web3 goes far beyond cryptocurrency. There are many other use cases that leverage the same basic principles that support Web3. Cryptocurrency is just one of them. There are numerous decentralized applications that utilize the various technologies we will touch upon today.
Web3 was born in response to perceived shortcomings in current internet infrastructure, and its core philosophy is decentralization. To operate Web3 workloads, you need to combine various decentralized technologies: blockchain networks, decentralized storage networks, virtual machines for smart contract execution, and more. When thinking about actual use cases or workloads, such as enabling digital assets, it is common to combine many of these decentralized technologies to operate a single workload.
That is how everything actually comes together, and when doing so, you have many choices to make. And we at AWS are here to provide the prescriptive guidance needed to build and scale these workloads. When you think about building Web3 products, using decentralized technology is not the goal; it is merely a means to an end. Ultimately, what you are looking for is to build a product.
Therefore, in many respects, it is our responsibility to provide the right building blocks so that you can utilize these technologies to build the products you need. We are in the business of providing these primitives, these building blocks, which allow you to build Web3 products. We are not building Web3 products for you; you are. What we do is provide all these foundational technologies and primitives, allowing you to operate these workloads.
However, as you build Web3 products by leveraging all these decentralized technologies, it very often looks like the winding curve shown on the screen. This is because you have to make many choices, and there are many components you should leverage to bring a single solution together. The most fundamental choice is, first, choosing the right foundation for building the product. Do you use a public chain, or do you use a permissioned chain? Do you use a combination of both? Which public protocol do you choose? Do you choose multiple different protocols? And if you do, do you need to build interoperability?
Now, if we are talking about assets, are you providing a custodial solution, or are you providing a non-custodial solution? How do you handle smart contract execution? What standards do you use there? These are all topics you may or may not be familiar with, and there are so many different choices you have to make. Once you move past these foundational core components, you then have to make other choices.
How do you handle blockchain data? How do you conduct analytics? There is on-chain data, and there is off-chain data. How do you bring it all together to make the choices required for building your product? How do you build your wallet? Do you build it yourself, or do you purchase it? And of course, if you are in the digital asset business, do you become an issuer? Do you handle it yourself, or do you leverage someone else to do it so you can focus on building the necessary product and offload the heavy lifting? These are very big choices because they determine how your business will move forward from there.
AWS's Approach to Web3: Managed Services, DIY Tools, and Partner Ecosystem
And that's where we come in. Through the approach we've taken toward Web3, we are doing our best to turn the winding curve you saw earlier into the straight line shown on the screen. And we achieve that through three fundamental pillars: managed services, DIY Web3 solutions, and a very robust partner ecosystem built around Web3. Let's start with managed services.
If you want to build your own product on AWS, you can leverage all the primitives and building blocks we currently have to make your solution operational. If you choose, you can do everything yourself. It requires a lot of work, but it is feasible. We will help you build by leveraging some of our core infrastructure products.
So, from an infrastructure perspective, let's focus a bit on EC2. There are also Lambda and other logos over there, but I'll talk a bit about EC2 here. One of the core principles I mentioned earlier is decentralization. Decentralization does not mean you shouldn't run on the cloud. It means decentralizing authority and decision-making. Now, when you think about running blockchain nodes on the cloud, AWS provides certain guarantees by default. That is, AWS operators have no access to customer content on Nitro-based instances running on AWS.
So, take a step back and think about one of the biggest factors that probably sparked your thoughts on decentralization. It's about data access and ownership. And with AWS, when you spin up and run EC2 instances, there is no mechanism by default for AWS operators to access your content. In other words, your content remains protected. This can be said to be one of the best reasons to run blockchain nodes on AWS.
There are also other components related to storage and security. I'll touch on security for a moment now. If you are building custodial solutions, I highly recommend considering the specialized features we have built specifically to accommodate these Web3 custodial solutions. AWS Nitro Enclaves are the foundational components of confidential computing in these wallet solutions.
When building a wallet solution, if you are using enclaves, you are likely using a keystore to import keys, decrypting them within the enclave, and managing those keys to sign transactions. AWS KMS and AWS CloudHSM are products that enable this. I can take questions about this after the session, or we can dive deeper into what it looks like on AWS. I am just introducing some of the components and products you should consider when you start thinking about these specific solutions.
In addition to managed services, we also offer DIY-style solutions. These are not intended for production environments, but they are helpful for getting started right away. We are building something called AWS Blockchain Node Runners, which is an open-source project. Node Runners has blueprints for several popular protocols, helping you launch your own blockchain nodes on AWS. So, if you want to self-manage your nodes and are not using a provider, you can use Amazon EC2 directly to launch blockchain nodes on AWS, and Node Runners will assist you. We provide the blueprints, and we continue to add popular protocols to Node Runners. If there is a protocol you are interested in and you don't see it in our repository, please talk to me, send me a note, and I will add it.
Another solution is related to blockchain wallets. We have been working on blockchain wallets for four to five years, so we have built up a lot of knowledge and expertise. And we share all of it. We have workshops and blogs on blockchain wallets, and we also provide prescriptive guidance and architectural guidance on how to build wallets on AWS.
Another major program we are running for Web3 is AWS Public Blockchain Data. We provide blockchain datasets for free. We select the top blockchain protocols that our customers are asking for or are interested in. We monitor activity to see which protocols we need to continue adding, and we add datasets for free. We have achieved this over the years through partners. As we head into 2026, we are making slight changes to our approach. We will work directly with foundations to provide datasets from them. This means you will no longer have to rely on partner products. It will be provided for free and will be available through the AWS Public Blockchain Data program.
Now, let's take a quick look at these Node Runners. For those of you who want to see these blueprints, there is a QR code here. We have added support for about 14 to 15 protocols, and we will continue adding more next year. We will also monitor how many Layer 2s are emerging. We will continue adding here based on where there is activity and demand. This is an open-source project, so we would love for you to contribute as well.
We currently provide support for all these chains shown on the screen in Public Blockchain Data. Some are available more natively, and some are provided through partners. We also highly recommend checking out partner solutions. Because if you aren't building your own data analytics solution, our partners offer datasets for free, and they have fantastic products that allow you to leverage this data and start mining it immediately. So, for those of you who aren't familiar with how to handle or work with on-chain data—and I know there are some of you in the audience—they have already solved that problem. We highly recommend you check out some of the partner solutions. The latest dataset we recently added is from Cronos. We are seeing increasing demand for more chains, so please look forward to even more datasets being added throughout next year. And here is that QR code.
So, let's talk about partner solutions. Whatever you are looking for—blockchain infrastructure solutions, wallet and custody solutions, data and analytics solutions, etc.—these are all foundational building blocks. There are many more. You can open up the blueprints and take a look. There are many more, but these are very foundational. For each of these, we have multiple partners vetted and certified by AWS offering solutions, allowing you to launch decentralized applications very quickly, as they handle all the underlying base layers. All you need to do is focus on the application you want to build for decentralized technology.
The Importance of Digital Asset Payments: Solving Challenges in Traditional Payments
Now, let's briefly look at the key use cases in Web3. I have listed a few here, but this is by no means an exhaustive list. I'm just listing them as areas where we are currently seeing the most active movement. Tokenization, trading, payments, and wallets. Since we will be combining tokenization and payments today, I won't spend too much time here. However, I want to leave you with this thought about Web3: one of the biggest trends emerging right now is digital assets, the tokenization of securities, and even the tokenization of currencies, with a focus on stablecoins.
However, all of this is meaningless without downstream use cases to actually leverage what is being offered. And that is where payments really become important. In other words, think of one as an enabler and the other as the actual utility that will become more mainstream moving forward.
This is a closer look at what a tokenization solution looks like. Don't worry, I don't intend to explain this solution one by one. The point I want you to focus on here is that if you look at an end-to-end tokenization solution and break it down into components, it is immediately clear that at AWS, we have all the products and features that correspond to each of these components. And I can easily map these components to show how partners get involved here, who can provide the tokenization engine, who can provide the wallet, and who can provide the custody solution. So, the high-level idea I want you to take away is that not only can we help you launch your own solution if you wish, but we can also help you get started with partners just as well. That is, think of this as a blueprint that you can map to AWS or map to partners, depending on your intent to build or buy.
Now, let's look at the Web3 trends shaping our ecosystem. I've listed a few different items here, but I really want you to focus on two. This is what we will focus on today. There is growing adoption by many institutions and governments, which is leading to regulatory clarity. So, for those of you familiar with the GENIUS Act or Clarity itself, you know that stablecoins are becoming more accepted as digital assets that can be leveraged for multiple different use cases, and we are seeing more informed language coming from the government as well. So, we're hearing a lot from customers, but as I mentioned, issuing stablecoins is one thing, but actually using them is what's important. That's really what brings it all together for everyone, and that's where payments come in. Stablecoins and payments—we view these together as one trend, and today Eric and Josh will talk about what you can do with digital assets and how you can build payment solutions. And the next question arises: Why is this important? We already have currencies. We already have payment solutions. Why is all this important?
The importance lies in the fact that existing traditional payment solutions, current payment solutions, have challenges. Processing fees are very high. There are long delays in settlement. There is currency volatility that must be dealt with. There are complex cross-border transactions that occur when trying to move money from one country to another. And finally, there are many intermediaries. Let's take a step back and look at it from the other side. When processing fees are really high, it's very difficult to make small transactions. Digital asset payments actually reduce costs because they require less infrastructure, have lower fraud management costs, and have automated compliance. All of these actually reduce costs and bring significant benefits. That is micropayments. It enables smaller payments. You can perform more transactions.
Back to settlement delays. For example, if you want to transact on a Monday, you need to make sure you transfer the money on the Thursday of the previous week to ensure it's ready to use. If you're a small business and have to deal with delays in three or four transactions, it really affects your cash flow. Digital assets settle in minutes, improving cash flow and response times. The same goes for currency volatility. I don't think I need to explain this in detail. If you are waiting for a payment to settle while dealing with currency volatility, you could lose one or two percentage points if the exchange rate fluctuates.
And intermediaries. If you can eliminate or even reduce intermediaries, it's not just faster and cheaper, but more importantly, you can reduce counterparty risk. So, there are many benefits that push for digital asset payments to become more mainstream. One last thing I want to mention is that this can bring banking services to the unbanked. Today, there are over 1.2 billion people in the world who do not have access to the actual banking system. This brings banking services to them. This brings peer-to-peer transactions. This brings them so much more that they can do.
Coinbase Developer Platform and the Potential of Stablecoins
Now, I'll invite Eric up to talk to us about the x402 payment protocol and how it enables digital asset payments. Thank you for listening. Thanks, Ivan. I'm really excited to be here. This is my first time speaking at a silent disco, so if you're in the audience and can't hear me well, please try the headphones.
I'm Eric. I lead engineering for the Coinbase Developer Platform. CDP is to Coinbase what AWS is to Amazon, so to speak. That's what CDP is for Coinbase. Amazon took all its expertise in building cloud infrastructure and made it available for millions of businesses to use. CDP has done the same for Coinbase's infrastructure: asset custody, payment infrastructure, blockchain infrastructure, wallets, orchestration, trading, and so on.
There are many things we do shown on the slide, and there are many more not shown here. If you want to talk about payments, stablecoins, or trading as a service, please talk to me afterwards. But we also have great wallets. We also have excellent access to data products. We have nodes, staking, and on-ramping/off-ramping to the crypto ecosystem. But I didn't come here today just to talk about CDP. I came here to talk about agent payments and a project we've been working on called x402.
At Coinbase, we believe broadly that stablecoins are an extremely compelling technological solution for AI. I'd like to ask for a show of hands: how many of you in the audience know what a stablecoin is? Probably about 70%, I'd guess. To get everyone on the same page, a stablecoin is a token that exists on a blockchain and is pegged 1-to-1 to some kind of fiat asset. The one most of you in this audience have likely heard of is USDC. USDC is a stablecoin launched through a partnership between Circle and Coinbase. It is backed 1-to-1 by a combination of US Treasury bonds and bank account dollars, and is fully audited.
Circle and Coinbase are both public companies now. Literally, you can check the serial numbers of all the Treasuries backing USDC and know for certain that it is backed 1-to-1. That means if you hold 1 USDC, you can withdraw 1 dollar into a bank account. Why are stablecoins so good for agents? Well, there are several factors I will explain, such as transaction costs and speed of settlement. But there is a more fundamental problem we face when working on payments. That is, there is no open standard for payments. Let's define it.
The Necessity of Internet-Native Payments: Background of the x402 Protocol
The internet has existed for nearly 35 years, yet there is no standard for payments. If you want me to really, really dive deep into this point, I gave a talk on Wednesday in the FSI track where I basically broke down what standards are and why they are important, so I highly recommend checking out that recording. However, let me define how I think about internet-native payments. I define internet-native payments as a way for computers to programmatically exchange payments, in a standard and neutral way, within the existing client-server paradigm upon which the internet is built, and without requiring a human to be in the loop.
So what do I mean by standard and neutral? It means that every interaction between a client and a server should be the same. We don't download a different browser for every website we visit. The internet works because the browser Google publishes can access a website Amazon publishes, and there is an agreed-upon standard way to send that data. Those standards are HTML, CSS, and JavaScript for interaction.
Neutral means it doesn't favor any specific payment processor, blockchain, or payment mechanism. Any mechanism that wants to be expressed within internet-native standards should be able to express their payment flows within that standard without gatekeeping. And as for being within the existing client-server paradigm, as those of you who have integrated payment APIs before have likely noticed, there is usually some component outside of the direct request the client is making to the server, whether it's calling someone else or having a webhook.
And it can be achieved without needing to put a human in the loop. Almost every payment that has ever happened on the internet has happened downstream of a human entering a credit card on a website. So, if we believe we are entering the era of agents, we need to break out of that paradigm. And you can see remnants of this idea that we need an internet-native payment mechanism going back to the 80s and 90s.
I believe it was released in the 1997 HTTP 1.1 standard, where HTTP status code 402 was reserved for future use to signify that payment is required to access this resource.
In fact, Marc Andreessen, co-founder of Netscape, spent a lot of time trying to make payments work on the internet, but the technology just wasn't there yet. One reason we think the technology is ready now is the rise of stablecoins. Five years ago, in 2020, it cost about 10 dollars to send a stablecoin. However, while the world was focused on AI and many other things, blockchains became very good. Now, it usually costs less than 0.1 cents to send a stablecoin. It doesn't matter if it's 1 dollar or a million dollars. However, the actual cost on-chain to send that money is 0.1 cents, with no percentage-based fees. What you are paying for is purely the blockchain resources your transaction is utilizing.
This is counter-intuitive. It goes against expectations. Most people are used to a 30-cent fee and a 3% fee, but on a blockchain, you are paying for the processing power of the blockchain you are actually using. So, as blockchains scale, achieve more throughput, and settle faster, those direct benefits can be passed on to payments. AI is forcing us to really re-evaluate internet-native payments. AI is used by hundreds of millions of people every day now, but the number of economic transactions they are executing is incredibly small. One reason for this is that AI agents are basically programs running on computers.
How many of you in the room have ever written an AI agent? Please raise your hand if you have. Probably about a third of you. When you start trying to build AI, you quickly realize that an AI is not much different from a long-running while loop calling an LLM. These agents have no way to consistently conduct transactions. In the end, even if such a garden exists, it becomes something like a walled garden.
So, let me ask by a show of hands: how many of you have had an AI agent pay for something on the internet? Perhaps using ACP or some other standard? Yeah, you can see that standards to deal with these problems are beginning to emerge. ACP is a fantastic standard for checkout and human-in-the-loop conversational commerce. But if we want to achieve true autonomy, I think a payment standard needs to be built directly into the internet. Because AI agents are fundamentally going to disrupt the fundamental economic model of the internet.
If you think about how much of the internet has worked, how it has worked until now, a merchant pays a website. The website shows you content and the merchant's ads. You, as a user, consume that content and those ads, and at some point, you convert and buy a product from the merchant. That is how much of the consumer internet works. Websites have an incentive to publish content because they can serve ads. Those ads convert. The merchant pays. A fantastic closed loop has been created among the three actors. What we are seeing is that AI removes the ads, and by doing so, it removes the payments as well.
As more people start consuming the internet using chat interfaces, you probably haven't seen ads from the websites that provided the information for the LLM's responses. Scraping to train these LLMs also results in content publishers missing out on value. In this way, this cycle is broken. We need a new cycle. We need a new economic model for these interactions. One way to achieve this is to pay directly for content. We skip this loop and pay the website directly. This is where x402 comes in. This is an open standard for internet-native payments that Coinbase is working on.
The x402 Protocol Mechanics: A Payment Standard Leveraging HTTP Status Code 402
In fact, x402 is a bridge between the internet and blockchain-based payments. It's very distracting to speak while people are clapping. It is a bridge between the internet and blockchain-based payments, and you can get the benefits of blockchain and the benefits of these sub-cent transactions. Part of the reason why it's not feasible to pay directly for content on the internet is that it's really difficult to move 30 cents, 50 cents, or even a dollar on existing rails where fees are 30% to 3%. As a business, if you are charging 50 cents, you might only get 14 cents of value now, and this eats up a lot of margin. On the other hand, if you are being charged a 0.1 cent fee, you can earn 40 to 50 cents, or 49.9 cents, right?
So, what is x402? x402 is an open standard for internet-native payments. It meets the points of the philosophy I mentioned at the beginning of the talk. It started at Coinbase.
Actually, I created it, and it's currently being transferred to an independent foundation structured as a Linux Foundation JDF. So, how is it going? In November, x402 processed 70 million transactions. Honestly, this growth is astonishing. There was a fantastic chart showing 30% week-over-week growth, but it hit a major inflection point in November and has really grown rapidly. Of these 70 million transactions, the actual amount moved, the dollar volume, was about 40 million dollars. As you might notice, 40 million dollars is less than 70 million. The average transaction size on x402 represents a trade of about 80 cents. These are transactions that were not really possible on card rails, and with x402, you can scale payments from 1 cent up to a million dollars, if you really need to. However, this niche market of micropayments has been the product-market fit for x402 so far, enabling new things that were impossible before.
So, how does x402 actually work? It functions standardly within the existing client-server flow: a client—be it a browser, mobile phone, LLM, or bot—sends an HTTP request to a server. That server responds with a 402 status code and a header saying "payment required." This header contains data telling you how to pay. What that data looks like, I will explain shortly. The client sees that header and constructs a payload representing that payment. I will touch on how that payment payload is constructed soon. Don't worry, I'll explain. Then, it resends the same request, this time including a "payment signature" header and the payload it constructed.
The server has choices. It can do all the work shown in this slide itself, or if the team is not very accustomed to working in Web3, they can delegate the interaction with the blockchain in x402 to what we call a "facilitator." Facilitators have a fairly standardized flow. The server calls the facilitator's "verify" endpoint via HTTP, propagating both the payment requirements it sent to the client and the payment signature sent by the client. It asks the facilitator, "Will this payment be valid? Should we actually process this payment?" On the happy path, the facilitator responds with a 200 response, saying, "Yes, this is a good payload. By this, you will receive payment. You should perform the work necessary to respond to the client."
Here, the server performs the work it does as a web server, such as database queries, cache lookups, or PDF generation. After the work is finished, it posts the payment signature and the payment requirements data it gave to the client back to the facilitator's "settle" endpoint. The facilitator handles sending the transaction to the blockchain. Once the blockchain transaction is sent, the facilitator responds to the server, saying, "This payment succeeded." This is actually a blocking operation. With modern L2s and modern blockchains, the time it takes to confirm a transaction is about 2 seconds, and before returning to the client, you can actually know that you have received the money and that it is an irreversible transaction.
Stablecoins support refunds, but they do not support chargebacks. Therefore, as a server, you can always say, "Oh, I made a mistake, I'll refund the client." However, the client has no ability to take funds that have already been passed to you. And now that you have the funds, you can return to the client, saying, "Yes, here is that news article, here is the API access you requested." This is done through standard HTTP verbs, functioning throughout the entire HTTP specification simply by utilizing headers. You can return it on POST, GET, PUT, whatever you like.
Now, let's look at this payment requirements data structure. This is the top-level structure of the x402 protocol. There is a top-level version of the x402 protocol. We will be releasing spec V2 shortly. And there is a list of payment requirements called "accepts." Through this "accepts" keyword, the server can specify multiple payment methods. As a server, you can say that you support payment in USDC on Base. You can also say that you support payment in USDT on Solana. And in the future, x402 will support fiat methods as well. You might say you support USD via Mastercard or Visa. And there is an "error" field to convey error information to the client.
Each payment requirement within the "accepts" key is expanded here, consisting of scheme, network, asset, pay-to field, and max amount required, which is the amount to be transferred. There are other metadata fields, but these are the most important. What this looks like is that you can return something like what is on the right to the client. Here, it is operating on x402 version 1, accepting the "Exact" scheme on Base, which is the USDC identifier. And it asks you to pay to a crypto address. This crypto address can be any wallet. It can be an exchange like Coinbase. It can be any address capable of receiving crypto assets. And if you do not pay, it results in "payment not included."
Let's talk about the payment payload. You might notice the scheme and network, but the way to think about it is that the scheme is the logical way money moves. With "Exact," it is equivalent to me handing you one dollar. That is the extent of the complexity of the exchange. I took a dollar out of my wallet and handed it to you. There could be other logical ways to move money. For example, in LLM token generation, because LLMs do not finish deterministically, you do not necessarily know how much to charge until the token generation is complete. Thus, you could imagine a scheme called "up-to." This means you might authorize up to one dollar, but you do not yet know exactly how much will be charged. In other words, you have it pre-authorized for one dollar, and after the token generation is complete, you charge based on the actual work performed.
The way this payload is constructed is called the "mechanism," and the mechanism is built on top of the scheme and the network. What this means is that the way the payment is executed is decoupled from the network and the logical way the payment is executed. "Exact" on Base or Ethereum behaves differently than, for example, "Exact" on Solana. And you can optimize the payment flow for the blockchain network or fiat network where funds are actually settled.
x402 Design Philosophy: Safety, Nativeness, Ease of Adoption, and Extensibility
Some of the goals for x402 were safety, nativeness, ease of adoption, and neutrality and extensibility. Regarding safety, the client holds the logic to construct the payment. Neither the server nor the facilitator has the ability to move funds unless the client authorizes the movement. The server chooses the payment mechanism it chooses to accept, so one cannot say, "I paid on this minor chain, so you are obligated to provide your service." The server specifies the mechanisms it chooses to accept, and the client chooses which one to use. Similarly, at a point of sale, you might accept Visa, Mastercard, Amex, or cash. You take out your wallet and say, "Oh, I have a Visa card, so I will pay with Visa."
The facilitator does not hold funds at any point, nor does it have the ability to direct funds or route them anywhere. This is simply an abstraction layer on the blockchain to ensure the server does not need to run hot wallets or RPC nodes. The server can delegate the responsibility of gas management and large-scale transaction processing on the blockchain to the facilitator. Regarding the safety of EVM Exact, we use EIP-3009 messages. This is the standard for signature-based transfers in the EVM ecosystem. As a result, the only way funds can move is if the client has signed the intent to authorize the movement of funds.
Regarding nativeness: We want to include payment in the existing communications that occur between the client and server. This means these types need to be expressed in a way that is native to the transport. Also, in x402, we separate the transport from the method of moving funds. In HTTP, we include payment requirements and payloads in the headers. In existing requests occurring in MCP, we include them in the meta field present in all MCP interactions and tool calls. In Agent-to-Agent, we include them in the x402 payment field of the metadata. We follow the convention of each transport that occurs, and this is all standardized and documented in the repository.
Anyone can write a client or server independently of our reference SDK and be able to interact with other clients and servers. This is because how the transport works is part of the standard. You can read the documentation on how x402 works within an MCP context to write your own client, or use many of the clients that have been written over these past few months.
Ease of adoption is very important. As much as possible, we have ensured that no RPC or gas is required on the client side. There should be no need to introduce new technologies into the client stack. We want to ensure as much backward compatibility as possible with browsers and the existing Web ecosystem. Also, all signatures, standards, and signers in the SDK comply with industry-standard interfaces. This is very granular, but if there are existing patterns for expressing actions, use them. Do not invent new things.
We are trying to provide middleware for all common HTTP frameworks. This means if you are using Express, Hono, Flask, Gin, or others I cannot list here, you can integrate x402 into your existing services with one line of code as middleware. And, as I mentioned earlier, there is a facilitator. This abstracts away the cryptography and lowers the barrier to adoption significantly. You do not need to learn how to operate a hot wallet. You do not need a node, either. With a facilitator, you only need the URL to send RPC requests, and everything else is executed. Our middleware abstracts that. You just need to add the URL of the facilitator you want to use to the middleware settings.
Next, extensibility and neutrality. This is the reason why we decouple the data structure and implementation. This allows EVM x402 and SVM x402 to be different, and for clients and facilitators to have a common understanding of what to do in that scenario. This is similar to how if an image tag uses a PNG, the server knows how to encode that PNG, and the browser knows how to render that PNG. Philosophically, we prefer to be agnostic and modular rather than trying to solve all problems across the full stack. We are trying to solve one problem very well. Regarding identity or other aspects of agent systems, we want to be compatible with them, not force everyone into our full-stack solution.
So, what do you get from this? This demo video here is where I am using a chat interface LLM to investigate x402 and the trends happening with x402 recently. The unique point of this chat interface is that it has MCP tools that provide access to a wallet with stablecoins, the ability to pay for x402 resources, and the ability to discover x402 resources. As you can see, I first search the web to investigate x402, and then check Bazaar, which is our marketplace for x402 services. Then, I pay for data from one of those services to enrich the report I am writing about x402. These funds—and this is the wallet the agent has—these funds are isolated to the agent. There are 56 cents in the wallet. It can only use those 56 cents. And I have the ability to set permissions on how much it can use per request or within a session.
Anyone can build this experience. It is built entirely on top of open standards like the wallet ecosystem and infrastructure surrounding x402 and stablecoins. This experience works for anything that accepts x402. In other words, if your API accepts payment via x402, this MCP can now pay for your content. This is very powerful. I believe it enables a level of agent utilization that was previously impossible. Currently, each MCP tool must be integrated manually. Now, if you integrate one MCP tool, you can pay for everything in the ecosystem.
What you get is a dynamic agent. The set of capabilities an agent has is not limited to the set of vertically integrated or walled gardens that you, as a human, have integrated one by one. Just as a browser can visit any website on the internet, an agent can now pay for any tool or service to do a better job for you. Now, I will pass it to Josh. Josh will show you a solution on how to build payment infrastructure on AWS using x402 and stablecoins.
Building AI Payment Systems on AWS: Leveraging Bedrock and Agent Core
Yes, thank you, Eric. Let's start from a high-level conceptual perspective. We here at AWS are thinking about the stack for building scalable AI payment systems. This stack starts with the platform or the foundation. AWS provides primitives like EC2 for compute, Amazon Bedrock for AI, security primitives like Nitro Enclaves, or edge services like CloudFront, as Arvin mentioned earlier. Today, I will talk about some of these foundations that support this stack and how to actually build solutions.
On top of that, we leverage open protocols like the ones Eric spoke about. Some of these have been around for a long time: HTTP, DNS, HTML, languages, frameworks, and protocols. And now, x402 has emerged as an open standard for payments, which we can integrate and start using. From here, you can combine platforms and protocols to build and enhance more advanced services. This is the middleware; some of these are as-a-service products, B2B products, and Amazon provides services like Bedrock. We provide AgentCore for Bedrock, which I will talk about shortly. And we have a complete suite for agentic AI. Coinbase provides what is called AgentKit, a tool that connects wallets to AI agents, which we will also leverage today. And finally, all of this allows you to build complex solutions that connect Web2 applications, Web3 applications, hybrid applications, and agent-to-agent communication, including payments.
So, if we zoom out, I won't spend much time on this slide, but AWS provides agentic AI solutions across the entire stack. At the bottom layer, there is infrastructure, development and services for builders, and applications. We offer a suite of models, tools, applications, and expertise to help you start your journey in the way you desire. We also provide robust infrastructure, including custom silicon, data access, and other foundation services.
And today, we will zoom into this middle layer and Bedrock. Because we are talking about builders and the adoption of these new protocols. Now, Amazon Bedrock, as a premise before getting into this, is a serverless, fully managed service that helps you build, deploy, and operate Gen AI applications, including agents. Bedrock provides access to leading foundation models from Mistral, Anthropic, Cohere, Amazon, and others, allowing you to apply guardrails, optimize costs, optimize latency, and utilize data very easily. These features can be used for any type of use case, including building and operating crypto-native agentic AI payment systems.
Bedrock also includes AgentCore. And we have these services at the top. These are services to securely deploy and operate agents at scale. You can think of this top layer as what operates and runs the agents. There is a runtime, which is a serverless runtime for long-running agents, so you do not need to manage infrastructure. Next is the AgentCore Gateway, which allows you to easily integrate MCP servers and APIs with agents, providing a simple way to empower agents with a large number of tools. And today, we will use both of these services. And finally, the AgentCore Browser and Code Interpreter allow agents to operate autonomously within a browser and execute code on your own terms. Regarding the bottom layer, think of them as supporting tools that enable these agents.
To build enterprise-ready agents, you need identity with standards-based authentication. Use something like OAuth for agents. AgentCore Memory allows agents to store and retrieve short-term and long-term memory, as these agents are stateless and run within the runtime. And we will use this today as well. Finally, observability helps centralize the observability stack for Gen AI agents. Especially in payment systems, due to the lack of precision and determinism in LLMs, observability is a mandatory element that requires an additional layer. So, if we zoom out using these tools, what can we achieve? One of the key areas we see in the maturity of AI is the ability to discover and use tools. Agents may eventually have access to tens of thousands of tools. The AgentCore Gateway connects to this ecosystem, enabling tool discovery, combining it with Auth to decide which agent can use which tool, and starting to leverage tools that can use paid API keys. You might have existing relationships, such as monthly subscriptions with API keys, or you might want to call internal services running on Lambda functions or EC2 servers. But today, we are talking about this intermediate channel. Sometimes you want to give agents the ability to discover and use tools. As Eric showed in the video, go see what is available on the internet, and go see what can be done to achieve goals using x402. Thus, you can create an architecture that uses CloudFront, allows functions to be executed using Lambda Edge, has content backed by S3 or EC2, and builds this framework.
Travel Agent AI Implementation Example: End-to-End Architecture with Nitro Enclaves and AgentKit
So today, let's talk about an example of a travel agent AI and a data provider that works with it. This could be built by an enterprise. Let's imagine a virtual company trying to provide services to customers building automated vacation packages. The agent presents a frontend to the user. This is the travel agent AI interface, i.e., a chat.
And the AI can discover available tools from the x402 MCP server using the Agent Core Gateway. As an example here, this agent needs to leverage many different types of data. It might need to leverage a global distribution system with hotel inventory, flights, flight prices, and availability. This might be charged in various ways: per query, booking fees, or other charges. It might also need a database of tourist spots and local attractions. These might be charged per query, right? Like, send me the reviews for this restaurant for a penny. It might also need weather data to identify delay risks or forecasts, or to check if you want to go to a sunny place.
First, let's zoom out and look. This is the end-to-end architecture. On the left, there is the Travel Agent AI, driven by Coinbase's Nitro Enclaves and a server wallet using Coinbase's AgentKit, interacting with the Bedrock AI agent. In the center, there is the data provider or merchant. They provide weather data, map service APIs, and rails. This is the facilitation layer Eric was talking about.
Since we are planning to make crypto data payments, let's look at the foundation first. Secure wallet using Nitro Enclaves. I won't spend much time here, but there is a blog we wrote jointly with Coinbase on the AWS site. We can send or share it. There might be a QR code at the end. However, this is the architecture Coinbase is using to drive server wallets on AWS. When developers want to create a wallet or sign a transaction, they follow this workflow through API Gateway. The request is passed to a secure signer within this enclave, and neither Coinbase nor AWS operators can access these keys. This wallet provides a secure foundation for building and enabling crypto payments. All that's left is to connect to it.
So, AgentKit works in conjunction with the Bedrock AI agent. This is the architecture I will talk about today. This architecture powers that AI agent. And it uses AgentKit to access this secure wallet. You can see AgentKit at the gateway on the right, but looking from the top down, there is a supervisor agent. This can be any multi-agent workflow. This is just an example. There is a supervisor agent running on the Agent Core runtime, which interacts with an itinerary agent that manages travel memory and planning. And then, it makes assumptions. It confirms that this place is good, so it says we need to find a hotel in this place. We want to go there, so we need to confirm availability. So, it has the tool agent check these assumptions.
The tool agent uses the Agent Core Gateway to search for available tools. Some of these tools might be registered directly with the Agent Core Gateway, but there could also be external MCP servers outside the account. This might be an x402 MCP server, or some universal travel MCP server operated by an existing travel company or travel agency. Looking at the end-to-end path, the tool agent calls the Agent Core Gateway. It calls the x402 MCP server through the Agent Core Gateway, accesses the necessary data, and makes payments via x402. It becomes possible to leverage the wallet held through AgentKit. This is also registered with the gateway.
This is the AI agent side, but in fact, you can also see the other side on AWS. Suppose you are a data provider. That is, a service providing weather data, a service providing map data. Remember, these are entities providing flight scheduling or distribution. For these customers on AWS, there is an opportunity to start monetizing data in new ways for new workflows, without relying on existing bundles or subscription-based payments, using the bridge called x402.
So, to show our position on the map, this is the architecture seen from another perspective. There are parts that overlap with the Agent Core Gateway. You can see the same x402 MCP server seen earlier. This is for showing the position. AgentKit and the x402 MCP server are registered as tools. When you pass through this layer, it is sent to the Lambda function here, Lambda Edge, via the CDN, i.e., CloudFront, as a viewer request. This viewer request might not have payment information at first. So, this Lambda function returns a request saying this content actually requires payment. That a header indicating payment is required is needed. Specifying assets, networks, and parameters like those Eric spoke about, the client can retry the request.
If a payment header exists, it asks the facilitator to verify it. It asks, "Will this payment work?" "Will this payment pass?" "Is this address valid?" If it is valid, the x402 function returns a response to the server to make the request, and finally, the agent can issue the correct payment. At the end of the workflow, you can forward the request to the origin. In this case, it is an EC2 web server hosting satellite weather images, JSON weather data, or any data the travel agent needs. At this point, the agent requested weather data, the payment was made by the wallet connected via AgentKit, and the merchant was prompted via x402 for the accepted payment. The facilitator processes the settlement on the blockchain, and the funds arrive in the merchant's crypto wallet.
We also have additional resources, blogs, and more. The Agent Core documentation explains observability, identity, runtime, and gateway in detail, allowing you to deepen your understanding of these primitives. There is also a blog written jointly with Coinbase, which delves into the Nitro Enclaves-based wallet we used. And there is a link to the CDP documentation here. This covers x402, AgentKit, and other services they provide. Well, thank you for your time. I hope you enjoyed this talk. Have a great weekend.
- This article is automatically created using Amazon Bedrock, maintaining the information of the original video as much as possible.
Discussion