An x402 payment can look fast in a dashboard and still feel slow to an agent.
The chain may accept a transaction quickly, while the facilitator is still verifying it. The facilitator may report settlement, while the merchant has not delivered the protected response. A low token transfer fee may hide native gas, facilitator charges, funding overhead, or failed attempts.
That makes x402 Payment Flow benchmarking more demanding than reading a network's block time or sending one test transfer. A useful comparison must measure the completed request: from the initial HTTP challenge through payment authorization, broadcast, confirmation, settlement reporting, and resource delivery.
This article defines that benchmark and the raw data required to run it across Base Sepolia, Solana Devnet, and GOAT testnet3. It also states an important data boundary: no funded test signer, merchant credentials, controlled paid endpoint, or multi-network facilitator setup was available in the current environment, so this artifact does not invent live latency or cost results. The attached CSV preserves the not-run status rather than presenting fictional measurements.
A Payment-Flow Benchmark Needs More Than Block Time
An x402 transaction has several clocks:
These events can happen in different systems and have different meanings.
Clock | What it measures | What it does not prove |
|---|---|---|
challenge latency | time for the server to return HTTP 402 and payment requirements | payment validity or service delivery |
signing latency | client-side wallet and policy work | chain confirmation |
verification latency | facilitator or resource-server validation of the payload | successful broadcast or delivery |
broadcast latency | time until a transaction is submitted | confirmation or merchant fulfillment |
confirmation latency | time to the benchmark's configured chain threshold | application-level settlement completion |
settlement-report latency | time until facilitator or merchant reports payment state | successful resource execution unless explicitly bound |
complete-request latency | time from initial request to protected response | long-term service quality |
Calling all of these "confirmation time" makes network comparisons difficult to reproduce. A fast block may not produce a fast paid API response. A slower chain may still give a better completed-request result if its facilitator, merchant backend, and retry behavior are more consistent.
The benchmark's primary outcome should therefore be t7 minus t0: the time from the initial request to a delivered protected response. Report the component clocks beside it so operators can identify where time is spent.
What The Benchmark Measures
Use UTC timestamps with millisecond or better resolution and capture these markers:
Marker | Event |
|---|---|
t0 | client begins the initial request |
t1 | resource server returns HTTP 402 and payment requirements |
t2 | wallet signs the payment payload |
t3 | payload is accepted or verified |
t4 | payment transaction is broadcast |
t5 | configured chain confirmation threshold is reached |
t6 | facilitator or merchant reports settlement |
t7 | protected resource is delivered and recorded |
Calculate:
The exact placement of t3 and t6 depends on the integration. Some resource servers verify locally. Some facilitators return an accepted state before the chain is confirmed. Some merchant systems use an order status endpoint that adds polling delay. Record the implementation and keep the event names stable.
Cost needs the same discipline. Record separately:
quoted resource price;
token amount in atomic units;
native gas used and gas asset;
facilitator fee, if any;
merchant or platform fee;
batch-settlement amortization;
failed transaction cost;
testnet funding cost, usually excluded from production economics;
bridge or treasury funding cost, reported separately from per-request cost.
Do not call the quoted USDC amount the total transaction cost if the wallet also pays gas. Do not treat a testnet faucet as evidence of mainnet economics.
Control Variables Before Comparing Networks
The same protocol can produce different results when the surrounding variables change. Freeze these inputs before the first sample:
Variable | Required control |
|---|---|
resource | identical response body, payload size, and server work |
scheme | use exact for the first fixed-price comparison, or compare schemes separately |
amount | same economic value, converted to each token's atomic units |
token | record token contract, decimals, and transfer mechanism |
facilitator | use one named facilitator per network and record its provider |
client SDK | same version and language where possible |
server SDK | same middleware behavior where possible |
RPC | record provider, region, endpoint class, and connection reuse |
location | run clients and servers from the same region or disclose the difference |
confirmation rule | define block, slot, or merchant threshold before sampling |
concurrency | begin with one in-flight request; test concurrency separately |
retry policy | record maximum retries and whether paid requests can be retried |
environment | keep testnet and production credentials completely separate |
A benchmark that changes facilitator, RPC provider, scheme, and confirmation policy at the same time cannot explain why one network wins. It may still be a useful system comparison, but it is not a clean network comparison.
Candidate Network Matrix
The planned pilot uses three strata. The table describes the planned path, not measured performance.
Network | CAIP-2 identifier | Planned environment | Planned facilitator path | Measurement status |
|---|---|---|---|---|
Base Sepolia | eip155:84532 | testnet | public x402 test facilitator | not run |
Solana Devnet | solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1 | testnet | public x402 test facilitator | not run |
GOAT testnet3 | eip155:48816 | testnet | GOAT x402 test merchant/facilitator path | not run |
The first two networks are useful for a protocol-level test because official x402 documentation lists them among the public testing facilitator's supported networks. GOAT testnet3 must be tested through the GOAT environment and credentials that are actually issued for that environment. It should not be sent to the public x402 facilitator merely because both paths use x402.
Network support is not one binary property. Record separately whether the SDK can identify the network, whether the facilitator supports it, whether the token and scheme are supported, whether a funded wallet is available, whether the merchant can settle there, and whether the protected resource is delivered only after the desired state.
The x402 protocol uses CAIP-2 identifiers to distinguish networks. It can register additional EVM networks at runtime, but runtime registration does not create a facilitator, token liquidity, merchant configuration, or production reliability. A support table is a prerequisite for a benchmark, not a benchmark result.
The Exact Test Procedure
Use a fixed-price exact payment for the first run. Usage-based upto and batched settlement change the authorization and settlement semantics, so they belong in separate test groups.
1. Prepare The Resource Server
Expose the same protected resource on each network path. The response should include a unique request ID, a deterministic payload hash, and a server timestamp. Keep server-side work constant and record whether the payment middleware settles before or after the handler completes.
2. Make The Unpaid Request
At t0, send the request without payment. At t1, record the HTTP 402 response and persist the payment requirements. Validate the amount, asset, network, destination, scheme, and expiration before signing.
3. Sign And Submit The Payment
At t2, record the wallet signature completion. At t3, record the first accepted verification result. Do not use the time the client library returns as a proxy for chain settlement.
4. Capture Broadcast And Confirmation
At t4, record the transaction or payment reference. Poll the authoritative chain or merchant status until the predefined confirmation threshold is reached at t5. The threshold must be the same kind of business rule for every network, even if the underlying unit is a block, slot, or merchant status.
5. Capture Settlement And Delivery
At t6, record the facilitator or merchant settlement state. At t7, record the protected response and verify that its request ID matches the original payment. A payment that settles but produces no valid response is a paid-but-undelivered sample, not a success.
6. Run Failure And Replay Cases
Successful samples are not enough. Include:
lost client response after broadcast;
duplicate settlement request;
expired payment requirement;
wrong network or token;
facilitator timeout;
merchant delivery failure after settlement;
repeated request with the same idempotency key.
Keep failure rows in the dataset. A network with a slightly slower median but fewer paid-but-undelivered outcomes may be preferable for an agent service.
Cost Accounting For x402 Payments
A useful cost report has at least three views.
Buyer Debit
How much value left the buyer's wallet, including the token amount and any native gas paid by the buyer.
Seller Receipt
How much the merchant received after network, facilitator, platform, or settlement deductions.
System Cost
The operational cost of retries, polling, failed transactions, liquidity, funding, RPC usage, and reconciliation. This may not appear in the onchain transfer but affects a production service.
For exact, the buyer authorizes the advertised amount and the payment is normally a fixed-price transfer. For upto, the buyer authorizes a maximum and the seller settles actual usage within that ceiling. For batch-settlement, the benchmark must amortize the eventual onchain settlement across the requests represented by the batch and separately report the offchain voucher path.
Never compare an exact one-call fee with a batch-settlement per-call fee without explaining the batch size and redemption timing.
The raw record should include both human-readable price and atomic amount. Use token decimals from the actual token contract or merchant configuration. Avoid converting all fees to USD unless the conversion timestamp and price source are also recorded.
Raw Data And Statistical Reporting
The artifact includes benchmark/raw-data.csv with one row per sample and the following fields:
The current file contains not-run rows for the three planned networks. It is an honest raw-data contract, not evidence that one network is faster or cheaper. Numeric values should be appended only after a controlled execution with funded test wallets and a reproducible environment.
For a pilot comparison, warm up each path separately and then collect at least 30 successful samples per network. For public testnets, more samples may be needed because queueing and shared infrastructure can produce heavy tails. Report:
sample count and failure count;
median, p90, and p95 for each latency field;
minimum and maximum;
timeout and paid-but-undelivered counts;
median and p95 complete-request time;
mean and distribution of gas and facilitator fees;
scheme, facilitator, RPC, region, and confirmation rule.
Do not silently remove slow or failed samples. If a run is excluded because the endpoint or facilitator was unhealthy, document the exclusion and publish the raw row separately.
How GOAT Should Be Benchmarked
GOAT Network needs a path-specific benchmark because its x402 integration exposes more than one settlement shape.
The standard DIRECT mode pays the merchant's receiving address and gates delivery on verified payment. For a paid API or content route, t6 can represent the merchant's settled status, while t7 represents delivery of the protected response.
DELEGATE is a separate mode for payment-triggered onchain execution and is disabled by default. Its completion condition may include callback execution after payment. If a benchmark reports only transfer confirmation, it has not measured the complete DELEGATE request. Record callback completion as a separate event or define t7 accordingly.
For a GOAT test, record:
goat-testnet or the exact selected environment;
chain ID and CAIP-2 identifier;
merchant ID and settlement configuration, without exposing secrets;
receiving token and token decimals;
DIRECT or DELEGATE mode;
API or merchant gateway path;
facilitator or GOAT settlement service;
order status and proof endpoint behavior;
callback completion if DELEGATE is used;
SDK and backend versions.
This is where GOAT can be valuable to developers: AgentKit and the GOAT x402 stack expose payer actions, merchant operations, settlement status, and environment-specific configuration in a broader agent-commerce surface. The benchmark should measure that complete developer path, not only the chain's RPC response.
The result still has to be earned by data. GOAT should not be declared the fastest or cheapest network until the same sample definition, cost accounting, and confirmation rule have been executed against the comparison paths.
What Results Would Change A Network Decision
Different results imply different decisions.
Observed result | Engineering interpretation |
|---|---|
high challenge latency | server, route, or geographic problem before payment |
high signing latency | wallet, policy, or client-side approval overhead |
high verification latency | facilitator or verification path dominates |
high broadcast latency | RPC submission or facilitator queueing issue |
high confirmation variance | chain congestion, threshold, or network tail behavior |
high settlement-report latency | merchant polling, facilitator callback, or status API delay |
high complete-request latency with fast settlement | delivery path is the bottleneck |
low token fee but high failure rate | apparent price advantage may not survive retries and support cost |
low median but high p95 | good demos, unpredictable agent experience |
low cost with batch settlement | inspect capital lockup, voucher risk, batch size, and redemption delay |
There is no universal winning network. A low-value, high-frequency API may weight p95 complete-request latency and failure rate. A treasury workflow may weight cost, confirmation policy, custody, and operational control. A callback-driven digital product may care more about settlement-to-execution completion than raw transfer time.
The selection should follow the service's acceptance rule, not a leaderboard.
FAQ
What should an x402 Payment Flow benchmark measure?
Measure challenge latency, signing, verification, broadcast, chain confirmation, settlement reporting, protected-resource delivery, fees, failures, and the complete request from the first HTTP call to the delivered response.
Is blockchain confirmation time the same as x402 settlement time?
No. Confirmation is one event in the flow. Facilitator processing, merchant status, callback execution, and resource delivery can add time before the agent receives a completed result.
Which networks does x402 support?
x402 uses CAIP-2 identifiers and can support EVM networks through registration, as well as network families such as Solana, Stellar, Aptos, TON, Algorand, and Hedera through compatible mechanisms. Practical support depends on the facilitator, scheme, token, merchant configuration, and environment.
Why benchmark the facilitator separately?
The facilitator may verify payloads, broadcast transactions, wait for confirmation, and return settlement status. Its implementation and region can materially affect the complete request, so a network-only measurement cannot explain the user-visible result.
How should GOAT DIRECT and DELEGATE be compared?
Compare them as separate workloads. DIRECT normally measures payment-gated delivery to the merchant. DELEGATE may include callback execution after payment. Use separate acceptance events and do not combine their timings into one average.
How much data is needed for a reliable comparison?
Use at least 30 successful samples per network for an initial pilot, preserve failed and timed-out samples, and report median and tail percentiles. Mainnet decisions should use a longer, repeated run across the real deployment region and workload.
Publish The Raw Run, Not A Network Slogan
An x402 Payment Flow benchmark is credible when another developer can reconstruct what was measured, with which facilitator, under which scheme, using which asset, confirmation rule, RPC, region, and sample set.
The article artifact deliberately separates documented support from live measurement. The planned networks are identified, the event timestamps are defined, the cost fields are explicit, and the raw CSV records that the current run was not executed because the required funded and credentialed test environment was unavailable.
That limitation is more useful than fabricated numbers. Once the controlled run is available, append the rows, calculate the percentiles, preserve failures, and update the conclusions. Then the comparison can answer the question developers actually face: not which network has the best headline metric, but which x402 path delivers the paid resource with predictable cost, settlement, and recovery.
