x402 on Solana, and why the share figures disagree

RoundhouseReviewed .md
In short

Solana carried a large share of x402 transaction activity through 2026, reported at roughly 70% of monthly activity by mid-August by several sources, while Base retained the cumulative lead. Solana payments use an SPL token flow rather than EIP-3009, which means an index covering both chains runs two different detectors.

Contents
  1. What the reported figures say
  2. Why did Solana grow so fast?
  3. What is different technically?
  4. Why does this make measurement harder?
  5. Should a seller build on Solana?
  6. Frequently asked questions
  7. Where to check this yourself

What the reported figures say#

Several sources through 2026 put Solana at roughly 70% of monthly x402 transaction activity by mid-August, against total volume of about $24M across all chains over the prior 30 days. An independent tally of 680 x402 services found Solana at about 74% of measured transactions, though that count covered one directory and only 49 Solana services.

Other trackers reported lower shares over different windows, including one putting Base's weekly transfer share at 48% against Solana's 38%.

All of these can be correct simultaneously. They differ on window, on whether they count transactions or dollars, on chain coverage, and on what evidence standard decided what counts. Why counts disagree goes through the six specific causes.

Source typeTends to favour
Cumulative since launchBase, which started first
Recent weekly or monthlySolana, which grew faster
Transaction countSolana, whose payments are smaller
Dollar volumeWhichever chain had the large transfers
Directory-derived samplesWhichever chain that directory covers better

Why did Solana grow so fast?#

Three reasons, in rough order of importance.

Transaction cost. Solana fees are low enough that settling a sub-cent payment individually is comfortably economic. This is the binding constraint on the whole category, and Solana is well inside it.

Throughput. High-frequency payment patterns that would congest other chains do not congest this one. For a seller expecting bursty agent traffic that is a real property rather than a benchmark claim.

Stablecoin depth. A lot of dollar-denominated balance already sits on Solana, and buyers pay from where their money is. A chain where your buyers already hold a balance is a chain they can pay you on without bridging.

What is different technically?#

The HTTP layer is identical. A server answers 402 with terms, a client signs, retries with a payment header, the server verifies and settles. Nothing about that changes.

What changes is the authorisation. There is no EIP-3009 on Solana, because EIP-3009 is an Ethereum token standard. The equivalent is an SPL token flow where a relayer pays the fee on a transfer the holder authorised, which produces the same property that matters to agents: a buyer can hold one stablecoin, no native token, and still pay.

x402 v2 is what made this a first-class path rather than an extension, by generalising the network and asset fields away from their EVM shape. Client code that maps a network name to an EVM chain id, or validates an asset as a 20-byte hex address, breaks here.

Why does this make measurement harder?#

Because an index covering both chains is running two detectors rather than one detector twice.

On EVM chains, the x402 signal is a gasless authorised transfer relayed by a facilitator, identified from the EIP-3009 marker and the transaction sender. On Solana the instruction is different, the marker is different, and the relayer set is different.

Two consequences follow, and both show up in published figures.

Important

The evidence standards on the two chains are not automatically equivalent. A number that pools them is summing two different definitions of "x402 payment", and any difference in detector strictness between the chains shows up as a shift in apparent share. This is why per-chain comparison is the only comparison worth making, and why a tracker that publishes one blended total is less useful than one publishing two.

The second consequence is coverage. Indexers built EVM-first have better Solana coverage now than a year ago, and some still do not cover it at all. A share figure derived from an index with uneven coverage measures the index as much as the market.

Should a seller build on Solana?#

By buyer, mostly.

Choose Solana if your buyers hold balances there, if you expect high call frequency where per-settlement cost compounds, or if you are already operating in that ecosystem.

Choose Base if your buyers are EVM-native, if you want the longest-established tooling, or if indexer coverage matters to you commercially because you want your history visible to buyers screening you.

Advertise both once either is working. The accepts array takes multiple entries and a buyer picks one it can satisfy, which removes the failure where a willing buyer cannot pay because its funds are elsewhere.

What should not decide it is a share percentage. Those move by tens of points in weeks and the figure you are shown is usually older than it looks.

Frequently asked questions#

Does my EVM client library work on Solana?#

No. The authorisation construction is different, so you need a client that implements the Solana path. Check library support before committing, since coverage is uneven.

Which facilitators settle on Solana?#

Coverage differs per facilitator and changes. Check the facilitator's own documentation rather than the specification, which describes what is possible rather than what is available.

Is Solana x402 volume as inflated as Base's?#

The published analyses of wash trading and self-dealing cover the ecosystem broadly, and the pattern follows cheap transactions wherever they are. Nothing suggests one chain is clean, and the authenticity question applies to both.

Can one payment settle across chains?#

No. A payment settles on one chain. Multi-chain means offering a choice of terms, not bridging within a payment.

Which chain should I check a seller's history on?#

The one its receiving address is on, which you get from its live 402 rather than a directory. A seller operating on both chains has two histories and an audit of one is not an audit of the other.

Where to check this yourself#

/stats breaks the record down per chain with the window and basis stated rather than publishing a pooled total, and /status says which chains the index covers and how far behind each one it is. That second page is the one to read before concluding a chain is quiet rather than unwatched.

Reading this as an agent?

Every page here has a markdown twin at the same URL plus .md. Same words, no navigation, no markup to strip. And the settlement record this article describes is a live index you can query rather than a claim you have to take on trust.

  • GET https://roundhouseai.io/resources/x402-on-solana.mdthis page, as markdown
  • GET https://roundhouseai.io/llms.txtevery surface on roundhouseai.io
  • GET https://api.roundhouseai.io/v0the index: endpoints and schema
  • GET https://api.roundhouseai.io/v0/test/x402$0.01 over x402, and it mints your own key with no account

/docs/api has the limits and the SQL surface. /v0/account, /v0/endpoints and the capability layer answer without a key.

Read next