Japan
The date shown marks the start of Japan’s electronic payment instruments regime. The linked Financial Services Agency materials provide the statutory and implementation context.
Stablecoin infrastructure
Build stablecoin systems on Solana.
ERPC provides the RPC connection layer that applications use to read Solana state, submit already signed transactions, and query the resulting status. Network, compute, and purpose-built engineering can be combined within the selected project scope.
A technical overview of RPC, signing, network, and reconciliation boundaries for stablecoin systems on Solana.
Regulatory context
Regulatory milestones by jurisdiction
Selected public milestones provide dated context for architecture and operating decisions. Every statement below links to a named primary source.
Sources reviewed:
European Union
The date shown marks when MiCA Titles III and IV for asset-referenced tokens and e-money tokens began to apply.
United States
The date shown marks when the GENIUS Act was signed into law.
Public examples from Japan
JPYC
On the date shown, JPYC officially launched its yen-denominated stablecoin and issuance and redemption platform.
JPYC Inc.Official launch announcementJPYSC
On the date shown, SBI Group and Startale announced limited account-based provision of JPYSC. Their announcement describes public-chain circulation as a future step subject to legal and tax readiness.
SBI GroupJPYSC launch announcementThis infrastructure overview is not legal, tax, or regulatory advice. Obligations depend on the product, jurisdiction, custody model, and participating entities.
RPC connection layer
Read, submit, and observe results
Applications commonly use RPC to read Solana state, submit already-signed transactions, and query the resulting status. The customer-controlled wallet or signer retains the private keys and creates the transaction signature. ERPC forwards the already-signed transaction request to Solana RPC infrastructure and returns the network response. The customer system determines how to monitor confirmation and reconcile its own business state.
- 01Read
- Query balances, account state, block data, and transaction status needed by the application.
- 02Submit
- Submit an already-signed transaction through the RPC connection layer for delivery to the Solana network.
- 03Confirm
- Query processing and confirmation status so the customer application can update its own business state.
RPC is one application-facing connection path; validators, indexers, and private transaction paths may also be part of a system. ERPC does not hold customer private keys, create customer signatures, or decide how the customer records the result.
Transaction journey
Follow a payment from state query to reconciliation
The five stages separate application logic, customer-controlled signing, RPC transport, Solana processing, and confirmation and reconciliation in the customer system.
- 01
Customer application
The application reads the Solana state needed to construct a payment and prepares the transaction instructions.
- 02
Customer-controlled signer
Within the customer-controlled security boundary, the wallet or signer builds and signs the transaction. Private keys are not passed to ERPC.
- 03
ERPC RPC layer
ERPC forwards the already-signed transaction request to Solana RPC infrastructure and returns the network response.
- 04
Solana network
The Solana network processes the transaction according to current network state and protocol rules.
- 05
Status and reconciliation
The customer system queries the resulting status, decides how to monitor confirmation, and reconciles its own application and business state.
In this journey, ERPC carries state queries, already-signed transaction submissions, and resulting-status queries. Signing, confirmation policy, and business reconciliation remain within customer-controlled systems.
Ownership and responsibility boundaries
The legal roles of all parties depend on the arrangement and jurisdiction and require separate legal analysis.
- Customer-controlled signer
- The customer controls the application, wallet, private keys, signature authorization, and transaction intent.
- ERPC RPC layer
- ERPC’s boundary covers the selected RPC connection. It excludes custody of customer private keys, transaction signing, and customer business rules.
- Solana network
- Solana processes submitted transactions and maintains network ledger state under its protocol rules.
- Status and reconciliation
- The customer owns the rules that turn network responses and status queries into confirmation decisions and reconciliation records.
Operational use cases
Connect stablecoin flows to business systems
These are representative integration patterns, not customer or regulated-service claims. Product policy, signing, compliance, and reconciliation remain with the customer or partner.
01
Checkout and embedded payments
The application constructs the payment, the customer authorizes and signs it, and the merchant system maps the observed network result to the order.
02
B2B settlement, payouts, and treasury
Customer systems can submit signed transactions for settlement, payouts, or treasury workflows and reconcile the results with invoices, approvals, and internal books.
03
x402 API and agent payments
Clients and servers can exchange x402 payment requirements and scheme- and network-specific PaymentPayloads. This HTTP payment flow is separate from the general application journey; on Solana’s exact scheme, the payload can contain a serialized, partially signed payment transaction for verification and settlement.
04
Reconciliation and system integration
Integrations can map RPC responses and later status queries to order, ledger, or ERP records while the customer retains the reconciliation rules.
x402 and API payments
Follow the x402 payment flow
x402 is an HTTP payment protocol, not a stablecoin or wallet. It defines how a server states payment requirements and how a client returns a payment payload before the server provides a resource.
The x402 PaymentPayload is specific to the selected scheme and network. For Solana’s exact scheme, it can contain a serialized, partially signed Solana payment transaction for verification and settlement.
- 01
Request paid resource
A client requests a paid HTTP resource or API operation from the server.
- 02
Return 402 requirements
The server responds with 402 Payment Required and the payment requirements it accepts.
- 03
Create signed payload
The client creates the signed x402 API payment payload and sends it with a new request.
- 04
Verify and settle
The server or facilitator verifies the payload and performs the settlement defined by the protocol.
- 05
Return resource and result
After verification and settlement, the server returns the resource and the available settlement result.
Responsibility boundaries
Separate responsibilities by system layer
The architecture separates customer-controlled product and compliance decisions, the contracted ERPC scope, and transaction processing on Solana.
Customer or partner
The customer or partner defines product policy, application behavior, wallet and signing controls, compliance and identity processes, accounting, and reconciliation rules.
- Checkout and embedded payments
- Reconciliation and system integration
Selected ERPC scope
Within the contracted scope, ERPC can provide shared or dedicated RPC, network connectivity, selected VPS or bare-metal infrastructure, and purpose-built engineering. ERPC does not custody customer private keys or sign customer application transactions.
- ERPC Solana RPC
- VPS infrastructure
- Bare-metal infrastructure
Solana network
Solana processes submitted transactions and maintains network ledger state according to its protocol rules.
- Solana network
This technical map does not assign ERPC or any other party the role of issuer, custodian, exchange, broker, payment intermediary, or end-user wallet. Legal roles depend on the arrangement and jurisdiction and require separate legal analysis.
First-party evidence
Review the first-party product surfaces
The RPC, documentation, VPS, and bare-metal surfaces below document the public components available for architecture review. The contracted scope determines which components apply.
ERPC Solana RPC
Review the RPC product surface against the application’s required state queries, signed transaction submissions, and status queries.
View RPC servicesERPC RPC documentation
Use the documentation to review methods, parameters, error responses, and integration boundaries.
Read RPC documentationVPS infrastructure
Review VPS options when customer-operated services or integration components are included in the selected scope.
View VPS optionsBare-metal infrastructure
Review bare-metal options when the customer needs to plan the physical server environment as a separate infrastructure decision.
View bare-metal optionsEnterprise inquiry
Define the project boundary.
Discuss the RPC requirements, customer-controlled signing boundary, status and reconciliation workflow, and any network or compute components in the selected scope.