[#84] Stripe's MPP, Coinbase's x402, the A2A Payment Protocols, and why stablecoins will power the agentic economy

Everyone's talking agentic payments. But there are two markets here: agentic commerce and machine payments. MPP and x402 are building for the latter, using stablecoins and HTTP 402.

Over the last few weeks, there has been a lot of chatter around ‘machine payments,’ and some of the new launches in agentic payments, and more specifically - machine payments, which is what Stripe’s MPP (Machine Payments Protocol) and x402, by Coinbase are building for. And something that Viraj (ex-founder Celeriz, Head of APAC Partnerships at Encryptus) have been discussing.

For those of you folks who have been following along, a theme that I’ve been trying to really understand over the last 6 - 8 months, is more about is the world of agentic commerce. You can read my previous articles on these below:

1. [#75] The AI Money Movement Layer: MCP, ACP & TAP are launched but are autonomous payments really the future?

2. [#80] Google’s UCP & AP2: Moving agentic commerce from just “plausible” to “scalable”

3. [#83] The AI Money Movement Layer (Part 2): 5 Blueprints Built on the Same Core Principles

TLDR, the hypotheses formed, and what the market seems to be validating are:

1. Agentic commerce is shopping x payments. Shopping can happen via LLM chats, chatbots etc, but payments (and fintech in general) is not just an “experience” layer. It requires trust. And that is why Open AI is rolling back its “Instant Checkout.” The vision for this was: Complete everything IN the AI checkout itself. But barely anyone onboarded.

2. There are fundamental issues with todays systems, which make agentic payments hard to pick up. I’ve talked about this before, but a quick example is why Alipay AI worked, and why others didn’t. Alipay owns the acquirer stack (payments PSP), and the issuer stack (customer app + takes the onus of verifying customer identity). So everything is just Alipay integrating. Now, take a look at current fiat systems:

But all of these payment protocols are still fiat stack first.

And secondly, and more important, all of these see this more as a human delegating a task to an agent, and then the agent completing the task end to end. The product being bought here is a “human consumable” good. In the case OpenAI’s - Instant Checkout - they partnered with Shopify - an ecommerce website. Razorpay partnered with Bigbasket. All human goods.

What hasn’t been considered (in the mainstream world, x402 has actually been around since May 2025) is an agentic flow for a “machine consumable” good. A better way to understand this: Consider a flow where an agent is carrying out some task autonomously. In that workflow, the agent needs to access a paid service or endpoint. This endpoint charged per API call. The agent has to do a payment or submit some sort of proof of payment to complete the task.

THAT is what Stripe’s MPP, and x402 are trying to solve. That if there is an agent carrying out tasks, and needs to consume some API which is paid, how do they complete this payment (usually a micropayment) WITHOUT having to constantly have a human in the loop?

Every payments player in the world today is trying to launch their own protocols for agentic payments.

Till now, the chatter in the agentic world has been more about users wanting to buy something, doing that shopping on a LLM layer, and then wanting to pay seamlessly, via or through the agent platform, either through some embedded, or a redirection experience. Google with its AP2 (mandate based auth) + UCP (a unified protocol to do shopping + standardize payments), Alipay (with its fullstack), Stripe (its ACP, which utilizes its SPT) all consider the flow in a commerce flow or what I’m calling a “human consumable” good. You can check out the table below.

So, then, in this whole agentic payments flow, while everyone and their aunt is trying to launch their own protocols, it’s also important break agentic commerce into: agentic commerce payments, and machine payments.

This space is more like a spectrum from micro- machine payments, to human in the loop is agentic commerce

And with these two sitting on opposite sides of the spectrum, as the transaction amount becomes bigger, and the frequency of purchase per user becomes lower, there is an increasing need for a human in the middle, and additional auth measures, such as 2FA, biometric, passkeys, and so on.

1. Micropayments in the agentic workflow for machine consumable goods: An agent is tasked with building something, or paying for something, and needs access to a paid service for this. Could be some APIs, or access to some data. Agent decides and pays autonomously. Protocols for this: x402, MPP (which we’ll get into later)

2. Agentic commerce for human consumable goods: A human is buying a “t shirt” or some item of furniture let’s say. So the agent helps discover, select, negotiate, and the human approves. The agent then needs to call checkout, and the agent then executes the protocol: UCP, ACP, AP2

What is clear is that while the agentic commerce stack will always have a fiat angle to it, the machine payments stack is very obviously betting on stablecoins as the default layer

Now, this market still has a long way to go. It is still early days. But, the deeper you go into understanding some of these systems, the more I genuinely believe that stablecoins will be the default layer for a lot of the agentic workflows. And specifically, for machine payments.

But should stablecoins be the native payment rail for machine payments?

In agentic commerce, it could still be fiat: if we go by the thought process that transactions for human goods is (relatively) more occasional, and of a higher ticket size. In machine payments, when we are talking about things such as paid endpoints and so on, and transactions can go into hundreds or thousands per day, stablecoins just make more sense, not just from a “number of stakeholders” involved perspective, but from a cost perspective.

1. Fewer stakeholders, fewer hoops to jump through

A traditional card payment touches 5+ intermediaries: issuing bank, card network (Visa/Mastercard), acquiring bank, payment processor, and sometimes a payment facilitator. Each adds fees, compliance requirements, and latency. Settlement takes 2-5 business days. Compare that to stablecoins. A stablecoin payment needs one signature from one agent. (which should be ideally a MPC based threshold signature to ensure maximum security). The transaction settles on-chain in seconds to minutes. No interchange network, no card association fees, no dispute arbitration layer. An AI agent with a wallet can autonomously pay another agent or APIwith no bank account, no KYC flow, no human in the loop. My core point here is that: Fiat payment rails were designed for humans transacting with merchants during business hours. Machines transact 24/7, at millisecond frequency, across borders. The legacy stack wasn’t built for this, and probably cannot support the volume of payments in any case

2. Fiat systems usually charge a fixed fee + some % of the transaction. In many cases, you can end up paying more in fees than the amount you’re receiving, in the case of a micropayment

Lets take an example. Let us assume that an agent needs to pay $0.1 for something.

Now, in fiat rails:

1. Payment amount: $0.01

2. Paypal charges (link to website): Charges 3.4% + a fixed fee. This fixed fee as per the Paypal website is $0.3.

3. So then: total processing fee = $0.30034 (3.4% of $0.01 + $0.3)

So, the merchant receives $0.01. But pays $0.3. Where is the sense?!

Compare that to stablecoin rails:

1. Payment amount: $0.01

2. Solana charges (link here): Can range between $0.0001 and $0.001.

So merchant here receives $0.009 - $0.0099 or ~90% - 99% of the transaction amount.

Now, there are other barriers that stablecoins obviously have to cross. They win on speed, structurally being able to provide micropayments, and the authentication (Stablecoins require a cryptographic signature, while fiat platforms usually require some tokenized credentials, and in some regions need a 2FA) The barrier to solve for stablecoins MAINLY as I see it is user familiarity. The fact of the matter is that there is no way to get around wallet funding. You can make wallet creation as seamless as possible, but there will be a wallet funding step, and for the average user, they may not even know what stablecoins are. But that is from an agentic commerce step.

For machine payments - its just a type of “currency.”

It looks like existing platforms with distribution: Coinbase and Stripe are betting on agentic machine payments and stablecoins

Stripe published its repos for machine payments. And for MPP as per the github repo, it support crypto payments, and more specifically stablecoins as well as fiat. x402 by Coinbase supports stablecoins (USDC exclusively). But before we get into what these are, let’s take a step back, and first try to understand the market for ‘machine payments,’ and why should we even care about this space?

What’s the market size for machine payments?

Honestly, this is hard to size. This isn’t a market that existed before, and there are a lot of assumptions we will have to make here. All the data I can find right now is for the entire agentic commerce market, which I presume includes both the transactions for “human consumable goods” and “machine consumable services.” Various estimates show that different reports are estimating this market to be in the 10’s if not 100s of $billions. Lots of assumptions have been taken, mainly around first estimating the total global payments volume. Lets map them out:

• In 2025 according to a Mckinsey report the global payments volume was $2 Quadrillion (that’s fifteen 0’s btw).

• Then, another Mckinsey report, also estimated that the agentic commerce market (volume, not revenue, I assume this includes agentic + machine) could reach ~$3T in 2030. As a % of total global payments volume, this is 0.15%. And then some % of this, I would assume would be machine payments.

• Very crude, but lets just assume the % of machine payments (of agentic commerce) to be 1%. No scientific reason, just taking this number randomly: Calculations suggest is a market of $30B!

So there is a significant enough market here, in terms of value. And today, in terms of ACTUAL traction, not some numbers done on a spreadsheet, suggests that while it is early stage, it is showing promise.

Let us look at another statistic. Coinbase’s x402 protocol has processed 150M transactions ever since it was launched in May 2025. And when I say transaction, what I mean is, any time an agent (or script) sends a payment through x402 to access a resource. So this can mean:

• Agent paying an API for data (market signals, sentiment, leads)

• Agent paying for compute or storage

• Agent paying another agent for a service

• Agent tipping, micro-purchasing content

This is a big deal. 150M transactions are not nothing. Granted, out of a global payment volume (# of transactions) of 3.6T, this is 0.00004%. A blip. But in terms of absolute transactions, and potential market size, ($30B), the number we calculated earlier, this could be big. And that is probably why everyone is rushing to launch their own machine payment protocols - like Stripe with MPP, and x402 with Coinbase.

What is MPP? (Machine Payments Protocol?): Well, it uses the long unused HTTP 402 status code to enable agents to pay automatically for resources

Well, this is a payments protocol co-developed by Stripe and Tempo and launched in March 2026. Tempo Labs is a blockchain startup incubated by Stripe and Paradigm.

MPP is made for an agent first world: it essentially allows AI agents to automatically pay for resources like API calls, data feeds, and computer power using a “challenge-response” flow, and it does this using the HTTP 402 payment code (unused since 1997!)

MPP is a request-response protocol that adds a payment step to any HTTP API call. That’s it. Everything else is plumbing. For the uninitiated, whenever you make ANY call on the internet, you’re making a HTTP call.

To understand MPP, lets go back to the absolute basics, and first understand what HTTP is.

Any HTTP call has the following components:

So, now, let’s say you want to check the weather in Chennai. You open up your browser: Google Chrome, and type in: what is the weather in Chennai? Your browser makes this HTTP call:

REQUEST:

• Method: GET (since you want some data)

• URL: https://www.google.com/search?q=what+is+the+weather+in+chennai+today

• Headers: User-Agent: Chrome/120 on Mac, Accept-Language: en-IN, Cookie: (your Google login session)

RESPONSE:

• Status: 200 (OK, here you go)

• Body: <html>...the entire Google results page...</html>

So, essentially your browser sent a GET request with your query in the URL, Google’s server processed it, and sent back the full HTML page you see.

Now, here’s what is elegant about both the MPP and the x402 solution. It doesn’t use anything that wasn’t there, which is where HTTP status code of ‘402’ comes in.

HTTP has existed since 1997 and is one of the building blocks of the internet.

HTTP responses have multiple status codes. 200 means: “here you go.” 404 means doesn’t exist. 402 already existed, but no one ever used it until now, which essentially is the response code for “pay me first.” So, now, to explain this in an easier fashion, let me use the same example I used above: fetching the weather, and show it also in an agentic workflow.

Workflow WITHOUT payment

Pretty straightforward. I’m using the example I talked about above. I make a HTTP call via my browser to Google. Google in turn makes a HTTP call to a weather API / server (using the exact format I mentioned earlier), gets a JSON response back, and then converts it into a pretty weather card that it embeds into your search results.

Workflow WITH payment using the Machine Payments Protocol

This is where the Machine Payments Protocol that Stripe co-developed with Tempo has come in. Essentially what is happening here is that, while today, this Weather API is free, let us assume in a world, the agent, or the LLM is making a call to a paid resource. Now, in this situation, instead of going through a human flow, the agent is able to leverage the 402 response code to understand that:

1. It needs to make a payment to get this service

2. It needs to make a payment in a way that the service can verify it.

But the 402 status code anyway exists. What is MPP coming and doing exactly?

Well, think of it this way. 402 existed, but there was no instruction on what to do here to proceed with payment.

👉 So, in a pre-MPP world, if payment was required, either there would be a response that said 402, and that is it, or some sort of custom message, which said: hey - buy a subscription, or something else.

MPP essentially gives the agent some instructions on WHAT it needs to do to actually proceed with this payment / or provide proof of payment, and access the service.

👉 So, in a post MPP world, while both sides do need to speak MPP, there is now a way to ask for payments, and for the agent to know, what it needs to do to verify the payment. The mppx library is the thing that generates that structured body. Without it, the server wouldn’t know what format to return, what challenge nonce to include, or how to verify the credential when the agent retries. So, here, the server (in this case the Weather API service) needs to have the MPP library installed so it can GENERATE challenges and VERIFY credentials. After the MPP library is installed, if this action requires a payment, the response back to the agent would be something like this:

Server: 402 Payment Required

• Body:

  • {“type”: “payment-required”, ← always this

    “challengeId”: “ch_abc123”, ← always present

    “amount”: “0.01”, ← always here

    “currency”: “usd”, ← always here

    “methods”: [...] }

For the agent to proceed, first it needs to have a MPP aware wallet, so that it can read the challenge, and then send the credentials. If only one side has it, nothing works: Example: Server has MPP, agent doesn’t → agent sees 402 and doesn’t know what to do next. If the Agent has MPP, server doesn’t → server never sends a proper 402 challenge in the first place

The next question I would have here, is: what is an agent wallet? And what needs to be done to make it “MPP aware?”

So, to think about it in a rudimentary way, think of this agent as a code running on a server. For it to execute this payment, it needs to:

1. Money somewhere: either in a bank account, or in a crypto wallet

2. It needs a way to move that money

3. It needs some sort of way to authorize that money movement: either access to some card credentials, or, what is in the case of crypto payments: needs to have some sort of MPC enabled wallet, which enables threshold signatures to authorize the transaction.

A point that I have come across is: why can’t you just give this agent access to a card or something?

This is an easy one to answer. Security nightmare. You cannot just hand over your card details or API keys. If this agent gets hacked, then your details can be used by anyone! So there needs to be some middle layer that already holds some funds, which have been pre-approved, or holds some hashed credential that references your real credential stored somewhere else. (An example is something folks are familiar with: the whole concept of card tokenization. The actual card details are stored in the network - like Visa or Mastercard, or now, increasingly PSPs. What the payment player, or in this case, the wallet stores is a tokenized reference to that card number, which the network, or the PSP can use the map, and look up the actual credential).

This is where the agent wallet comes in. This is the “container” that the stablecoins, in case of a crypto rail. In the case of holding a tokenized credential, (if fiat rails are used), a wallet may not be required, just access to the credential should be enough

This is essentially the wallet that the agent has access to, and that has the MPP server installed, so it can read the challenge, and understand what it has to do next to continue with the transaction. MPP is developed to support both: crypto and fiat rails. You can check them out more in Stripe’s documentation here.

The crypto native method in MPP

This is similar to the stablecoin payments stack I discussed earlier. This requires some sort of agentic identity (usually via an agent platform) to be registered. This probably requires some type of one time onboarding of the agent platform with whoever is providing the payment rail (if the Stripe MPP is being used, then onboarding would be required on Stripe).

This is how it goes:

The User flow (note this is the “payment initiator” so it doesn’t have to be an individual, it can also be a B2B player)

1. Agent platform (Crews, Google ADK, even a Claude, ChatGPT, which runs the agent that you as a user create) is onboarded as an agent on the entity enabling these rails (Stripe, Mastercard, Visa etc), and enable stablecoins / crypto as a payment method

2. This user would need to create some sort of wallet (if it is Stripe, then they would use Privy), and link this to the agent

3. This wallet is funded with some stable-coins, so there is some on ramp happening here: either via an off ramp provider, or via a direct exchange integration if it is a B2B agent flow

4. The key management is handled by an MPC provider (like Silence Laboratories), which shards the keys, to provide the highest level of security

The merchant flow (note: this is the “payment accepter” flow)

1. The merchant does need to sign up on Stripe, and first enable stablecoins and crypto. This is important, because in certain regions, this isn’t available

2. The merchant then needs to install the mppx (MPP) library

3. They then need to define what service is paid for (example, if an agent calls API X, is that paid? Or is API X free, and API Y is paid?)

4. They need to set a price per API Call

5. They need to set up the method that they allow (crypto - on Tempo)

6. Generate a server secret key (for challenge binding - the challenge needs to be signed by this key, and a hash created by the merchant for authenticity, and this is what the merchant checks against when the agent pays, and presents the payment proof )

Obviously, the above set up happens prior to the payment. At the time of payment, if this is a paid service:

1. When the 402 status code is sent, this contains the deposit address. So here, the “payment intent” has already been created by Stripe. The sequence is: - the agent calls the paid API. The merchant server calls Stripe: “Create PaymentIntent, crypto, Tempo”. Stripe returns: PaymentIntent + deposit address 0xABC. Server caches 0xABC. Server returns 402 with 0xABC in the challenge body

2. The agent selects the Crypto method to pay, accesses the wallet with the stablecoins, signs using MPC, transfers the money to the entity wallet, and then retries the original HTTP GET Call with the payment authorization (this is the challenge ID + payment credential) in the header.

   • Agent → Server: “GET /weather?city=chennai”

   • Authorization: MPP <credential>

3. Server checks the challenge validity, deposit address, and the Stripe monitors the blockchain (Tempo) and confirms when the funds land, usually in ~2 seconds, and returns the 200 response (OK)

✅ TLDR: The agent platform being used by the user needs to be onboarded as a platform on Stripe

✅ Both need to install the MPP library, so that the request / response structures are defined - each party knows what to do

✅ Both need to set up: the user needs to set up a wallet and fund with stablecoins. The merchant server needs to define endpoints, methods enabled, and generate the server secret key to sign the challenge.

✅ Payment happens autonomously since everything is already defined.

The fiat method in MPP

This is slightly different, since this doesn’t really require a pre-funded wallet. The key differences are, that there is no wallet created, just the agent has the payment credential linked. And, this is done using the SPT: so, in the crypto method, the Payment Intent is created before the 402 response code is sent, and in the fiat method, the payment intent is created after the 402 response code is sent.

So, breaking this down into the same user flow:

User flow (Client)

1. Firstly, whatever agent the user is using needs to be onboarded on Stripe

2. Then, the agent needs a Stripe-linked payment method. This means:

   1. A Stripe Customer exists (cus_123)

   2. A PaymentMethod is attached (card_tok_ABC) to the agent. This is done via Stripe Elements or API, where the payment method is created, attached to the customer, and then the customer ID and the payment method is stored in the agent configurations, so it knows that this is a payment method it could use.

   3. This is the “card credential linking” step - done once by the user

3. This is Key difference from crypto: There’s no “agent wallet” in the crypto sense. The agent just has a reference to a Stripe customer + payment method. The money stays in your bank/card.

Server (merchant side)

1. Server (Merchant) Side:

   1. Sign up on Stripe (this would be the standard flow - there is no need to enable stablecoins), and install mppx library

   2. Configure server (Define paid endpoints (i.e. which endpoints does the agent need to pay to access, set the price, set the Stripe Shared Payment Token method: accepted payment methods (card, Link), and provide their Stripe secret key to set this up

Payment flow

So, since this is fiat, this is a little different. It’s not as simple as the agent already having policies set up to pay. Instead, when the 402 status code is sent back (with the challenge, and the methods that the merchant server accepts, which could include both crypto and fiat), and the agent has the fiat method enabled, it uses the stored customer ID, credential, and calls Stripe API to create a Shared Payment Token (SPT). This is what is sent to the Server as a response to the 402 code.

The merchant server then sends the SPT (amount, customer ID) to Stripe. Stripe checks the details against the SPT that was created by the user’s agent (which should be the same). It verifies that everything is fine, and then the mppx library and Stripe create a payment intent for and then charge the card.

✅ TLDR: The onboarding steps on Stripe are similar. What is different is that for the crypto method, the merchant server is creating the payment intent, and sending back the deposit address along with the 402 response code. The open question I have here is what if both the methods are enabled by the merchant, and how will the merchant know in advance if the user will pay by crypto? I’d look at this the other way, and say that the mppx library probably enables the merchant server to send back the 402 response code, and ALL the options that the merchant has enabled, even if it doesn’t know what the user has. It’s on the user’s agent to pick what works best for them.

✅ Both need to install the MPP library, so that the request / response structures are defined - each party knows what to do

✅ Both need to set up: the user needs to set up a wallet and fund with stablecoins. The merchant server needs to define endpoints, methods enabled, and generate the server secret key to sign the challenge.

✅ Payment happens autonomously since everything is already defined.

A point to note here is that Stripe is the central authority here. Everything is done by calling Stripe to create a payment intent, create a SPT, and verify money movement. Stripe is taking the responsibility of being that central authority through which every transaction passes, and running their own risk / fraud checks basis that.

So that’s MPP. So then what is x402 by Coinbase? How does it work?

x402 is a payment protocol for machine payments, that was created by Coinbase in May 2025. It’s now reportedly maintained by the x402 foundation, which is co-founded by Coinbase, Cloudflare, Google & Visa, which joined later. It uses the same HTTP 402 status code.

Current scale: 75M+ transactions, $24M+ volume, 94K buyers, 22K sellers in last 30 days. So this isn’t insignificant. It’s still a blip in the ocean sure (reports suggest that global volumes are 9.8B digital payments a day), but this shows potential.

The two major differences between x402 and MPP is: in MPP, Stripe is the only verifying entity. In 402, Coinbase is the default, but there are multiple. And the second: x402 ONLY supports stablecoins, not fiat, unlike MPP, which supports both

From what I could gather (and of course, this is basis my reading and interpretation), x402 doesn’t really require onboarding on anything. Stripe and MPP for example requires onboarding because it is the central authority, and you are calling Stripe APIs.

👉 So like you install the mppx library, here, both parties need to install the x402 library (which is a line of code that probably goes like import x402). There is no central entity that entities need to onboard on.

👉 The payment initiator needs to create a wallet, fund it (on ramp), and link that wallet to the agent, and give their private key, along with policy set up, so that when the HTTP 402 response is sent, the agent can handle the response using the x402 library, and use the wallet to send over the payment credential

Now, this is where the difference in MPP and x402 comes in: there is a 3rd party Facilitator that enables wallet to wallet transfer - doesn’t require any onboarding like Stripe

In MPP, if its crypto, then the merchant server calls Stripe APIs to return back the “crypto method” and the “merchant deposit address.” If it is fiat, then the agent calls Stripe APIs to create a SPT, and share with the merchant. In both cases, Stripe is being called in the middle.

In x402, none of that is happening. When the agent calls the paid endpoint, if the merchant has the x402 library is enabled, then the x402 protocols are called, and along with the HTTP 402 reponse code, the merchant deposit address is sent.

👉 Now, here: the x402 library in the agent code reads the response code, SIGNs an authorization, and sends that back to the merchant server. The x402 library in the merchant server calls the Facilitator (which is Coinbase), which connects to the blockchain, sends details, and ‘facilitates’ the transfer. While MPP currently just supports Tempo (blockchain incubated by Stripe), x402 supports 10+ blockchains, including Base, Solana, Polygon, Ethereum and so on.

So, in MPP Stripe handles everything. It gives the library, gives its APIs to create the intent or the SPT, monitors the blockchain for fund transfer completion, and / or charges the customer card

Compare that to the flow we just walked through. x402 is a decentralized service. You just need a line of code to enable it (along with your wallet set up, on ramp and so on). The merchant needs to choose a “Facilitator” that communicates with the blockchain.

Now, x402 has seen scale (150M+ transactions), but it has been around for a year. MPP has just launched. The problem I have always had with blockchain transfers is the lack of regulation, dispute management, and a central authority who is actually imposing fraud and risk controls. That is being solved by MPP. So even though there is an “extra” entity here, and an extra step of onboarding / KYC etc, to create a Stripe account, and enable it - my view is, when you’re moving money, it is okay if there are a few extra steps. Friction is a feature here.

HTTP 402 is just a way to send back a payment requirement, and then require the agent to show proof of payment

This is not a situation where you can ONLY pay on the go. All it requires at its core, across protocols (MPP, x402), is just a way to prove that you’ve done the payment, or the payment is authorized. How to check it, or broadcast details, or facilitate fund movement (in the case of x402) is something taken care of by the installed protocol library. The agent just needs to show a payment credential, or an authorization. That can be pay per use, some sort of token received when the bundle was paid for (ex: enterprises may pay for 10,000 API calls upfront), or even a subscription token if its a subscribed service.

The direction is clear: stablecoins are where payments are headed - cross-border and agentic, human and machine. The market moves tell the story:

Stripe acquires Bridge ($1.1B, 2024), Privy (wallet-as-a-service), and incubates Tempo (blockchain + Paradigm-backed). It then launched ACP, SPT, MPP (2025-2026): Signal: Three protocols in 18 months - agentic commerce, shared payment tokens, machine payments, built on stablecoin rails, stablecoin wallets, and a purpose built chain for agent payments.

Meanwhile, Mastercard acquired BVNK ($1.8B, 2026). A Card network paying a billion dollar price for stablecoin rail, while Visa partners with Bridge + stablecoin-backed cards. The other card network hedging the same way. And OpenFX raised $94M (March 2026). This is a massive round for stablecoin-settled FX - keeps local fiat pools, settles books on chain with its local entities. This isn’t speculation anymore. The largest payment companies in the world are spending billions to position for a stablecoin-native future.

But here’s the honest assessment: we’re at the POC stage. Conviction is there. The product flows work. Stakeholders buy the concept. What we don’t yet know is which flows win.

Will it be MPP or x402 or AP2? Fiat-first with stablecoin settlement (OpenFX model) or crypto native end to end (Coinbase model)? Will agents pay on-chain per-transaction, or batch-settle through intermediaries? The infrastructure is being built in parallel by players who are each betting on different architectures. When the dust settles, some of these protocols and flows will be the standard, and some will be footnotes.

That’s the nature of a POC-stage market with trillion-dollar potential: the destination is visible, but the winning route isn’t.