此次发布的是在 x402.erpc.global 上提供、可实际运行的 x402 Solana RPC。用户、应用程序和 AI Agent 可以向 POST /v1/solana-mainnet 发送 Solana JSON-RPC 请求。当需要支付时ERPC 会返回 HTTP 402 Payment Required 以及 x402 支付 challenge。客户端随后可以附上 Solana mainnet 上的 USDC 稳定币支付 payload重新发送同一个请求并在支付验证与结算完成后收到 Solana RPC 结果。过去 API 支付大多依赖人类先注册服务、取得 API key然后 AI 或 bot 使用该 key。通过 x402AI Agent 和程序可以读取请求时返回的支付条件在所有者设定的预算与权限范围内完成支付并当场使用所需的 API。ERPC 将这一流程落地到 Solana RPC 这一具体基础设施场景中。什么是 x402x402 是一个开放支付协议用现代方式利用 HTTP 402 Payment Required将支付嵌入 Web 与 API 请求本身。传统 API 使用流程要求用户为每个服务创建账户、登记支付方式、生成 API key并管理月度订阅或预付 credit。这个流程适合人类在浏览器中签约使用但对于需要动态选择服务、只为实际使用部分付费的软件和 AI Agent 来说过于沉重。在 x402 中客户端访问付费资源时服务器首先返回 402 Payment Required。该响应包含支付条件应支付多少、在哪个网络、使用哪种资产。客户端根据这些条件创建支付 payload并带着支付证明重新发送同一请求。服务器验证并结算支付确认无误后返回所请求的 API 响应或内容。也就是说x402 将 Web API 中这个处理需要这个金额“已经支付”现在返回结果的对话作为自然的 HTTP request / response 流程嵌入进去。ERPC 实现了什么ERPC 的 x402 Solana RPC 是运行在 Cloudflare Workers 上的 Solana mainnet JSON-RPC proxy。支付验证和结算使用 Coinbase CDP x402 facilitator并处理 Solana mainnet 上的 USDC 稳定币支付。/.well-known/x402 公开了 x402 version 2、facilitator URL、Solana mainnet、USDC以及 /v1/solana-mainnet 的 POST endpoint。首次请求时客户端发送普通 Solana JSON-RPC body。如果此时没有 X-PaymentERPC 会返回 402 Payment Required并附带支付所需的 x402 challenge、RPC 方法 weight 以及以 USD 计价的价格信息。客户端随后根据条件创建 Solana mainnet 上的 USDC 稳定币支付 payload并在同一 JSON-RPC body 上附加 X-Payment header 后重新发送。ERPC 请求 facilitator 验证并结算支付取得 settlement receipt 后将请求 proxy 到上游 Solana RPC。最终客户端会收到 JSON-RPC 结果以及 X-Payment-Response receipt。为了兼容性ERPC 也接受 legacy header Payment-Signature。为了防止重复使用支付签名同一签名被 replay 时会返回 409 duplicate_payment。支付无效或金额不足时会返回 402 payment_invalid 或 payment_amount_too_low。价格遵循 ERPC 的 canonical token model每个方法的 raw weight 乘以 0.000001 USD。标准 JSON-RPC 方法为 42 tokensgetProgramAccounts 为 4200 tokensgetTokenLargestAccounts 为 2400 tokensgetMultipleAccounts 按 pubkey 数量每个增加 420 tokens。为了匹配 facilitator 的最小结算金额整个请求会应用 0.001 USD 的 minimum charge。例如 getSlot 的 raw weight 是 42 tokens但应用 minimum charge 后实际计费 weight 为 1000 tokens即 0.001 USD。同时也提供免费查询 endpointGET /health、GET /pricing、GET /.well-known/x402。/pricing 中可以确认各 Solana RPC 方法的 raw weight、应用 minimum charge 后的 weight 以及 USD 价格。作为微支付的意义x402 支持的重要意义之一是让 API 和 RPC 能够以接近微支付的粒度处理。过去 RPC 这类基础设施通常通过月度计划、固定 quota、预付 credit 或后付账单提供。用户往往需要预先购买比实际需要更多的额度。未使用的 credit 会被浪费而突发的使用量增长又会带来上限和追加购买问题。对于 AI Agent 或 bot 这类需要时大量读取、之后几乎不使用的 workload这种固定额度与实际使用量之间的差距尤其明显。通过 x402 这样的机制服务可以按 API request、数据读取或处理单位提示价格客户端只为所需部分支付。ERPC 的价格模型也以方法 raw weight 乘以 0.000001 USD 为基础。当前 endpoint 为了匹配 facilitator 最小结算额对整个请求应用 0.001 USD floor但基础单价设计为 1 token 0.000001 USD 的粒度。这在传统信用卡支付中并不现实。每次 0.1 美分甚至更小金额的支付手续费和审批流程本身就可能超过支付金额。稳定币支付与 x402 这样的 internet-native payment protocol使这些小额支付可以直接嵌入 API request / response 流程。此外batch JSON-RPC request 可以将多个 read-only call 合并到一个 request 中对合计 weight 只应用一次 floor。例如多个轻量状态确认方法可以一起调用而不是为每个 call 分别支付 minimum charge从而让整个 request 更高效地完成支付。因此ERPC 的 x402 支持是从先签约再使用 RPC走向读取所需数据时当场支付的一步。随着 AI Agent 根据上下文组合大量外部服务这种支付粒度将变得重要。为什么 AI Agent 支付重要AI Agent 正在开始自主完成写作、调研、编码、监控、寻找交易机会和运维基础设施等工作。这些任务往往在需要的瞬间使用付费外部资源例如 API、数据集、RPC、存储、计算资源、分析服务和认证服务。人类使用服务时可以先签 SaaS 合同、确认账单、发放 API key。但当 AI Agent 在工作中进行成千上万次小判断时如果每次合约或支付都需要人类批准流程就会停止。未来的模式是AI Agent 读取获取这份数据需要 0.001 USD执行这次计算需要某个金额等条件在所有者定义的预算、权限和策略范围内完成支付接收结果并记录 payment receipt。重点不是让 AI 无限制支付而是在人类和组织设定的 spending limit、使用目的和允许服务范围内自动化必要的支付。这不只是 checkout 自动化而是机器之间按需交换价值的支付基础设施。AI Agent、bot、API、IoT device、机器人和监控系统都可以在需要服务的瞬间完成支付。未来Agent-to-Agent / Machine-to-Machine 计费会自然发生一个 Agent 为另一个 Agent 的任务付费AI 为每次数据 API 调用付费监控系统只在异常发生时为高精度分析服务付费。Agentic Commerce 正在成为巨大市场McKinsey 估计到 2030 年agentic commerce 可能在全球 orchestrate 3 万亿到 5 万亿美元规模的商业活动。AI 已经成为搜索、比较、推荐和决策支持的入口。随着 identity、authorization、payments 等执行基础设施成熟AI Agent 预计会更深入地参与购买和服务执行。与此同时x402 这样的 internet-native payment protocol 已经开始展现大规模 transaction activity 与实验性用例。x402 官方网站公开过去 30 天的 transaction 数、volume、buyers、sellers。Circle 也提到 x402 在最初数月处理了超过 1 亿美元的支付。Chainalysis 也分析称Base 上的 x402 agentic payments 到 2026 年第 1 季度已经超过 1 亿笔 transaction。这些数字说明x402 并不只是概念而是已经进入高频 machine payment 的实验与使用阶段。市场仍处于早期但围绕 API、数据、计算资源和数字服务按 request 粒度支付的基础设施正在快速形成。Solana RPC 与 Agent 支付天然契合对于 Solana 应用来说RPC 并不是附属功能。余额确认、slot 查询、account 信息读取、program account 搜索、transaction status 确认、区块获取和实时监控都依赖 RPC。当 AI Agent 开始检查 Solana 状态、做出判断并执行行动时RPC 接近于它们的眼睛和手。Agent 会根据情况决定查看哪个 account、查询哪个 program、何时再次确认以及搜索到多深。在这样的环境中仅靠月度合约和固定 quota 并不总能适应细粒度使用。如果 Agent 可以在需要的瞬间调用所需 RPC 方法并直接为该请求支付它就能更灵活地组合外部服务。ERPC 的 x402 支持是面向这一世界的已实现第一步。AI Agent 和程序不仅可以把 Solana RPC 作为预先签约的固定服务也可以把它作为按需支付和使用的 service primitive。对开发者意味着什么对于开发者来说x402 支持的 ERPC 是实际验证 agentic workflow 与 pay-per-use API 设计的环境。例如一个调研 Agent 想确认 Solana account 状态时可以先向 ERPC 发送 RPC request。如果需要支付Agent 会从 402 response 读取所需金额确认在预算内创建 USDC 稳定币支付 payload 后重新发送。ERPC 验证支付并返回 RPC 结果。Agent 可以将结果与 receipt 保存到 task log。这一流程也可以用于 bot、监控系统、数据收集 pipeline、MCP server 和 AI agent runtime。开发者不必只依赖月度固定合约而可以在 task、API call、数据读取等粒度上验证服务组合方式。对于服务提供者而言x402 也让 API monetization 更细粒度。小型 API、专业数据、短时间计算、单个分析结果等过去难以通过传统支付方式收费的单位都可以更容易定价。早期采用并推动实际落地ELSOUL LABO 与 Validators DAO 通过 Solana RPC、Geyser gRPC、Shredstream、SLV、SLV AI、Validators Solutions 和 AS200261 Solana 专用数据中心持续改善 Solana 应用与 validator 运营所需的基础设施。AI Agent 支付与这些工作自然相连。当 AI 支持开发和运维自动选择所需的数据和计算资源并在需要时支付使用基础设施就不再只是人类签约的服务而会成为 Agent 自主组合的 primitives。我们通过早期采用 x402 等 internet-native payment protocol并以 Solana RPC 这一具体用例公开推动 AI Agent 支付的实际社会落地。这不是只谈未来的故事。该 endpoint 已经可以返回 HTTP 402、接受 USDC 稳定币支付、执行 Solana RPC并返回 receipt。ERPC 将继续提升 Solana 专用基础设施的性能同时推进 AI Agent 与自治系统更容易使用的支付、授权与执行层研发。使用范围本 endpoint 用于通过 x402 支付 ERPC Solana RPC 使用费。它不提供暗号资产交换、经纪、托管或钱包服务。