Table of Contents
Researcher
Source: Cloudflare Blog
On July 1, Cloudflare announced Monetization Gateway.
Cloudflare is one of the companies most committed to agentic payments. In September 2025, it co-founded the x402 Foundation with Coinbase, which is now under the Linux Foundation. The Pay-Per-Crawl model released with the foundation showed the expansion potential of the x402-based agentic web.
Source: Cloudflare Blog
For more on the Pay-Per-Crawl model, see “Cloudflare and x402: The Future of the Agent Web.”
This raises a rather aggressive question.
Is this a crypto product for crypto’s sake, with product-market fit forced onto it? Did Cloudflare create a problem for the product, rather than make a product to solve a problem?
This is a fair question from the perspective of people accustomed to a web built for humans. The web works without much friction today, and agents reading or crawling content does not feel like a real problem yet.
So let’s look at why Monetization Gateway, and by extension the agentic web, may be adopted in the future.
Why the monetization gateway is needed: Bots are not intruders
Today, we use websites without much difficulty. When bots crawl or access sites without permission, operators often use a web application firewall (WAF) to prevent server overload and data theft.
Source: Rackspace
At the center of these firewalls and bot management systems is Cloudflare, a global company that handles about 20% of web traffic worldwide. With its large traffic dataset, Cloudflare has been able to distinguish humans from bots quickly and accurately, while protecting both website operators and users from cyber threats. In this structure, bots were always treated as intruders to be blocked.
But bots are no longer intruders. They are the web’s new users. The main actor here is the full set of automated requests that AI sends to the web, referred to below as AI bots. AI bots can be divided into two categories:
- Crawlers: They collect content in advance and at scale without a human request, mainly for training and indexing.
- Agents: They access only the pages needed at the moment a specific user gives an instruction.
This distinction matters. Agents are customers worth serving, but they are being treated as troublemakers because of the problems created by crawlers.
First, we need to understand referral, which has been central to the web’s revenue structure. For 30 years, the web’s revenue model has been based on human visits, and referrals have been the pipeline that supplied those visits. A referral means one actual visit to a site through a search result or a link from another site.
For example, when a user clicks a link in Google search results or in an AI assistant’s answer, the browser arrives at the site with a Referer header that shows where the user came from.
Ad impressions, subscription conversions, and similar events happen on top of that visit. From the site’s perspective, this is practically the only case in which revenue is generated. For this reason, before AI bots became widespread, allowing crawls during the search era was an investment rather than a cost. If a site allowed a few pages to be crawled, it could receive a referral in return.
AI bots have broken this exchange formula. They do not view ads, they do not maintain subscriptions, and most of all, they do not send referrals back.
Source: SEOmator
Current statistics show this clearly:
- Automated traffic at 57.5%: Machine traffic has exceeded half of all traffic for the first time in internet history.
- Crawled pages per referral: Google 5 vs. GPTBot 1,276 vs. ClaudeBot 23,951.
- 53.3% of AI bot requests are training crawlers: There is no path for them to generate referrals.
- Agents are still at 2.6%: They are the fastest-growing category, with 15x growth in one year and a 393% increase in U.S. retail traffic from AI.
In short, a site makes money only when a person visits a page. Ad impressions and subscription conversions both depend on the event of a visit. But AI bots are not visitors. They extract content at the moment of request, and the person often gets what they need from the AI assistant’s answer without visiting the original site. From the site’s perspective, requests accumulate while revenue events disappear and serving costs remain.
Blocking all AI bots is not the answer either. If a site blocks training crawlers, it may also block the fast-growing demand from agents shown in the numbers above. Behind each agent is a user with real demand. Advertising and subscriptions do not work for this buyer. The only unit that can be charged is the request itself, and the web has not had a payment method for that unit until now. In a sense, an agent is closer to a customer who walked into a store with no checkout counter than to a free rider.
Strictly speaking, we do not even know whether this customer had any willingness to pay. There was no price tag and no checkout counter, so no one had ever asked for payment in the first place. The frustrated party is the clerk. The clerk wanted to charge but had no way to do so. As a workaround, the clerk defined the customer as a thief and locked the door, even though the customer might have made an actual purchase.
If agents become the main users of the web, why should the web’s revenue structure remain the same? Monetization Gateway can be understood as an answer to that question.
How the monetization gateway works
Source: Cloudflare Blog
The numbered steps in the diagram show the overall flow. (1) An agent requests a resource. (2) The gateway returns a 402 code with the price, payment asset, and wallet address. (3) The agent approves the payment from its wallet and sends the request again. (4) Once the payment proof is verified, (5) only the “verifiably paid request” is delivered to the origin.
Origin: The seller’s actual server behind Cloudflare.
The notable point is that the origin is involved only in step (5). Price disclosure, payment, and verification are all completed at the edge. The origin never touches payment traffic and receives only requests that have already been paid for. For sellers, adding a payment system has usually meant building billing, connecting a payment gateway, and managing settlement. With this service, they only need to write rules through a dashboard, API, or Terraform. That is a clear UX improvement.
The announcement also introduced three example functions:
- Charging for specific actions: Charge only GET or POST requests to selected API paths.
- Variable pricing: Charge different fees based on task complexity or compute usage.
- Charging unauthenticated users: Return a 402 (Payment Required) code instead of a 401 (Unauthorized) error when an unregistered external agent accesses the service, so revenue can be collected immediately.
Now imagine how these functions might be used. For a media site behind Cloudflare, the available options against AI crawlers have so far been robots.txt and bot blocking. In other words, allow or block. After Monetization Gateway, this binary choice becomes a price list by agent. A search bot that sends traffic back can pass for free. A training crawler can be charged $0.005 per page. A bot whose identity is not verified through Web Bot Auth can be blocked entirely or charged a premium price. The key point is that the same content can have different prices depending on who requests it.
On the buyer side, all of this runs automatically. The agent compares the price received through the 402 response with its own spending policy, such as automatic approval for transactions below $0.05, then pays and receives the resource. The whole process ends within seconds without human involvement, and there is no onboarding process such as account issuance.
Source: Cloudflare Blog
The dashboard example released with the announcement makes this easier to understand.
The image generation API is priced at $2.00 per request, and the news article path is priced at $0.001 per request. These are price levels that legacy card rails could not structurally support, but they can be configured with a few simple rules.
The condition attached to the second rule, “when auth header is missing,” is the actual implementation of charging unauthenticated users described earlier.
The Non-monetized endpoints section at the bottom is also worth attention. Cloudflare observes traffic and even suggests endpoints that can be monetized. Since it sees all traffic from the proxy position, it can also see what may be sold.
So why x402?
Why x402? Of course, we cannot ignore that Cloudflare led the creation of the x402 Foundation. But from a functional perspective, no other protocol meets the requirements of machine payments to this degree.
- Open source base: Anyone can implement it and contribute to specification extensions.
- Micropayments: Very small payments can be supported.
- No separate account registration: The payment itself acts as a credential.
- Payment rail flexibility, or rail-agnostic design: It can accept stablecoins and other rails such as card networks.
I also see governance as a meaningful point.
In April 2026, x402 officially launched under the Linux Foundation as a neutral standard with 22 founding member organizations. AWS also integrated x402 into CloudFront in June. With this announcement, the world’s two largest edge networks now use the same payment handshake.
For agents, which cannot implement a different payment API for each site, a single handshake that works across the web is a prerequisite for adoption. The less that standard belongs to a specific company, the less friction it creates.
The functions required for agent payments will keep changing as the market changes. In such a volatile market, x402 has an edge because it is open source and has kept evolving through many specifications.
P.S. If OUSD (Open USD) is added
Source: Cloudflare Blog
One point stood out while reading the blog. Cloudflare explicitly listed Open USD alongside USDC as an example payment asset. Open USD is a consortium stablecoin announced on June 30 by more than 140 companies, only one day earlier, and Cloudflare is also part of the consortium. In other words, Cloudflare mentioned OUSD in an article about its new product one day after the consortium announcement.
This combination is interesting because of OUSD’s economic model. OUSD has a yield-sharing structure that distributes most reserve income to partners that drive adoption. As more payment flows created by the gateway are settled in OUSD, Cloudflare earns through reserve economics rather than transaction fees. For OUSD, Gateway becomes a native distribution surface that covers 20% of the web. For Cloudflare, OUSD becomes a mechanism that converts payment flow into revenue.
Taking one step back, the same names are appearing across the full agent payment stack: the protocol (x402), the settlement asset (OUSD), and distribution (the edge network). Monetization Gateway is the first view of this stack being assembled into a single product, almost like a super app. With OUSD added, Cloudflare would own the route through which payments flow, rather than merely intermediate payments.
Just as ancient civilizations began along rivers, wealth forms at the chokepoints of flow. In the agent economy, the river is the request, and Cloudflare already holds the river mouth.
As a practical note, the Monetization Gateway waitlist is now open to Cloudflare customers. Customers interested in monetizing a web page, dataset, API, or MCP tool with usage-based pricing can join the early access list.
The author of this report may have personal holdings or financial interests in assets or tokens discussed herein. However, the author affirms that no transactions have conducted using material non-public information obtained in the course of research or drafting. This report is intended solely for general information purposes and does not constitute legal, business, investment, or tax advice. It should not be used as a basis for making any investment decisions or as guidance for accounting, legal, or tax matters. Any references to specific assets or securities are made for informational purposes only and should not be construed as an offer, solicitation, or recommendation to invest. The opinions expressed herein are those of the author and may not reflect the views of any affiliated institutions, organizations, or individuals. The opinions and analyses expressed herein are subject to change without prior notice. In addition, beyond the individual disclosures included in each report, Four Pillars, may hold existing or prospective investments in some of the assets or protocols discussed herein. Furthermore, FP Validated, a division of Four Pillars, may already be operating as a node in certain networks or protocols discussed herein or may do so in the future. Please see below links in the footer for FP Validated's participating network disclosures and for broader disclosure details.
