x402 Payee Hygiene Report, November 2026

Data as of 4 November 2026 UTC. Directory figures are from the snapshot taken on 3 November 2026 at 22:13 UTC. Inflow figures cover about 5 October to 4 November 2026.

Summary

A payee is the wallet address a seller asks buyers to pay. We looked at three things for the payees listed in the directory. Is the directory internally consistent? When a seller's own endpoint returns a payment quote, does it name the payee the directory lists? What does incoming USDC on Base look like for those payees?

The directory passed its basic consistency checks. Since 21 October, 1,906 directory-listed payees had at least one associated route return a readable quote. Of those, 1,867 (98.0%) matched at least once. This excludes cases where no readable quote was obtained and does not measure the current accuracy of the whole directory. The patterns worth a second look are a minority, and each has several possible ordinary explanations.

The directory

On 3 November 2026 the directory listed 3,322 hosts and 2,382 distinct payees. Over the seven days from 28 October, hosts grew from 2,819 to 3,322 and payees from 2,297 to 2,382.

We count hosts and payees first. Route counts are less useful. On 3 November there were 110,060 routes, and a single host accounted for about 68% of them. On 1 November the directory listed about half as many routes as the day before, and most returned the next day. Route totals move with one or two large listings, so we give them only for context.

Some basic checks came back clean on all seven days. No route lacked a payee. No route had only zero or missing prices. No EVM payee was malformed. Routes that offered only test networks were under 0.3% of routes every day.

Shared payees

On 3 November, 392 payees (16.5% of all payees) appeared on two or more hosts, and 1,899 hosts (57.2%) used at least one of them. Through the week the share of shared payees stayed between 16.2% and 16.5%, while the share of hosts using one rose from 52.4% on 28 October to 57.2%.

A shared payee is normal. Payment gateways, hosting platforms and custodial services often collect on behalf of many hosts with one address. A shared payee does not mean the hosts have the same owner. It does mean a buyer cannot tell which seller they are paying from the address alone.

Live quote check

Each day we visit about 1,200 hosts and request up to two of their listed routes, to read the payment quote (HTTP 402). We never send a payment or a payment header. If a route refuses GET with a 405, we send one POST with an empty JSON body. From 28 October to 3 November 2026 we made 12,888 route checks. A route can be checked on more than one day.

• 2,127 checks (16.5%) returned something other than a payment quote.
• 136 checks (1.1%) could not connect.
• Of 2,952 hosts that have returned a quote since 21 October, 88 (3.0%) showed a payee different from the directory on at least one day.

"No 402" is not the same as dead. Many routes need specific parameters, a login or a request body before they quote a price, and some have become free. For "dead" we use a stricter rule: three checks on three different days, each one not found, a server error or no connection. Of 1,920 routes checked on at least three days, 189 (9.8%) met that rule. We started recording this per route on 28 October, so the figure is early.

A mismatch also has more than one cause. A seller may have changed address before the directory updated, or the listing may be wrong. The quote alone does not tell us which.

The 98.0% figure in the summary covers only directory-listed payees with at least one associated route that returned a readable quote. Payees whose routes never returned one are not in it.

Payee inflow profile

For payees on Base, we read incoming USDC transfers over about 30 days to 4 November 2026. This covers 1,832 of the 1,893 Base payees in the directory. We assign a class only when a payee received USDC from at least five different sending addresses. 1,252 payees met that bar. 529 had one to four sending addresses, and 51 had no incoming USDC in the window.

The two shares below are measured by amount, on incoming USDC after leaving out transfers from identified exchange wallets, because an exchange sends on behalf of many unrelated users. Among the 1,252:

• 888 (70.9%) fall below both thresholds: no single sending address supplied 80% or more of their USDC, and round-trip flow stayed under 30%. This is a threshold result. It does not prove that the money came from many independent customers.
• 232 (18.5%) received 80% or more of their USDC from one sending address.
• 132 (10.5%) received 30% or more of their USDC from addresses that this payee had sent USDC to earlier in the window. We call this round-trip flow.

