ERPC Launches Solana RPC with x402 Payment Support, Ushering in an Era Where AI Agents Pay On-Demand for Necessary APIs

ELSOUL LABO B.V. (Headquarters: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) and Validators DAO are pleased to announce that ERPC has today launched a Solana mainnet JSON-RPC proxy that supports x402 payments.

The newly launched service is a functional x402-compatible Solana RPC provided at x402.erpc.global. Users, applications, and AI agents can send Solana JSON-RPC requests to POST https://x402.erpc.global/v1/solana-mainnet. If payment is required, they will receive an HTTP 402 Payment Required response and an x402 payment request. Subsequently, by resending the same request with a payment payload using USDC stablecoin on the Solana mainnet, they can receive the Solana RPC results after payment verification and settlement.

Previously, API payments primarily involved humans making contracts first, issuing API keys, and then AI or bots borrowing those keys. With x402, AI agents and programs can read the payment conditions presented at the time of request, make payments within the budget and authority set by the owner, and approach a design where they can use necessary APIs on demand. ERPC has implemented this flow for the concrete infrastructure use case of Solana RPC.

What is x402 x402 is an open payment protocol that leverages HTTP's 402 Payment Required in a modern way to embed payments directly into web and API requests.

Traditional API usage required creating accounts for each service, registering payment methods, issuing API keys, and managing monthly subscriptions or prepaid balances. This flow was suitable for a world where humans contract and use services via browsers, but it is too cumbersome for a world where software and AI agents need to select services on demand and use only what they need.

With x402, when a client accesses a paid resource, the server first returns a 402 Payment Required response. This response includes payment conditions specifying the amount, network, and asset for payment. The client then creates a payment payload, such as with USDC, according to these conditions and resends the same request with proof of payment. The server verifies and settles the payment, and if everything is in order, returns the requested API or content.

In essence, x402 is a mechanism that embeds a conversation into Web APIs as natural HTTP requests and responses: 'This operation requires this amount,' 'Payment has been made,' 'Here are the results.'

What ERPC Has Implemented ERPC's x402-compatible Solana RPC is a Solana mainnet JSON-RPC proxy operating on Cloudflare Workers. It utilizes the Coinbase CDP x402 facilitator for payment verification and settlement, handling USDC stablecoin payments on the Solana mainnet. At /.well-known/x402, x402 version 2, the facilitator URL, Solana mainnet, USDC, and the POST endpoint at /v1/solana-mainnet are published.

In the initial request, the client sends a standard Solana JSON-RPC body. If no X-Payment header is present at this point, ERPC returns a 402 Payment Required response, along with the x402 challenge, the weight of the RPC method, and pricing information in USD required for payment.

Based on these conditions, the client creates a USDC stablecoin payment payload on the Solana mainnet and resends the same JSON-RPC body with the X-Payment header. ERPC requests the facilitator to verify and settle the payment. Upon receiving the payment receipt, it proxies the request to the upstream Solana RPC. Finally, the client receives the JSON-RPC result and the X-Payment-Response receipt. For compatibility, it also accepts Payment-Signature as a legacy header.

To prevent double payments, reused signatures are treated as 409 duplicate_payment. If the payment is invalid or the amount is insufficient, it will be returned as 402 payment_invalid or payment_amount_too_low.

Pricing is calculated based on ERPC's canonical token model, multiplying the raw weight per method by 0.000001 USD. Standard JSON-RPC methods have a raw weight of 42 tokens, getProgramAccounts is 4200 tokens, getTokenLargestAccounts is 2400 tokens, and getMultipleAccounts incurs an additional 420 tokens per pubkey. A minimum charge of 0.001 USD is applied to the entire request, aligning with the facilitator's minimum payment amount. For example, while the raw weight for getSlot is 42 tokens, the actual billed weight becomes 1000 tokens (0.001 USD) due to the minimum charge.

