日本
表示された日付は、日本の電子決済手段に関する制度の開始日です。金融庁のリンク先で、制度と施行に関する資料を確認できます。
ステーブルコイン基盤
ERPCは、Solanaの状態照会、署名済み取引の送信、その結果の照会に使うRPC接続層を提供します。ネットワーク、コンピュート、目的別の開発支援は、選択したプロジェクト範囲に応じて組み合わせられます。
Solana上のステーブルコインシステムにおける、RPC、署名、ネットワーク、照合の境界を整理した技術概要です。
規制の文脈
公開されている主な節目を、アーキテクチャと運用判断の時系列的な文脈として整理します。以下の各記述は、明記した一次情報にリンクしています。
一次情報の確認日:
表示された日付は、日本の電子決済手段に関する制度の開始日です。金融庁のリンク先で、制度と施行に関する資料を確認できます。
表示された日付から、資産参照トークンおよび電子マネートークンを扱うMiCA第III編・第IV編の適用が始まりました。
表示された日付に、GENIUS Actが署名され、法律として成立しました。
表示された日付に、SBIグループとStartaleはJPYSCのアカウントベースでの限定提供開始を発表しました。公開チェーンでの流通は、法務・税務上の準備を前提とする将来段階として説明されています。
SBI GroupJPYSC提供開始のお知らせ本ページはインフラの概要であり、法務・税務・規制に関する助言ではありません。適用される義務は、製品、法域、カストディモデル、参加主体によって異なります。
RPC接続レイヤー
アプリケーションは一般に、RPCを使ってSolanaの状態を照会し、署名済みトランザクションを送信し、その処理状況を確認します。秘密鍵は顧客管理のウォレットまたは署名者が保持し、そこでトランザクションに署名します。ERPCは署名済みトランザクションのリクエストをSolana RPCインフラへ転送し、ネットワーク応答を返します。確認状況をどう監視し、自社の業務システムへどう反映するかは、顧客システムが決定します。
RPCはアプリケーション向けの接続経路の一つです。システムには、バリデータ、インデクサ、プライベートなトランザクション経路などが含まれる場合もあります。ERPCは顧客の秘密鍵を保持せず、顧客に代わって署名せず、結果の記録方法も決定しません。
トランザクションの流れ
5つの段階で、アプリケーションロジック、顧客管理の署名、RPC転送、Solanaでの処理、顧客システムでの確認と照合を分けて示します。
アプリケーションは支払いを組み立てるために必要なSolanaの状態を照会し、トランザクション命令を準備します。
顧客管理のセキュリティ境界内で、ウォレットまたは署名者がトランザクションを組み立てて署名します。秘密鍵はERPCへ渡りません。
ERPCは署名済みトランザクションのリクエストをSolana RPCインフラへ転送し、ネットワーク応答を返します。
Solanaネットワークは、その時点のネットワーク状態とプロトコル規則に従ってトランザクションを処理します。
顧客システムは処理結果を照会し、確認状況の監視方法を決め、自社のアプリケーションと業務記録を照合します。
この流れでERPCが扱うのは、状態照会、署名済みトランザクションの送信、処理結果の照会です。署名、確認方針、業務上の照合は、顧客管理のシステムが担います。
各当事者の法的役割は、具体的な取り決めと法域によって異なり、個別の法的検討が必要です。
運用ユースケース
以下は代表的な統合パターンであり、顧客事例や、ERPCが規制対象サービスを提供することを示すものではありません。製品方針、署名、コンプライアンス、照合は顧客またはパートナーが担います。
01
アプリケーションが支払いを組み立て、顧客が承認・署名し、事業者システムがネットワーク上で確認した結果を注文に対応付けます。
02
顧客システムは、B2B決済、送金、資金管理のために署名済みトランザクションを送信し、その結果を請求書、承認記録、社内帳簿と照合できます。
03
クライアントとサーバーは、x402の支払い要件と、方式・ネットワークに応じたPaymentPayloadをやり取りします。このHTTP決済フローは、一般的なアプリケーションの処理フローとは別です。Solanaのexact方式では、検証と決済のため、シリアライズされた部分署名済みの支払いトランザクションをペイロードに含めることができます。
04
統合システムは、RPC応答と後続の状態照会を、注文、台帳、ERPの記録へ対応付けられます。照合ルールは顧客が保持します。
x402とAPI決済
x402は、ステーブルコインやウォレットではなく、HTTP決済プロトコルです。サーバーが支払い要件を提示し、クライアントが支払いペイロードを返した後にリソースを提供する手順を定めます。
x402のPaymentPayloadは、選択した方式とネットワークに応じて内容が異なります。Solanaのexact方式では、検証と決済のため、シリアライズされた部分署名済みのSolana支払いトランザクションを含めることができます。
クライアントが、サーバーへ有料のHTTPリソースまたはAPI操作を要求します。
サーバーが402 Payment Requiredと、受け付ける支払い要件を返します。
クライアントが署名済みのx402 API支払いペイロードを作成し、新しいリクエストとともに送信します。
サーバーまたはファシリテーターがペイロードを検証し、プロトコルで定められた決済を実行します。
検証と決済の後、サーバーがリソースと利用可能な決済結果を返します。
責任分界
アーキテクチャ上で、顧客管理の製品・コンプライアンス判断、契約したERPCの範囲、Solanaでのトランザクション処理を分けます。
顧客またはパートナーが、製品方針、アプリケーション動作、ウォレットと署名の管理、コンプライアンスと本人確認のプロセス、会計、照合ルールを定めます。
契約範囲内で、ERPCは共有または専用RPC、ネットワーク接続、選択したVPSまたはベアメタル基盤、目的別の開発支援を提供できます。ERPCは顧客の秘密鍵を保管せず、顧客アプリケーションのトランザクションへ署名しません。
Solanaは、プロトコル規則に従って送信されたトランザクションを処理し、ネットワーク上の台帳の状態を維持します。
この技術上の分界は、発行者、カストディアン、取引所、ブローカー、支払仲介者、エンドユーザーウォレットの役割をERPCその他の当事者に割り当てるものではありません。法的役割は具体的な取り決めと法域によって異なり、個別の法的検討が必要です。
一次情報
以下のRPC、ドキュメント、VPS、ベアメタルの各ページは、アーキテクチャ検討に使える公開情報です。どの構成要素を採用するかは契約範囲によって決まります。
アプリケーションに必要な状態照会、署名済みトランザクションの送信、状態確認を、RPC製品ページと照らして確認します。
RPCサービスを見るドキュメントで、メソッド、パラメータ、エラー応答、統合境界を確認します。
RPCドキュメントを読む顧客運用のサービスや統合コンポーネントを選択範囲に含める場合は、VPSの選択肢を確認します。
VPSの選択肢を見る物理サーバー環境を独立したインフラ判断として計画する場合は、ベアメタルの選択肢を確認します。
ベアメタルの選択肢を見るエンタープライズ相談
RPC要件、顧客管理の署名境界、状態確認と照合のフロー、選択範囲に含めるネットワークまたはコンピュート構成を相談できます。