The Gateway blind spot

On October 29, 2026, Goldsky, a blockchain data company, wrote to the Major Matters x402 adoption tracker and asked to be listed. The request was routine. The entry it produced was not, because the way Goldsky collects payment removes the evidence the tracker normally relies on.

Goldsky documents two paid endpoints: Edge RPC, which serves EVM JSON-RPC, and Feeds, which serves wallet balances and token data. Both return HTTP 402 with an x402 version 2 payment challenge. The challenge names one payTo wallet, 12 settlement networks and the scheme "exact".

The amount is where the pattern breaks. The challenge asks for 5,000 atomic USDC, which is $0.005, on every network, and that is not the price of a call. Edge RPC costs 5 atomic USDC per call, or $0.000005. The challenge is asking for a top-up.

The first paid request funds a prepaid balance that Goldsky holds against the caller's wallet. Later calls draw it down without touching the chain. The deposit settles through Circle Gateway, whose GatewayWalletBatched contract is the verifying contract named in the challenge, and a top-up of $0.005 covers about 1,000 calls. Goldsky says a standard USDC option settled through the Coinbase CDP facilitator is coming; its documentation does not describe it yet.

What the chain stops showing

The consequence for anyone measuring adoption is direct. The payTo wallet shows zero token transfers on Basescan. That is the whole record. The money moves into a Gateway deposit, and the wallet the challenge names never receives a per-call payment that a block explorer can count.

So the tracker entry reads "live, volume not observable". The challenge is real and both endpoints serve it. Whether anyone has paid, and how often, cannot be read from the chain.

Two other sellers wrote in this month, and the contrast is the point. Kronos, at api.nexismvp.com, charges per call. Its settlement wallet shows 49 incoming USDC payments of $0.001 each between August 8 and October 27, 2026, from 14 sending addresses, one of which paid 23 times. Each paid call is a transfer, so the chain reports the volume. That is a floor rather than a total, but it is a floor anyone can check.

GigSoul, at api.gigsoul.com, publishes its own settlement feed at gigsoul.com/calls. When we checked on October 3, 2026, it listed 51 settlements in total and no customer volume. That is a seller stating its own number in public, which is a different kind of evidence from a block explorer, and still more than Goldsky's wallet offers.

The counts everyone quotes

This matters beyond one company because the public adoption numbers for x402 are built from on-chain transaction counts. Chainalysis reported 100 million cumulative x402 transactions on Base on June 3, 2026, and 138 million on October 14, 2026, with 87 percent of them under a dime. Visa and Artemis Analytics put adjusted cumulative volume at $15.0 million on July 14, 2026. TRM Labs, on September 9, 2026, found that 99.6 percent of the x402 value it analyzed settled in USDC and estimated that between 0.6 and 7.5 percent of screened payment value appears agentic.

Every one of those numbers rests on the same assumption: one request, one transfer. That assumption held while x402 was a per-call protocol, and it is now being engineered away. The spec ratified a Batch Settlement extension on May 11, 2026, five months after version 2 was released on December 11, 2025. An "Upto" payment scheme and an auth-capture scheme are in development. Goldsky's Gateway deposit is the same idea arriving from the seller side.

The break runs in two directions at once. A prepaid deposit turns up to 1,000 paid requests into one on-chain transfer, so the chain undercounts requests. A deposit that sits unused still counts as a transaction, so the chain overcounts paid requests. Either way, the on-chain count becomes a count of deposits, and a deposit is not a paid call.

The Chainalysis and TRM Labs numbers still describe the periods they cover. The series they belong to is about to measure something different from what it measured in June, with the label unchanged. A chart of cumulative transactions will keep rising. What it counts will have drifted underneath it.

What an independent count should do

We think the honest response is to stop treating the chain as one kind of evidence. For a per-call seller like Kronos, on-chain transfers are a floor on volume and worth reporting as one. For a deposit-based seller like Goldsky, the same transfers say nothing about volume, and a tracker should say so rather than report zero.

The better source is the seller. A settlement feed, or signed receipts a buyer can present, would let a third party count paid calls without trusting a wallet address. The spec has a proposal for "Receipt and settlement reference formats" in development. GigSoul's /calls feed is a crude existing example of the same thing, and crude is enough to start with.

Every tracker entry should also record which checks were made and which could not be. There are three: a live 402 challenge, ownership of the payTo wallet, and settlement history. For Goldsky, the challenge is live and the settlement history cannot be read, and the entry says which is which. The tracker's change log records each of those decisions as it is made.

Liveness is the one check that can run without the seller's help, so we now run it. Major Labs re-probes every listed seller daily for a live challenge and publishes the result at majorlabs.co/data/x402-liveness. The probe proves that the challenge is served. It proves nothing about volume. A green row is a served challenge, and a served challenge is all it is.

"Live" and "paid" are different claims. The tracker's status vocabulary now separates them: no customer volume, small volume, volume not observable, and material volume with a source. A seller can be live in every one of those states.

Before the number goes in the deck

Anyone quoting an x402 adoption number should ask two questions of it. Does it count transfers, deposits or requests, and could the source tell the difference? If the answer to the second is no, the number is a count of something, and it is worth checking what.