Endpoints available for free confirmation include GET /health, GET /pricing, and GET /.well-known/x402. The /pricing endpoint allows users to check the raw weight for each Solana RPC method, the weight after applying the minimum charge, and the price in USD.

Significance as Micropayments One of the significant implications of x402 compatibility is the ability to handle APIs and RPCs in units close to micropayments.

Traditionally, infrastructure like RPCs has been offered through monthly plans, fixed quotas, prepaid credits, or post-paid billing. With these methods, users tend to reserve a larger capacity in advance. Unused credits are wasted, and conversely, when usage suddenly increases, users face limitations or the need for additional purchases. This disparity between fixed capacity and actual usage is particularly pronounced for workloads like AI agents or bots that require large read operations only when needed and then remain largely idle.

With mechanisms like x402, it becomes possible to present pricing per API request, per data retrieval, or per operation, enabling payment for only the necessary amount. ERPC's pricing model is also designed to multiply the raw weight per method by 0.000001 USD. While the current endpoint applies a floor of 0.001 USD to the entire request in accordance with the facilitator's minimum payment amount, the base unit is designed with a granularity of 1 token = 0.000001 USD.

This is not feasible with traditional credit card payments. For transactions of 0.1 cents or less per instance, fees and authorization processes would exceed the payment amount. With stablecoin payments and internet-native payment protocols like x402, it has become practical to embed such small payments into API requests and responses.

Furthermore, with batch JSON-RPC requests, multiple read-only calls can be consolidated into a single request, allowing the floor to be applied only once to the total weight. For instance, when calling multiple light confirmation methods together, it's possible to design payments efficiently for the entire request rather than paying the minimum charge separately for each call.

In essence, ERPC's x402 compatibility represents a step towards not just 'contracting RPCs before use' but also 'paying on demand for the data read.' This granular payment design will be crucial in an era where AI agents dynamically utilize numerous external services.

Why AI Agent Payments Are Becoming Important AI agents are increasingly capable of autonomously performing tasks such as writing text, conducting research, writing code, monitoring systems, identifying trading opportunities, and managing infrastructure. These operations require utilizing various paid resources like external APIs, datasets, RPCs, storage, computing resources, analytics services, and authentication services at the precise moment they are needed.

For humans, this typically involves pre-contracting SaaS services, reviewing invoices, and issuing API keys before use. However, when AI agents operate by making thousands or tens of thousands of small decisions, the process would halt if humans had to approve contracts and payments for each instance.

Moving forward, AI agents will be able to read conditions like 'Acquiring this data requires $0.001' or 'Executing this computation requires this amount,' make payments within the budget, authority, and policies set by the owner, receive results, and record payment receipts. The key is not for AI to pay without limits, but to automate necessary payments within the spending limits, usage purposes, and permitted service scopes defined by humans or organizations.

This is not merely an automation of checkout. It is a payment infrastructure for machines to exchange necessary value on demand, including AI agents, bots, APIs, IoT devices, robots, and monitoring systems. In the future, agent-to-agent and machine-to-machine billing will occur naturally, such as one agent requesting work from another and paying for it, an AI paying small amounts each time to necessary data APIs, or a monitoring system calling a high-precision analytics service only when an anomaly is detected.

Agentic Commerce is Becoming a Major Market McKinsey estimates that agentic commerce could orchestrate between $3 trillion and $5 trillion globally by 2030. AI is already becoming the gateway for search, comparison, recommendations, and decision support. As execution infrastructure like identity, authorization, and payments matures, AI is expected to become more deeply involved in the actual purchase and utilization of services.

Meanwhile, internet-native payment protocols like x402 are beginning to demonstrate significant transaction activity and experimental use cases. The official x402 website publishes transaction counts, volume, buyers, and sellers over the past 30 days. Circle has also mentioned that x402 processed over $100 million in payments within its first few months. Chainalysis analysis indicates that x402 agentic payments on Base exceeded 100 million transactions by Q1 2026.

