x402 moves to the edge: AWS WAF, Cloudflare, and the CDN as paywall

For a year, adopting x402 meant installing something: middleware in Express, a decorator in FastAPI, a wrapper around an MCP tool. In June 2026 AWS turned it into a checkbox on a firewall rule. The paywall now lives one hop before your server, and it changes the shape of the protocol.

Two of the largest networks on the public internet now terminate HTTP 402 at their own edge. AWS announced AI traffic monetization on 15 June 2026 as a capability of WAF Bot Control, generally available with Amazon CloudFront at no additional charge beyond standard WAF pricing. Two weeks later, on 1 July, Cloudflare announced the Monetization Gateway — the same idea for anything behind its network — and opened a waitlist. On 4 August it announced Cloudflare Wallets, the buyer half of the same machine.

We covered the seller stack and the buyer stack as libraries you install and control. Edge enforcement is a different architecture with the same wire format. This is what the documentation actually says, what we could verify against the protocol repository, and what breaks.

The Monetize action, precisely

In AWS WAF, monetization is not a product surface of its own. It is a sixth action available to a rule, alongside Allow, Block, Count, Captcha and Challenge. Monetize is a terminating action: when a rule with it matches, WAF stops evaluating subsequent rules, and a request without valid payment authorization gets an HTTP 402 back at the edge.

The economics live in a MonetizationConfig attached to the web ACL, not in the rule. The getting-started guide documents the structure:

{
  "MonetizationConfig": {
    "CryptoConfig": {
      "PaymentNetworks": [
        {
          "Chain": "BASE",
          "WalletAddress": "0x1234...5678",
          "Prices": [{ "Amount": "0.001", "Currency": "USDC" }]
        },
        {
          "Chain": "SOLANA",
          "WalletAddress": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
          "Prices": [{ "Amount": "0.001", "Currency": "USDC" }]
        }
      ]
    }
  }
}

Four chains are supported: BASE and SOLANA for production, BASE_SEPOLIA and SOLANA_DEVNET when CurrencyMode is TEST. USDC only. The amount is a decimal USD string with at most three decimal places, and the floor is $0.001 per request. Per-rule variation comes from a PriceMultiplier on the rule action: base price times multiplier gives the effective price, so a rule with multiplier "3" over a "0.001" base charges $0.003.

That is the whole pricing model. One base price per chain per web ACL, scaled by integer-ish multipliers per rule. There is no notion of metered usage, no upto settlement of actual consumption, no batch accumulation — the three directions the protocol itself has been extending in, which we walked through in the upto scheme deep dive. The edge charges a fixed price for a request it has not yet made to your origin, because at the moment of the 402 it does not know what the origin will return or how expensive it was to produce.

Settlement inside the request path

The lifecycle in the how-it-works page is where the architecture diverges from every SDK deployment we have looked at.

The agent requests a monetized path. WAF matches a Monetize rule and returns a 402 carrying price in USDC, accepted networks, the publisher wallet as payTo, a maximum timeout, and the payment scheme. The client signs an authorization and resubmits the original request with a payment-signature header. WAF verifies — "this occurs synchronously in the request path", per the docs. On success the request goes to origin. If origin returns 2xx, the payment settles on-chain through Coinbase Developer Platform's x402 facilitator, and only then is the content served, with a payment-response header carrying settlement confirmation.

The reference middleware does not do this. In the seller SDKs, verify runs before the handler and settle runs after the response is produced; the seller absorbs a window in which work is done and settlement may still fail. AWS inverts the risk: the buyer absorbs the wait, and the seller is never exposed to unpaid work. That is a defensible trade for a publisher. It is a rough trade for an agent, and AWS says so in the pricing configuration page: the feature "adds several seconds of additional latency to requests that require payment processing", and "the exact latency depends on blockchain network conditions at the time of settlement".

