NexFlow › Library › x402 per-call vs key-tier pricing

x402 per-call vs key-tier pricing: one meter, two shelves

NexFlow's 80-chain RPC relay sells the same engine two ways. The x402 lane charges per request in USDC, settled by an HTTP 402 handshake, with no key and no account. The rk1_ key is a flat one-time pass with a rate shelf and larger batches. Neither is "cheaper"; each is cheaper for a different shape of traffic. This page puts the published numbers side by side and tells you which shape is yours.

Comparison · updated September 2026 · not financial advice

What the relay is, before the pricing

The NexFlow RPC hub fronts a JSON-RPC relay across 80 chains — Ethereum, Base, Solana, the published list under /api/rpc/chains. A free public lane exists underneath everything: baseline reads with no key, rate-limited per IP, one endpoint per chain on its own /rpc/<chain>/ page. The two paid lanes exist for volume, and the question this page answers is which of them to reach for when the free lane's per-IP limit stops being enough.

Both paid lanes hit the same upstream engine and return the same result verbatim. You are not buying better data on one than the other. You are buying a different billing shape and a different rate shelf.

The x402 lane

The x402 lane lives at rpc.nexflowscan.com/api/v1/x402/rpc/{chain}. You POST a standard JSON-RPC object — or a batch of up to 10 — with no payment header, and the endpoint answers HTTP 402 with a machine-readable offer. Your client settles $0.002 in USDC, retries with the payment header, and gets the upstream response. Any standard x402 client runs the loop automatically. There is no key, no account, no KYC; the payment header is the credential.

The billing rule that matters is charge-on-success. An upstream error — unknown chain, disallowed method, batch over the cap, rate limit — is mirrored back uncharged. A 200 that carries a JSON-RPC error object is an answered call and settles, which is how every RPC provider bills method-level refusals. The lane is advertised in agent.json and registered in the x402 bazaar, so an agent can discover and price it without a human.

The rk1_ key

The key is a flat $25 one payment, in USDC on Solana or Base — it does not expire, with no signup and no KYC. It buys a rate shelf of 3,000 items per minute and batches of up to 100 items. You send it as a header and the relay stops counting per request. The feature page calls it the volume shelf, which is exactly right: a bot or a service that makes a steady stream of calls all month is the workload it was shaped for.

Side by side, with sources

Every row is read from the x402 RPC feature page and the RPC hub on the date shown. These are the published prices and caps; whether one lane is cheaper for you depends entirely on your call volume and burst shape, which is the arithmetic in the next section.

The one "not published" cell is the x402 lane's rate shelf. The feature page describes rate-limit errors as uncharged but does not state a per-minute figure for the lane, so we do not either.

The break-even, done honestly

This is plain division, and it is worth doing in the open rather than asserting a winner. At $0.002 per call, $25 buys 12,500 x402 calls. If your lifetime total stays under 12,500 billable calls, the per-call lane costs less; above that, the key does. That is the only "break-even" on this page, it is derived from two published prices, and it moves the moment either price changes — check the feature page before you plan around it.

Two things complicate the division. First, batching: an x402 request carries up to 10 items and the key carries up to 100, so "call" and "item" are not the same word, and a workload that batches heavily gets more out of the key's shelf than the raw count suggests. Second, shape: 12,500 calls spread evenly across a month is one thing; 12,500 calls in a ten-minute burst is another, and the key's 3,000 items-per-minute shelf is a published ceiling while the x402 lane's is not. Do the division on your real numbers, then ask whether your bursts fit.

Who should pick x402 per-call

Pick the x402 lane if the caller is an agent or any process that should not hold a long-lived credential; if your volume is low, unpredictable, or below the 12,500-call lifetime line; if you want every call to be individually accountable; or if you want to try the relay with nothing more than a wallet that can pay USDC. It is also the honest choice for a workload that is bursty and small — pay for the burst, pay nothing between bursts.

The friction is real: every call carries a payment round-trip, and your client has to speak x402. Standard clients do, so the friction is a library import, not a project.

Who should pick the rk1_ key

Pick the key if a human or a service account can hold a secret, your lifetime volume is clearly above the line, and you batch — 100 items per request against 10 is the difference between a wallet-wide balance sweep in one call and ten. It suits bots polling on a schedule, indexers, dashboards refreshing many addresses, and anything where per-call settlement overhead would dominate the work. The integrate page carries the route map for both lanes and the free baseline beneath them.

The free lane, and the other x402 shelf

Do not skip the free lane. Baseline reads with no key, rate-limited per IP, on every one of the 80 chains — for a wallet, a light bot or a script that polls occasionally, it is enough, and both paid lanes exist for the moment it is not. And note that NexFlow runs a second x402 price list for its token-risk API, published in the API docs, with different per-call figures for different verdict routes. Those are a different product on the same payment rail; the numbers on this page are the RPC relay's, and the per-chain Solana and Ethereum pages carry the same curl you would use on any of the 80.

Frequently asked