Solana RPC That Accepts x402: Pay-Per-Call From a Wallet
x402 is the HTTP-native payment protocol where a client responds to a 402 Payment Required status by paying — in crypto, on-chain — and retrying the request. For Solana builders it solves a specific problem: letting software pay for RPC access at the moment it needs it, with no account, no API key provisioning, and no human checkout flow.
This article explains how x402 works for Solana RPC, what "accepting x402" actually requires from a provider, and why the settlement model behind the scenes matters more than the headline. Nodius is used as the reference implementation — it serves spec-compliant x402 payment terms and runs a self-sponsored settle endpoint.
What x402 is (in one paragraph)
x402 revives the long-reserved HTTP 402 Payment Required status code as a real payment rail. The flow: a client makes a request → the server responds 402 with machine-readable payment terms (asset, amount, destination) → the client constructs and signs the payment → the server verifies and settles it → the original request is retried and succeeds. The "payment" is a standard on-chain transfer (USDC on Solana), so any wallet that can sign a transaction can pay. No accounts, no invoices, no card networks.
Why RPC is the natural x402 use case
RPC access is metered, per-request, and consumed by software — the exact shape x402 is designed for. A trading bot or AI agent making thousands of calls a day is a better fit for pay-per-call than for a monthly subscription with a credit quota. And because x402 payment is just a signed Solana transfer, an agent that already holds a wallet can pay for its own RPC with zero additional infrastructure.
The part nobody talks about: the settlement model
Two RPC providers can both say "we accept x402" and differ enormously under the hood. The variable is who settles the payment — and it drives both cost and latency.
| Model | How it works | Consequence |
|---|---|---|
| Third-party facilitator | Each payment routes through an external facilitator (e.g. Coinbase CDP) that verifies and settles it | An external dependency and added latency in every payment loop; per-call floor set by the facilitator's minimum settlement |
| Self-sponsored / self-monitored | The provider watches its own deposit wallet on-chain and credits the payer directly | No third party between the agent and its RPC; the provider verifies settlement against its own node |
A facilitator-settled x402 RPC verifies a payment on every request before proxying it. That payment round-trip is real overhead — measured in the ~1.4-second range per call in side-by-side testing (see the benchmarks). A self-sponsored model pays once (a deposit), then subsequent calls are just the RPC — in the low tens of milliseconds.
Pay-per-request vs. prepaid credits
There's a second axis: does the agent pay per request or deposit once and draw down?
- Pay-per-request x402 settles a payment on every call. Simple, no session state — but bakes the payment-verification latency into each call and sets a per-call price floor (the payment rail's minimum, ~$0.001).
- Prepaid credits (x402-compatible) settle once on deposit, then serve calls at the RPC's native speed and a much lower per-call cost (~$0.0001 for a light read). For a bot making thousands of calls, the deposit model is both faster and cheaper per call.
Nodius supports both: a self-sponsored x402 settle endpoint for autonomous top-up, and prepaid credits for the steady-state hot path — so an agent can bootstrap with a single x402 payment and then run at full speed on credits.
What "x402-compatible" should mean when you evaluate a provider
Because the term is unregulated, ask three questions:
- Does it return spec-compliant payment terms? A real
402with a spec-shapedaccepts[]block (asset, amount, destination), not a generic "payment required" page. - Who settles the payment? Self-monitored against the provider's own node, or routed through a third-party facilitator that adds latency and a price floor?
- Can the same wallet pay and call? Credits should attach to the wallet that authorized the transfer, so one keypair is both the payer and the identity — that's what makes it agent-usable.
Nodius answers all three: spec-compliant 402 terms, self-sponsored settlement verified on its own Agave node, and credits that attribute to the transfer authority — so a funded keypair is the entire account.
Per-call costs and the x402 settle endpoint are in the API reference. The head-to-head latency measurement (pay-per-request vs. prepaid) is on the benchmarks page. To make your first x402-paid call, use the quickstart.