Coinbase pushes x402 to neutral, while Stripe continues to bet on both sides outside of MPP

Author: Charlie, Head of OSL Americas, Venture Partner @ Generative Ventures. Former Vice President at cryptocurrency unicorn Strike (involved in the El Salvador Bitcoin law and responsible for Latin America's Bitcoin Lightning Network and stablecoin payment business), macro and currency analyst at trillion-dollar fund Franklin Templeton, and an early member of global payment giant Adyen.

The article reflects the author's personal views and does not represent the positions of the related companies.

Recently, more and more friends have been paying attention to agentic commerce, but the various protocols and players have become increasingly confusing.

Especially last week, while everyone was busy understanding Stripe / Tempo's MPP, Stripe unexpectedly joined competitor Coinbase's x402 Foundation.

Moreover, Cloudflare now supports both systems. Google is also involved, but it has its own AP2 and UCP.

Visa and Mastercard have also joined, but they are clearly not there to support stablecoins.

The Linux Foundation publicly defines x402 as a neutral, industry co-governed "base camp," while Cloudflare has explicitly included both x402 and MPP in its own Agents SDK, and Stripe has also publicly stated that it supports both MPP and x402.

Who is competing with whom, and who is overlapping with whom?

However, the more I look at it these days, the more I feel that this "chaos" is not because the market lacks direction, but because the market is already very clear. As I mentioned before in x402, we might have misunderstood its original intention: from day one, this matter would not be unified by a single protocol all at once.

It resembles a common situation in internet infrastructure—different layers are developing simultaneously, different companies are betting on different layers, and ultimately, interoperability will get the whole thing running.

The real strategic story is about who will define the default control layer for paid machine access on the agentic web; and key players are clearly multi-homing, as everyone is still betting on where the true bottleneck will fall—authorization, distribution, or settlement.

1. Why did Coinbase hand over the x402 Foundation to Linux?

If x402 were just Coinbase's protocol, it would be hard to become the industry default option.

This is not a politically correct statement, but rather a realistic standardization logic.

The Linux Foundation's statement this time is very clear; it emphasizes service provider neutrality, community governance, and shared infrastructure, rather than "a certain company has released a new product feature."

More crucially, the x402 Foundation page currently states that the project is in the establishment phase, and the governance mechanism and board are still being built.

In other words, this action is not primarily announcing "the product is mature," but rather announcing "we want to give this protocol a neutral home."

The underlying implication is quite simple.

If x402 continues to bear the face of a Coinbase product feature (like the current Base), then cloud vendors, payment companies, card organizations, and platform players, even if technically willing to adopt it, will hesitate politically.

No one wants to hand over the future paid access layer to a single platform. Placing it under the Linux Foundation is not because Coinbase does not want to control it; rather, it is precisely because it wants x402 to be widely adopted that it must first remove the burden of "this is Coinbase's protocol."

This point is actually very important because many people view actions like those of the foundation as merely PR or open-source gestures.

But in the protocol war, governance is part of the product.

Especially when a standard is still in its early stages and lacks absolute network effects, the so-called "neutral and trustworthy" is not less important than technical elegance.

Conversely, if x402 can indeed become some kind of HTTP-native paid access baseline in the future, it is likely not because its code is the most beautiful, but because it has lowered political costs earlier than other solutions.

In other words, governance here is not a supporting role; governance itself is a growth engine.

2. What is Stripe's dual strategy really doing?

The player to watch this time is definitely Stripe, as its actions are the most confusing.

On one hand, it launched MPP with great fanfare on March 18, packaging it as an open standard for machine payments.

On the other hand, it is a founding contributor to the x402 Foundation and its own documentation also supports x402 machine payments.

Cloudflare's documentation is even more direct, explicitly stating that MPP is backward-compatible with the core payment process of x402, and MPP clients can directly consume existing x402 services.

If viewed solely through the lens of "protocol competition," Stripe seems to be engaging in a dual strategy.

But if you elevate your perspective a bit, this approach actually makes the most commercial sense.

Because what Stripe really wants to protect is not just the 402 handshake itself.

What it truly wants to safeguard are the layers above the handshake: credentials, compliance, risk, reporting, tax, refunds, merchant integration.

Stripe does not appear to be a true believer in any single protocol; rather, it seems to be ensuring that regardless of which handshake standard ultimately prevails, Stripe remains the default abstraction layer for agent payments.

Supporting x402 is to ensure participation in the open ecosystem; pushing MPP is to help define the underlying semantics; and further promoting ACP and Shared Payment Tokens is to safeguard the thicker value layer of workflows and payment credentials.

Thus, the most "strange" aspect of Stripe this time is actually its most honest aspect.

It does not pretend that the future will quickly reduce to a single protocol. It is taking action to tell you: at least at this stage, no one should bet on just one side.

3. This is actually a B2B infrastructure story

I increasingly feel that many media outlets have misfocused the spotlight on this matter.

When it comes to agent payments, the easiest thing to think of is retail: AI helping you book flights, reserve hotels, place orders, and go through checkout.

But if you look at the scenarios that have truly been publicly implemented and really have an infrastructure flavor, the first to take off is not retail checkout, but rather the more mundane and real B2B paid access: paid APIs, paid data, paid tools, paid browser sessions, paid agent workflows.

Cloudflare now openly supports charging for HTTP content, APIs, and MCP tools using x402 and MPP.

The strongest adoption path for x402 lies in developer-to-developer paid APIs and tools, because "no account + pay-per-request" here is not just a gimmick, but a genuinely operational reality.

The changes behind this are quite significant.

In the past, charging for an API typically required going through a whole set of "human-friendly" processes: opening an account, linking billing, issuing API keys, setting limits, reconciling, and then handling payment permissions.

For humans, this is already quite annoying; for agents, it is even more awkward.

The most attractive aspect of x402 is not that it is more crypto or more AI, but that it attempts to reinsert "paid access" back into HTTP itself, allowing access control and payment negotiation to occur like a normal request-response.

The server returns a 402, telling you how much this request costs; the client pays, then retries the same request with the payment credential.

If you view this model from the perspective of B2B software and machine-to-machine access, it flows much more smoothly than from a retail perspective.

Moreover, the closer you look towards B2B, the more obvious x402's advantages become, and its shortcomings are less fatal.

Because in consumer commerce, refunds, chargebacks, merchant-of-record, consumer protection, and liability attribution are all hard issues; but in B2B API and tool calls, the importance of these issues significantly decreases.

Conversely, "no account, pay-per-call, get results and go" is a real demand.

Retail is certainly larger, more vibrant, and easier to attract attention; but the scenarios that truly define what the protocol looks like are often not the most vibrant ones, but those that first expose real needs.

For today's wave of agent payments, that scenario is likely not the shopping cart, but the increasing number of paid access between software, agents, and workflows.

4. Industry development validates my previous judgment on interoperability

The core judgment in my last article was interoperability.

At that time, this judgment sounded somewhat like "it should be structured this way."

Now, it increasingly resembles a reality constraint, as the open market is already voting with its feet.

Cloudflare did not choose a side but directly supports both x402 and MPP while clearly making compatibility mappings.

Google is participating in x402 while continuing to advance AP2 and UCP.

Visa and Mastercard have also not expressed their strategies in an "all-in-one winner" manner; instead, they are both joining x402 while continuing to double down on agent tokens, identity verification, instruction validation, and dispute signals.

The multilateral bets by the giants are rational decisions, not commercial hypocrisy.

Why is this the case? Because these protocols are not even on the same layer.

At least so far, x402 and MPP are closer to the paid HTTP handshake layer, addressing the question of "how to ensure requests come back with payment capability."

AP2 is closer to authorization and trusted intent, addressing the question of "does this agent have the right to spend this money?"

UCP and ACP are more like the workflow layer, dealing with discovery, checkout, merchant relationships, and credential transmission—issues that are closer to "who controls traffic and transaction orchestration."

Many companies supporting x402, MPP, AP2, and UCP simultaneously are not because they themselves are unclear, but because the architecture that wins in the end is likely to span multiple layers and may even require multiple protocols to form together.

So if I were to reflect on my previous judgment in one sentence, I now believe even more strongly that without interoperability, this wave of ecology would not have emerged at all.

Looking at it now, the market is actively validating this judgment.

Furthermore, this judgment is also important for B2B vs retail.

Because in the retail world, it may indeed end up being absorbed by a few large platforms and a few major workflows; but the B2B world is not like that.

Businesses inherently exist in a reality where multi-cloud, multiple payment methods, multiple workflow systems, and multiple identity permission systems coexist.

Anyone trying to use a new protocol to completely overhaul the entire enterprise stack is likely to fail first.

What B2B customers are truly willing to pay for is often not "the one correct protocol," but the ability to make existing systems work in a multi-protocol environment.

This logic is precisely why interoperability is more critical in enterprise scenarios than in consumer scenarios.

5. This is not merely protocol competition, but layered stack competition

Once you understand this matter as a layered stack, many phenomena that originally seemed chaotic will immediately make sense.

At the bottom layer is the paid access handshake.

This layer concerns how HTTP requests express "payment is required here," and how the client brings back the payment credential after paying.

x402 and MPP are primarily competing here. MPP is trying to formalize 402 into more official HTTP auth semantics; while x402 is more about platformizing 402, using custom headers, facilitators, on-chain settlement abstractions, and ecosystem integration to get it running first.

One is more like a standardized semantic route, while the other resembles a platform distribution route.

The next layer up is the authority to spend, which is "who authorized this money."

This layer is the key that many people have not fully realized yet.

Machines paying money is not that difficult; the real challenge is ensuring that machines can be trusted to be authorized to spend money.

AP2 is important precisely because it addresses not just "how to pay," but also mandates, verifiable credentials, authenticity, and accountability.

The agent tokens, instruction validation, passkeys, and dispute signals that Visa and Mastercard have recently doubled down on essentially all fall under this layer.

The next layer up is workflow and distribution.

This includes discovery, checkout, merchant relationships, credential sharing, and AI surface integration—issues that are closer to "who controls traffic and transaction orchestration."

UCP and ACP are more like competing for this layer.

For B2B, this layer may not be as lively in the short term, but its long-term value could be very high.

Because if more and more enterprise software is coordinated, called, procured, and paid for by agents in the future, then whoever masters the workflow language is not just managing a single payment but the entire workflow.

Once you separate these three layers, you will discover a very simple fact: there is no need to expect a single protocol to cover all issues.

A more realistic path is for these three layers to develop separately and then gradually interoperate.

For this reason, multi-headed betting is not indecisiveness but rationality.

6. The real risk of x402 may not be regulation, but the economics of concurrency

If we only recognize "the coexistence of multiple protocols," it is still not deep enough.

The biggest risk for x402 may not primarily be regulation, but rather the time-of-check/time-of-use economics brought about by the two-step verification-settlement process.

Simply put, if verification of payment and final settlement are not the same thing, then in real internet environments characterized by high concurrency, retries, proxy layers, and caching layers, there will be a window for "pay once, access multiple times."

The x402 ecosystem is currently also patching holes, such as settlement cache, idempotency extension, and payment identifier, but this precisely indicates that the issue is not merely theoretical.

Why is this particularly worth noting for B2B readers?

Because what the B2B world fears most is not the inability to produce a beautiful demo, but rather that there are too many edge cases, and once it goes into production, it starts to leak.

API monetization may superficially seem like paying a few cents per request, which is quite light; but once your product charges per call, per result, or per workflow, then whether "pay once get one" or "pay once get many" is not just a product detail but a matter of life and death.

So if x402 can indeed take off in B2B, an important prerequisite is not the narrative but that these default-safe mechanisms must be made sufficiently brainless; otherwise, enterprises will not feel secure bringing real traffic in.

7. Protocols may be free, but toll booths will not disappear

There is one more point that I think is worth elaborating on in this article.

Many open protocols ultimately arrive at a very familiar place: the protocol itself becomes increasingly cheap, even free, but real toll booths will grow up alongside it.

x402 is no different.

The standard itself certainly emphasizes openness, neutrality, and 0 fees built into the standard, but this does not mean that value capture will disappear.

If x402 succeeds, value will not primarily remain within the protocol but will migrate to facilitators, wallets, key management, discovery, policy engines, and trust wrappers—these adjacent layers.

This is especially important for B2B.

Because enterprise customers will not massively overhaul their entire systems for a new protocol; what they are truly willing to pay for is who can help them tidy up orchestration, policy, risk, compliance, audit, settlement, and permission boundaries in a multi-protocol environment.

In other words, protocols will increasingly resemble underlying languages, but the ability to translate these languages into "enterprise-ready" capabilities will more easily become new platforms and new toll booths.

This is also why I feel that when looking at x402 today, we should not just focus on who among Coinbase, Cloudflare, or Stripe is more like the "protagonist."

What is truly worth watching is who has the best opportunity to stand on these adjacent layers.

Cloudflare has a position in edge and traffic distribution, Stripe has a position in payment infrastructure and merchant relationships, Visa and Mastercard have positions in credentials, network tokens, and consumer trust, and Google has a position in workflow and discovery surfaces.

Real value capture may not occur in "who defined 402," but rather in "who integrated 402 into larger enterprise systems."

8. Conclusion

The x402 Foundation is not announcing that x402 has already won in all agentic commerce protocols.

It is publicly acknowledging that this generation of agent payments will not be a single protocol world from day one.

Coinbase handing x402 over to the Linux Foundation is to make it more like a neutral public layer rather than an exclusive product.

Stripe pushing MPP while joining x402 is not indecisiveness; it is because it knows that one should not bet on just one side right now.

Cloudflare supporting both systems simultaneously is because it is closest to real traffic.

The actions of players like Google, Visa, Mastercard, and Adyen also indicate the same thing: first, let the systems interoperate, then discuss who ultimately occupies which layer.

And if we shift our perspective away from retail, this judgment becomes even clearer.

Because the first to need these protocols may not be the shopping cart, but rather the increasing number of B2B software and services that charge per call, task, or result.

Retail is certainly larger, but B2B often exposes real needs earlier and defines what the infrastructure ultimately looks like sooner.

In my last article, I placed interoperability at the center, and I believe the market's answer is now quite clear: yes, and even earlier than I thought at the time.

In this sense, the x402 Foundation is not the end of this story.

It simply allows us to see earlier that the real theme has never been "who will win," but rather "this world is destined to interoperate first, and who can occupy the most valuable layer after interoperability."