Several seconds, for a resource priced at a tenth of a cent. The unpaid path is untouched — only requests carrying a payment signature pay the tax — but any agent loop that walks a paid edge is now doing a chain write per fetch, in-band. Cloudflare, describing an unshipped product, says it is aiming for subsecond settlement. Nobody has shown that number in production yet.

There is one piece of good design in the ordering: no payment for failed origins. If the origin answers 4xx or 5xx, settlement is skipped and the client is not charged. The settlement record for that request is logged with status SKIPPED_ORIGIN_ERROR, alongside SETTLED, PENDING, FAILED and SERVICE_ERROR. This is the fix for the oldest complaint about pay-before-you-know-what-you-get, and it only works because the edge sits between the payment and the content.

What happens when the money layer is down

Because settlement is in-band, every dependency of settlement becomes a dependency of content delivery. AWS enumerates them: temporary unavailability of the Coinbase facilitator, blockchain congestion, transient on-chain errors. In all three cases, "content is not served to the client. The client receives a response indicating the failure and can retry the request." Beyond that, AWS reserves the right to throttle "excessively high volumes of payment traffic", with the guidance to back off and retry.

Retry is doing a lot of work in that sentence. A retry after a failed settlement is a second signed authorization against a resource that may already have been paid for. The protocol's answer is the payment-identifier extension, an idempotency key echoed in the payment payload, and AWS points at it: clients "can retry requests without double-payment for up to 15 minutes, as long as the extension is used by the client".

We checked that against the source. In the x402 repository at HEAD db9dabd0 (4 August 2026), specs/extensions/payment_identifier.md defines an id of 16 to 128 characters, a behaviour table (new id, process; same id and same payload, return the cached response; same id and different payload, 409 Conflict; required: true with no id, 400), and guidance to bind each id to a normalized request fingerprint covering scheme, network, asset, amount, payTo, path and method. What it does not define is a retention window. There is no fifteen minutes in the spec, and no MUST or SHOULD anywhere in the document — resource servers and facilitators "may" use the id. The window is an AWS implementation detail described in AWS prose as though it were protocol.

The practical consequence for an agent author: idempotency is opt-in on the buyer side, its duration is per-deployment, and the same key against a different fingerprint is a 409 rather than a refund. If your client does not send an id, a retry storm during facilitator congestion is a double-spend storm. This is exactly the class of failure the facilitator trust model warned about, now with a global CDN in front of it.

The caching question nobody has answered

A CDN is a cache. That is its reason to exist. x402 responses are, by construction, the least cacheable objects on the web: a 402 is a price quote bound to a nonce, and a paid 200 carries a payment-response header describing one buyer's settlement.

So we grepped the specification. In the same checkout of the x402 repository, specs/ contains zero occurrences of Cache-Control or no-store — not in x402-specification-v2.md, not in the HTTP transport document. The normative text is silent on caching.

