日本
面向日本市场时,应根据自身角色审视《资金结算法》的适用范围及主管部门的最新指引。
稳定币基础设施
监管背景
稳定币的发行、分发、托管和转移义务会因产品与司法辖区而异,应结合自身安排逐项核查。
已审阅的来源材料:
面向日本市场时,应根据自身角色审视《资金结算法》的适用范围及主管部门的最新指引。
面向欧盟时,应将发行、储备、信息披露和服务商义务与 MiCA 及目标成员国的规则逐一对应。
面向美国时,应评估适用的联邦和州级要求,包括资金传输、制裁、托管与消费者保护。
本页面提供技术背景,不构成法律、税务或监管建议。
RPC 的作用
应用可以通过 ERPC 查询 Solana 数据、发送已由客户签名的交易,并获取网络结果。私钥和签名始终由客户控制;ERPC 将请求转发至 Solana RPC 基础设施并返回网络响应。
ERPC 提供 RPC 请求与响应的传输层,但不接触客户私钥、不代客户签名,也不替客户决定如何完成业务对账。
交易流程
从生成交易意图到记录最终结果,每一步分别属于应用、客户签名方、ERPC 连接层、Solana 或客户系统。
应用依据自身业务逻辑生成操作意图,并组装所需指令。
客户的钱包或签名方检查已组装的交易,并在客户控制下完成签名。
ERPC 接收已签名请求,将其发送至 Solana RPC,并把收到的网络响应返回给应用。
Solana 按当时的网络条件和协议规则处理该交易。
客户系统自行决定如何监控确认并对账自身业务状态。
这样的拆分便于团队把技术流程逐项映射到安全、控制与记账模型。
各方的法律角色取决于具体安排和适用司法辖区。
运营场景
在不混淆各方职责的前提下,RPC 架构可以接入用户支付、企业结算、机器间 API 支付和内部账务系统。
01
在结账流程中,应用准备付款,客户签署交易,商户系统再独立跟踪网络结果和订单状态。
02
企业结算、批量付款和资金管理流程应预先设定签名权限、提交规则及内部控制。
03
客户端和服务器可以交换 x402 支付要求,以及与方案和网络对应的 PaymentPayload。此 HTTP 支付流程独立于应用的一般流程;在 Solana 的 exact 方案中,载荷可以包含序列化且部分签名的支付交易,用于验证和结算。
04
集成层按照客户系统的规则,将网络响应关联到订单、账务记录和操作日志。
x402 与 API 支付
x402 描述 API 层如何交换支付条件和支付证明;具体结算方式及资源交付取决于实际实现。
x402 PaymentPayload 的内容取决于所选方案和网络。在 Solana 的 exact 方案中,它可以包含序列化且部分签名的 Solana 支付交易,用于验证和结算。
客户端或代理向需要付费访问的资源发起 HTTP 请求。
服务器以 402 响应告知支持的方式、金额及其他支付条件。
客户端根据收到的 x402 条件生成 API 支付数据,并对其完成签名。
验证方检查支付载荷,并执行或观察该实现所采用的结算流程。
支付被接受后,服务器返回 HTTP 资源,并附带可用于关联此次结算的信息。
企业责任模型
上线前应明确谁管理密钥和业务逻辑、ERPC 提供哪些选定服务,以及 Solana 负责处理什么。
客户系统自行决定如何监控确认并对账自身业务状态。
ERPC 不保管客户私钥,也不为客户应用交易签名。
Solana 按当前网络条件和协议规则接收并处理链上交易。
各方的法律角色取决于具体安排和适用司法辖区。