These figures indicate that x402 is not merely a concept but is already in the experimental and utilization phase of high-frequency machine payments. While the market is still in its early stages, the foundational technologies are rapidly being established for a world where APIs, data, computing resources, and digital services are paid for on a per-request basis.

Solana RPCs are Compatible with Agent Payments In Solana applications, RPCs are not just auxiliary functions. Many operations, such as balance checks, slot retrieval, account information retrieval, program account searches, transaction status confirmations, and block retrieval, rely on RPCs.

As AI agents investigate the situation on Solana, make decisions, and take actions, RPCs become akin to the 'eyes' and 'hands' for the agent. The agent itself will determine which accounts to view, which programs to investigate, when to reconfirm, and how deeply to search, based on the situation.

In this context, traditional monthly contracts or uniform quotas may not align with fine-grained changes in usage. If agents can call necessary RPC methods the required number of times and pay each time, they can more flexibly combine external services.

ERPC's x402 compatibility is an implemented first step towards this future. AI agents and programs will be able to treat Solana RPCs not just as 'pre-contracted fixed services' but as 'service primitives that can be paid for and used at the moment of need.'

Implications for Developers For developers, x402-compatible ERPC provides an environment to actually test the design of agentic workflows and pay-per-use APIs.

For example, if a research agent needs to check the state of a Solana account, it first sends an RPC request to ERPC. If payment is required, the agent reads the necessary amount from the 402 response, confirms it is within budget, creates a USDC stablecoin payment payload, and resends it. ERPC verifies the payment and returns the RPC results. The agent can then save the results and receipt to its task log.

This flow can also be applied to bots, monitoring systems, data collection pipelines, MCP servers, AI agent runtimes, and more. Developers can test designs that combine services on a per-operation, per-API call, or per-data retrieval basis, rather than relying solely on monthly fixed contracts.

Furthermore, for service providers, x402 offers a means to design API monetization more granularly. It becomes easier to price units that were previously difficult to charge for with traditional payment methods, such as small APIs, specialized data, short-duration computations, or individual analysis results.

Early Adoption and Social Implementation ELSOUL LABO and Validators DAO have continuously improved the infrastructure necessary for Solana applications and validator operations through Solana RPC, Geyser gRPC, Shredstream, SLV, SLV AI, Validators Solutions, and AS200261 Solana-specific data centers.

AI agent payments naturally connect with these initiatives. As AI assists in development and operations, autonomously selects necessary data and computing resources, and pays for them when needed, infrastructure shifts from being merely 'services contracted by humans' to 'components autonomously combined by agents.'

By being early adopters of internet-native payment protocols like x402 and launching them in a concrete use case like Solana RPC, we aim to advance the social implementation of AI agent payments.

This is not merely an initiative to talk about the future. It is an initiative that has been made public as a functional endpoint, covering everything from receiving an HTTP 402, making a payment with USDC stablecoins, executing a Solana RPC, to returning a receipt.

ERPC will continue to focus on performance improvements as a Solana-specific infrastructure, as well as research and development of payment, authentication, and execution platforms that are easy for AI agents and autonomous systems to use.

Scope of Use This endpoint is for paying ERPC's Solana RPC usage fees via x402. It does not provide cryptocurrency exchange, brokerage, custody, or wallet services.

Related Links Paid RPC endpoint: POST https://x402.erpc.global/v1/solana-mainnet

ERPC pricing: https://x402.erpc.global/pricing

ERPC OpenAPI: https://x402.erpc.global/doc

ERPC x402 service discovery: https://x402.erpc.global/.well-known/x402

ERPC Official Website: https://erpc.global/ja

ERPC Dashboard: https://dashboard.erpc.global/ja

Inquiries For inquiries regarding ERPC, x402-compatible Solana RPC, Solana RPC, Geyser gRPC, Shredstream, or infrastructure for AI agents, please contact us via the ERPC Dashboard.

ERPC Dashboard: https://dashboard.erpc.global/ja