Japan
Für Japan sind insbesondere die geltenden gesetzlichen Vorgaben sowie Veröffentlichungen der Financial Services Agency und weiterer zuständiger Stellen zu prüfen.
Stablecoin-Infrastruktur
Stablecoin-Systeme auf Solana entwickeln.
Gestalten Sie Verbindungsschicht, Zuständigkeiten und prüfbare technische Nachweise so, dass Ihr Team sie nachvollziehen kann.
Planen Sie Stablecoin-Systeme auf Solana mit einer klar abgegrenzten RPC-Verbindungsschicht und nachvollziehbaren Betriebsnachweisen.
Regulatorischer Kontext
Für die Rechtsordnungen der angebotenen Märkte planen.
Technische Architektur und Betriebsabläufe sollten die jeweils geltenden Vorgaben berücksichtigen; die konkrete Einordnung ist für jedes Angebot gesondert zu prüfen.
Geprüfte Quellen:
Europäische Union
In der Europäischen Union sind MiCA und die Hinweise der jeweils zuständigen europäischen und nationalen Aufsichtsbehörden in die Prüfung einzubeziehen.
Vereinigte Staaten
In den Vereinigten Staaten kann die Einordnung von bundes- und einzelstaatlichen Vorgaben sowie den jeweils zuständigen Behörden abhängen.
Marktbeispiele
JPYC
Die öffentlich zugänglichen Unterlagen zu JPYC zeigen eine auf den japanischen Markt ausgerichtete Stablecoin-Initiative; ihre Eignung für den eigenen Anwendungsfall ist unabhängig zu bewerten.
JPYC Inc.Öffentliche Unterlagen zu JPYCJPYSC
Die veröffentlichten Informationen zu JPYSC bieten ein weiteres Beispiel aus Japan; Rechtsstatus, Verfügbarkeit und technische Eignung sind für den konkreten Einsatz gesondert zu prüfen.
SBI GroupÖffentliche Unterlagen zu JPYSCDiese Seite bietet technischen Kontext und keine Rechts-, Steuer- oder Regulierungsberatung.
RPC-Verbindungsschicht
Die technische Rolle der RPC-Verbindungsschicht
ERPC kann eine RPC-Verbindungsschicht bereitstellen, über die Anwendungen üblicherweise den Solana-Zustand abrufen, bereits signierte Transaktionen übermitteln und deren Ergebnis abfragen. Wallet oder Signaturdienst des Kunden erstellt und kontrolliert die Signaturen. ERPC leitet die Anfrage an die Solana-RPC-Infrastruktur weiter und gibt deren Netzwerkantwort zurück; Überwachung und Abstimmung verbleiben beim Kundensystem.
- 01Solana-Zustand abrufen
- Die Anwendung ruft über die RPC-Verbindungsschicht Konten- oder Transaktionsdaten aus dem Solana-Netzwerk ab.
- 02Signierte Transaktion übermitteln
- Eine zuvor vom Kundensystem signierte Transaktion wird über die RPC-Verbindungsschicht an die Solana-Infrastruktur weitergeleitet.
- 03Transaktionsstand abfragen
- Das Kundensystem fragt den von der Solana-Infrastruktur gemeldeten Transaktionsstand ab und bewertet ihn nach seinen eigenen Regeln.
Die Verbindungsschicht transportiert Lese- und Übermittlungsanfragen sowie Netzwerkantworten. Sie erzeugt keine Kundensignaturen und entscheidet nicht über die geschäftliche Verbuchung eines Ergebnisses.
Transaktionsablauf
Von der Anwendung bis zur kundenseitigen Abstimmung
Der Ablauf trennt Anwendungslogik, Signatur, RPC-Transport, Verarbeitung im Solana-Netzwerk und die anschließende Überwachung im Kundensystem.
- 01
Anwendung
Die Anwendung bestimmt die gewünschte Aktion und bereitet die dafür erforderlichen Solana-Daten oder Transaktionsanweisungen vor.
- 02
Kundenseitige Signatur
Wallet oder Signaturdienst des Kunden prüft den Inhalt und erstellt die Transaktionssignatur unter der Kontrolle des Kunden.
- 03
ERPC-Verbindungsschicht
ERPC transportiert die eingereichte Anfrage zur Solana-RPC-Infrastruktur und gibt die erhaltene Netzwerkantwort an die Anwendung zurück.
- 04
Solana-Verarbeitung
Das Solana-Netzwerk verarbeitet die Anfrage gemäß aktuellem Netzwerkzustand und den geltenden Protokollregeln.
- 05
Kundenseitige Bestätigung und Abstimmung
Das Kundensystem entscheidet, wie es Bestätigungen überwacht und den eigenen Geschäftsstand abstimmt.
Jede Stufe lässt sich anhand der Anfrage, der kundenseitigen Signatur, der RPC-Antwort und der eigenen Abstimmungsdaten des Kunden prüfen.
Verantwortungsgrenzen
Die rechtliche Rolle jeder Partei hängt von der konkreten Ausgestaltung und der jeweiligen Rechtsordnung ab.
- Kundenseitige Signatur
- Der Kunde kontrolliert Wallet, Signaturfreigabe und die fachliche Bedeutung der Transaktion.
- ERPC-Verbindungsschicht
- ERPC stellt die ausgewählte RPC-Verbindung bereit und übermittelt Anfrage und Netzwerkantwort.
- Solana-Verarbeitung
- Das Solana-Netzwerk verarbeitet die Transaktion nach Netzwerkzustand und Protokollregeln.
- Kundenseitige Bestätigung und Abstimmung
- Das Kundensystem entscheidet, wie es Bestätigungen überwacht und den eigenen Geschäftsstand abstimmt.
Betriebliche Anwendungsfälle
Stablecoin-Abläufe mit klaren Systemgrenzen
Die Verbindungsschicht kann unterschiedliche Geschäftsabläufe unterstützen, während Signatur, fachliche Entscheidungen und Abstimmung beim jeweiligen Kundensystem bleiben.
01
Checkout
Beim Checkout erstellt die Anwendung einen Zahlungsablauf, der Kunde autorisiert die Transaktion, und das Händlersystem ordnet die beobachtete Netzwerkantwort der Bestellung zu.
02
B2B-Abwicklung und Treasury
Für B2B-Abwicklung, Auszahlungen oder Treasury-Vorgänge kann das Kundensystem signierte Transaktionen einreichen und die Ergebnisse mit Rechnungen, Freigaben und internen Büchern abstimmen.
03
x402-API-Zahlungen
Clients und Server können x402-Zahlungsanforderungen und schema- sowie netzwerkspezifische PaymentPayloads austauschen. Dieser HTTP-Zahlungsablauf ist vom allgemeinen Anwendungsablauf getrennt; beim Exact-Schema für Solana kann die Payload eine serialisierte, teilweise signierte Zahlungstransaktion zur Prüfung und Abwicklung enthalten.
04
Abstimmung und Systemintegration
Integrationen können RPC-Antworten und später abgefragte Netzwerkstände mit Auftrags-, Ledger- oder ERP-Daten des Kunden verknüpfen, ohne die fachliche Abstimmungslogik an ERPC zu übertragen.
x402 und API-Zahlungen
Ein getrennter Ablauf für zugangsgesteuerte API-Zahlungen
x402 beschreibt einen HTTP-basierten Austausch von Zahlungsanforderungen und Zahlungsnachweisen; die konkrete Ausführung und Abstimmung wird von den beteiligten Systemen festgelegt.
Die x402-PaymentPayload richtet sich nach dem gewählten Schema und Netzwerk. Beim Exact-Schema für Solana kann sie eine serialisierte, teilweise signierte Solana-Zahlungstransaktion zur Prüfung und Abwicklung enthalten.
- 01
Ressource anfordern
Ein Client fordert eine geschützte HTTP-Ressource oder API-Funktion beim Dienst an.
- 02
402-Zahlungsanforderungen
Der Dienst antwortet mit HTTP 402 und beschreibt die für den Zugriff akzeptierten Zahlungsanforderungen.
- 03
Signierte API-Zahlungsnutzlast
Der Client erstellt und signiert die für das x402-Protokoll vorgesehene API-Zahlungsnutzlast und sendet sie mit einer erneuten Anfrage.
- 04
Prüfung und Abwicklung
Die zuständigen Systeme prüfen die Zahlungsnutzlast und führen die vorgesehene Zahlungsabwicklung unter den jeweiligen Netzwerk- und Protokollbedingungen aus.
- 05
Ressourcen- und Abwicklungsantwort
Nach der Prüfung liefert der Dienst die HTTP-Ressource oder eine Fehlerantwort zusammen mit den verfügbaren Angaben zum Abwicklungsergebnis zurück.
Verantwortungsgrenzen
Zuständigkeiten nach Systemschicht trennen
Eine belastbare Architektur hält kundenseitige Entscheidungen, den gewählten ERPC-Leistungsumfang und die Verarbeitung im Solana-Netzwerk auseinander.
Kunde oder Partner
Das Kundensystem entscheidet, wie es Bestätigungen überwacht und den eigenen Geschäftsstand abstimmt.
- Checkout
- Abstimmung und Systemintegration
Ausgewählter ERPC-Leistungsumfang
ERPC verwahrt keine privaten Kundenschlüssel und signiert keine Anwendungstransaktionen des Kunden.
- Solana-RPC-Anbindung
- Dedizierte VPS-Betriebsumgebung
- Bare-Metal-Infrastruktur
Solana-Netzwerk
Solana verarbeitet eingereichte Transaktionen nach dem jeweiligen Netzwerkzustand und den Protokollregeln.
- Solana-Verarbeitung
Die rechtliche Rolle jeder Partei hängt von der konkreten Ausgestaltung und der jeweiligen Rechtsordnung ab.
Technische Nachweise
Die gewählte Implementierung anhand konkreter Oberflächen prüfen
Teams können Verbindung, Dokumentation und Betriebsumgebung getrennt bewerten und die Nachweise für ihren ausgewählten Umfang festhalten.
Solana-RPC-Anbindung
Prüfen Sie an der RPC-Oberfläche, welche Solana-Abfragen und Einreichungswege die Anwendung benötigt und welche Netzwerkantworten sie verarbeitet.
RPC-Nachweis öffnenTechnische Dokumentation
Nutzen Sie die Dokumentation, um Methoden, Parameter, Fehlersituationen und die Trennung der Verantwortlichkeiten für die Integration nachzuvollziehen.
Dokumentation öffnenDedizierte VPS-Betriebsumgebung
Bewerten Sie eine dedizierte VPS-Umgebung für kundenseitige Dienste, Integrationskomponenten und kontrollierbare Betriebsprozesse.
VPS-Betriebsoptionen ansehenBare-Metal-Infrastruktur
Prüfen Sie physische Server als eigenständige Infrastrukturentscheidung für Workloads, bei denen der Kunde die Serverumgebung gezielt planen möchte.
Bare-Metal-Optionen ansehenVerbindungsschicht vor dem Produktivbetrieb planen
Die passende Stablecoin-Architektur gemeinsam abgrenzen.
Besprechen Sie RPC-Anforderungen, Signaturgrenzen, Netzwerkantworten und die kundenseitige Abstimmung für Ihren konkreten Anwendungsfall.