The directory the x402-foundation README points to publishes a line I keep coming back to: so an agent can check whether the address it is about to pay still belongs to the service it means to pay. Good advice. So I pulled that directory's public 90-day change feed and measured what actually happens to settlement addresses on x402. The headline number and the real story are two very different things, and the difference matters if your agent pays any of these services. What's in the feed Ninety days, 630 listed services (their daily-updated llms.txt, as of 09-06), 8,000+ recorded changes: 6,183 schema changes — quiet background noise, endpoints reshuffling their payloads 747 price changes 1,077 settlement-address (payTo) changes — the trust-critical kind Read "1,077" in isolation and x402 looks like a place where services swap their settlement wallet roughly 12 times a day, across the whole directory. That's the number you'd expect people to quote. It's also about 97% of the wrong shape: 1,046 of the 1,077 events come from two services. Two metronomes 964 of the 1,077 address changes come from a single service: Tavily Search. Not gradually — in a burst: July 24, 14:45 UTC to August 4, 07:48 UTC, 257 hours, one brand-new payTo address every 16 minutes — the median gap, to two decimals, is exactly 16.00. 964 distinct addresses. Each one used for exactly one rotation window, then swapped. None ever reused. A second service (altahub-vivarium) ran the same pattern on a smaller scale: 82 rotations over ~22 hours, median gap again 16.00 minutes. Two services, one rhythm. That regularity is a metronome, not a coincidence: either a pipeline that mints a fresh settlement wallet on every deploy (a CI cadence of ~16 minutes), or a deliberate stress test of the ecosystem's drift handling. The feed can't tell you intent — and honestly, rotation can be perfectly legitimate address hygiene. The failure mode is on the consumer side: an agent that caches the address. What the feed can tell you: for an agent that cached the payTo from a listing, that service was settling to a different address every 16 minutes for ten straight days. The steady state (the part that matters for most services) Strip out the two burst services and 90 days of x402 settles down to 31 address changes across 22 services — a few per week, almost all one-time events. Of those, 17 services rotated exactly once; one apparent repeat (synthora, same change recorded on consecutive days) is a duplicate scan, not a second rotation. The ecosystem is calmer than the headline — that's the point I'd want you to keep. 1,068 of the 1,077 events were clean swaps: the old address removed and the new one added in the same observation. And it's not a single-chain story — the directory tags Tavily's network as aws:base, altahub's as plain Base (eip155:8453), and other rotations touch Solana and Algorand endpoints. Base-family tags (eip155:8453 + aws:base) account for 83% of the old-address snapshot rows I counted. So the honest version of the headline: 3.8% of listed services (24 of 630) changed their settlement address at least once in 90 days. Most of them did it once. Two of them did it in a blur. What this means if your agent pays x402 services Don't hardcode payTo from a listing. The discovery document exists to be re-fetched at payment time. The address in yesterday's scrape is a promise, not a fact. "I verified it yesterday" is a weak defense. Inside a burst window, an address verified at 09:00 was dead by 09:16. Verification decays at the cadence of the service's deploys. Wrong address = social recovery, not on-chain recovery. USDC sent to a stranger's wallet is still USDC — it just isn't yours anymore. Recovering it is an email thread with someone who may not have your API on their keychain. Metadata drift is constant; settlement drift is rare. 8,000 changes across 630 services in 90 days — but almost all of it is schemas and prices. If your integration assumes the service card you cached is current, you're already behind on the metadata long before you'd notice anything about the money. What a pre-payment check should actually cover The bar is low: is the token the token you expect (exact address, correct version), is the network the network you expect, is the payTo the address you expected, is the price sane? That's four comparisons before you sign a transfer. Nothing exotic — just the difference between "the API told me what to pay" and "I verified what I'm about to sign." This is the class of bug that hurts — the $0.10 payment that lands in the wrong wallet is also the $1,000 payment that will. So we built SendCheck to do exactly these checks: a free checksum pre-check (/validate), a $0.01 check of token + network + payTo (/check), and a $0.05 deep check that adds schema and example validation (/deep). No account, no API key — the x402 payment is the auth. It's a small tool, and the drift data is why it exists: sendcheck.surge.sh. Method and caveats Source: https://x402-list.com/api/v1/changes (90-day window). Their API serves the full feed — fetched 09-06, filtered to type=payto_changed, all 44 pages (25 events/page, the last page returns 2 rows), and the oldest payTo event (2026-07-24) sits comfortably inside the window, so the series is complete, not truncated. Their own llms.txt independently states the same 1,077 payTo rotations. Three caveats: Scanner-observed, not ground truth. The feed records what the directory's scanner saw in discovery documents, not what the service intended. Duplicate observations exist. One service's single address change was recorded twice, on consecutive days — the scanner re-observed an endpoint that was still changed. Burst intent is unknown. Tavily's and altahub's metronome could be deploys, a load test, or a wallet-rotation policy. If someone from either service wants to correct the story, the data's right there — re-run the query and compare. Data: x402-list.com /api/v1/changes (CC BY 4.0, creativecommons.org/licenses/by/4.0/), filtered and aggregated by me.