Neither pattern is a finding against a seller. One large sender can be a major customer, a platform or a payment aggregator. Round-trip flow can be refunds, transfers between a team's own wallets, revenue sharing or testing.

Inflow is not sales. We count every USDC transfer to the address, not only x402 settlements, and anyone can send USDC to any address. Across the 1,832 payees we counted about 493,000 incoming transfers worth about $1.68 million, including transfers from exchange wallets. That total is inflow, not revenue or a number of x402 purchases. Inflow is concentrated in a small number of large payees, so this report gives class shares by number of payees, not by amount.

A change of method

Until this month we measured both shares by number of transfers. We now measure them by amount, so many tiny transfers do not outweigh one large payment. The two runs give different results: for 1,576 payees present in both, the single-sender share was 6.4% by count (computed 1 November, 874 classified) and 18.3% by amount (computed 4 November, 889 classified). This is not a same-window comparison. The windows end three days apart and the classified sets differ, so the gap is not all due to the method. The pattern behind most of the moves is a payee with many small senders and one large one, which looks spread out by count and concentrated by amount.

Incomplete samples

We read up to 10,000 transfers per address in each direction. 17 of the 1,252 classified payees reached that limit, so their shares rest on partial data and could move either way. Leaving them out, the three shares are 70.9%, 18.7% and 10.4%, so they do not change the picture.

What buyers and agents can do

• Before paying, check that the payee is the one the origin you are paying quotes. A directory entry is a pointer, not proof.
• Treat a payee change, or a network the origin did not quote, as a reason to review before paying.
• Keep a record of what was quoted and what was paid.

OceanAlt's free check at https://oceanalt.com/api/decide supports comparing the payee in a Payment Intent with the origin's own quote, when the intent's resource_ref is the absolute URL you are paying. It returns a decision with its evidence. Comparing with an earlier payment needs that earlier intent too, sent as previous_payment_intent. Quotes are cached for up to 10 minutes, and origins on private networks are not contacted.

Method

• Directory. Daily snapshots of the public Coinbase x402 Bazaar directory, taken around 22:12 UTC. Each snapshot is hashed and chained to the previous one. This report uses 28 October to 3 November 2026. A route is one listed URL. A host is the lowercase hostname. A payee is a distinct listed payment address. A shared payee appears on two or more hosts. Route shares are deduplicated by route.
• Live quote check. About 1,200 hosts a day on rotation, up to two routes per host. GET first, then one POST with an empty JSON body only if GET returns 405. No payment and no payment header are ever sent. Six-second timeout, no redirects followed. Only status categories and per-payee match results are stored, not response bodies. Payee match figures are cumulative from 21 October and cover only directory-listed payees with at least one associated route that returned a readable quote.
• Inflow profile. Public Base chain data, USDC only. Transfers to and from each Base payee over about 30 days, with the start block estimated at two seconds per block. Transfers from identified exchange wallets are left out of both shares, but included in the inflow total. Up to 10,000 transfers are read per direction. Classes are assigned in this order: no inflow, fewer than five sending addresses, round-trip 30% or more, single sending address 80% or more, otherwise below both thresholds.
• Rounding. Percentages are rounded to one decimal place.

Limits

• One directory. Other x402 directories are not covered.
• Base USDC only for inflow. Other networks and tokens are not covered.
• The inflow window is about 30 days, and route-level status history is seven days.
• The live check samples by host, not by route, and its payee match rate covers only payees with at least one associated route that returned a readable quote.
• The count and amount methods were not run on the same window.
• Round-trip and single-sender patterns have many ordinary causes. We have no rule yet that separates them.
• Inflow includes all USDC transfers, not only x402 settlements.
• No seller, host or address is named in this report, and none will be.

Data as of 4 November 2026 UTC.