The implementations are not. On 30 July 2026 the same behaviour landed in three SDKs: PAYMENT_REQUIRED_CACHE_CONTROL = "no-store" in the TypeScript core and in Python (PR #2990, which also merges private into successful 200s carrying PAYMENT-RESPONSE "so shared caches cannot store user-specific settlement metadata"), and PaymentRequiredCacheControl in the Go HTTP server (PR #2956). We flagged the TypeScript and Python side of this in the 31 July roundup while the Go change was still open; it has since merged.

The gap is the interesting part. Correct caching behaviour for paid responses exists only as convergent implementation, in library code, at the origin — while the two deployments with the most reach are shared caches enforcing the protocol themselves. Neither AWS nor Cloudflare documents what its cache does with a 402 challenge or with a paid 200. AWS does document one adjacent behaviour that shows the seam: its guidance for attaching machine-readable licence terms uses a CloudFront Response Header Policy to inject a Link header, and then notes that response header policies apply to origin responses, so "the 402 Payment Required Challenge served by the Monetize action will not include this header". The challenge and the content travel different paths through the edge. Anything you reason about for one does not automatically hold for the other.

Two edges, two theories of identity

Price discrimination is the actual product here, and it requires knowing who is asking. The two edges answer that differently.

AWS answers it with Bot Control classification: over 650 bot and agent types, each labelled and sorted into a verified tier (cryptographically confirmed identity) or unverified (user-agent and behavioural matching). The recommended pattern is to gate the Monetize action behind a label match so humans are never shown a 402:

{
  "Name": "MonetizeBotTrafficOnly",
  "Priority": 5,
  "Statement": {
    "LabelMatchStatement": {
      "Scope": "LABEL",
      "Key": "awswaf:managed:aws:bot-control:bot"
    }
  },
  "Action": { "Monetize": {} }
}

That guard is necessary because, as AWS puts it, "standard web browsers and human users cannot interpret or complete this payment flow — the 402 response will effectively block access for non-automated clients". A misconfigured rule does not degrade to a paywall page. It degrades to a wall.

And the classification underneath is, in AWS's own words, "probabilistic and might not correctly identify or categorize all bot traffic in all cases". Pricing by identity on top of a probabilistic identity signal means a fraction of buyers are charged the wrong tier and a fraction of humans are charged at all. Test mode exists precisely for this: CurrencyMode: TEST runs the full flow — verification, origin fetch, settlement — on Base Sepolia and Solana Devnet with faucet funds, and tags every event and analytics query with the mode.

Cloudflare answers identity with cryptography instead: the Monetization Gateway is documented as integrating with Web Bot Auth, the HTTP message signature profile we took apart in agent identity over HTTP. A signed request is a claim you can verify rather than infer. It also raises the floor: agents that do not sign get the anonymous price, which is the same tiering AWS builds from labels, arrived at from the opposite direction.

Neither edge closes the third gap. Price is not permission. AWS says it directly — monetization "tells agents how much to pay but not what they're allowed to do with the content" — and points at RSL, Really Simple Licensing, discoverable via robots.txt, a Link header, an HTML link rel="license", or an RSS module. The agent that pays a tenth of a cent for a page still has to fetch a separate XML document to learn whether it may train on it, and, per the note above, the 402 it just received did not carry the pointer.

Cloudflare's other half: the buyer becomes a product

The Monetization Gateway is a seller product with a broader surface than AWS's: charge for "web pages, datasets, APIs, or MCP tools", with rules written as expressions in the dashboard, API or Terraform, enforced across 330+ cities. The examples go past flat per-request pricing — a cent per GET to a premium path, variable amounts up to $2, a base fee plus a per-megabyte charge for uploads — and one pattern stands out: intercepting a 401 and requiring payment instead. That is the walk-up conversion we mapped in bearer versus x402, turned into an edge rule. Settlement is in stablecoins, Open USD and USDC.

Then, on 4 August, the other half. Cloudflare Wallets splits into Account Wallets, "designed for humans who are owners and users of Cloudflare accounts", which hold funds and delegate spend, and Virtual Wallets, "designed for agents", which "operate via API keys" and spend within permissions set by the account owner. The guardrails named are an allowance, an allow list and a maximum transaction size, with anomaly detection escalating to human review. Identity gets a human-readable form: Web Bot Auth "already allows agents to register their identity via a keypair", and a wallet handle like research.example.cloudflare.pay makes that keypair addressable. Handles are claimable now; paying with them is "soon".

Read the guardrail list again — allowance, allow list, transaction ceiling. It is the same triple as ERC-7715 execution permissions, Coinbase Spend Permissions, ACP's allowance object and the upto scheme's ceiling, which we traced through account abstraction for agent wallets. The industry has converged on the shape of a spend mandate. What differs is custody, and the announcement does not say who holds the keys behind a Virtual Wallet, nor which chains or assets it settles on. An agent that spends through an API key against a balance a platform manages is not doing non-custodial settlement, whatever the wire protocol underneath. x402's founding property was that the payment is the credential and no account with the seller is required. A wallet you log into with an API key reintroduces exactly one account — with the edge.

What it means for LLM4Agents

Three effects, in order of how soon they bite.

First, we are a buyer now, whether we planned to be or not. Documentation, data feeds and MCP tools that our agents fetch are moving behind edges that answer 402. Our outbound HTTP path has to treat a 402 as a normal, budgeted branch: parse the requirements, check the price against a per-domain ceiling, sign, retry, record the receipt. Two details are non-negotiable given what we read. Send a payment-identifier on every paid request — it is opt-in, the seller's retention window is undocumented and deployment-specific, and without it a facilitator outage turns retries into duplicate payments. And budget the latency: an edge that settles in-band can hold a request open for seconds, so paid fetches need their own timeout class, separate from ordinary tool calls, or one paywalled URL stalls a whole agent loop.

Second, our own billing model is the opposite one, and that is the right side to be on. The gateway reserves against a balance, proxies the model call, then settles what was actually consumed — the reserve, proxy, settle cycle. The edge charges a fixed price before it knows what the origin will produce, which is fine for a static article and wrong for an LLM completion whose cost depends on tokens generated. Nobody bills inference correctly with a flat per-request price at a firewall. The place where the edge model is genuinely better is its origin-error rule: no settlement on 4xx/5xx. We should hold ourselves to the same standard and make it explicit — an upstream failure settles nothing.

Third, identity at the edge becomes a cost input. Both networks price by who is asking. On AWS that is a probabilistic label; on Cloudflare it is a Web Bot Auth signature. If our egress traffic is unsigned and unclassified, it lands in the unverified tier by default and pays the highest price on every edge that discriminates. Signing outbound requests stops being a reputation project and becomes a line item.

Staying on the frontier

Concrete, ordered by leverage.

1. Ship the buyer-side idempotency key. Generate a pay_-prefixed id per logical outbound operation, bind it to the request fingerprint the spec describes (scheme, network, asset, amount, payTo, path, method), and reuse it across every retry of that operation. Handle 409 Conflict as a bug in our own fingerprinting, not as a payment failure.

2. Give paid fetches their own timeout and budget class. A per-domain price ceiling, a per-run spend cap, and a timeout that tolerates in-band settlement without letting it block the agent's other work. Log every 402 we accept and every one we decline on price — declining is a valid outcome and should be visible.

3. Sign our egress. Adopt Web Bot Auth for the gateway's outbound requests: an Ed25519 key, a JWKS at /.well-known/http-message-signatures-directory, Signature-Agent on every fetch. This qualifies us for verified pricing tiers on the edges that offer them and gives the sellers we buy from something better than a user-agent string.

4. Enforce cache discipline on both sides. Our own responses that carry payment metadata get no-store on the 402 and private on the paid 200, matching what the SDKs converged on in July, and no proxy of ours caches either. This is worth writing down as a rule precisely because the specification does not say it.

5. Run testnet parity in CI. AWS's test mode exists because the failure modes are configuration failures. The equivalent for us is an integration test that exercises the full paid path against Base Sepolia and Solana Devnet on every change to the payment code — the same discipline we applied to tool evaluation in CI.

6. Publish machine-readable terms. An RSL licence document for anything we expose, referenced from robots.txt and a Link header. It costs an afternoon, and it is the difference between a price and a contract.

7. Treat custodial wallets as a funding rail, not an execution rail. If Virtual Wallets or an equivalent become the easy way to fund an agent, use them at the boundary — top up, then execute non-custodially with keys we hold. The moment an API key can move funds, the security model is the platform's, not ours.

The edge did not change the protocol. It changed who runs it, and it moved the enforcement point to the one place on the internet whose job is to answer before the origin does. That is convenient for publishers and expensive, in latency and in identity, for the agents doing the buying. Building the buyer that handles it well is the more interesting half.