Japón
En Japón, conviene revisar la normativa aplicable y las publicaciones de la Agencia de Servicios Financieros y de las demás autoridades competentes.
Infraestructura para stablecoins
Construya sistemas de stablecoins en Solana.
Defina la capa de conexión, las responsabilidades y las evidencias técnicas que su equipo necesita revisar.
Diseñe sistemas de stablecoins en Solana con una capa de conexión RPC bien delimitada y evidencias operativas verificables.
Contexto regulatorio
Diseñe para las jurisdicciones en las que presta servicio.
La arquitectura técnica y los procesos operativos deben considerar las normas aplicables; la clasificación concreta se evalúa por separado para cada oferta.
Fuentes revisadas:
Unión Europea
En la Unión Europea, el análisis debe tener en cuenta MiCA y las orientaciones de las autoridades europeas y nacionales que resulten competentes.
Estados Unidos
En Estados Unidos, la clasificación puede depender de normas federales y estatales, así como de las competencias de los organismos correspondientes.
Ejemplos del mercado
JPYC
La documentación pública de JPYC muestra una iniciativa de stablecoin orientada al mercado japonés; cada equipo debe evaluar por su cuenta si encaja en su caso de uso.
JPYC Inc.Documentación pública de JPYCJPYSC
La información publicada sobre JPYSC ofrece otro ejemplo japonés; su situación jurídica, disponibilidad y adecuación técnica deben comprobarse para cada implementación.
SBI GroupDocumentación pública de JPYSCEsta página ofrece contexto técnico, no asesoramiento jurídico, fiscal ni regulatorio.
Capa de conexión RPC
Función técnica de la capa de conexión RPC
ERPC puede proporcionar una capa de conexión RPC que las aplicaciones utilizan habitualmente para consultar el estado de Solana, enviar transacciones ya firmadas y preguntar por su resultado. La cartera o el firmante del cliente crea y controla las firmas. ERPC reenvía la solicitud a la infraestructura RPC de Solana y devuelve la respuesta de la red; el seguimiento y la conciliación corresponden al sistema del cliente.
- 01Consultar el estado de Solana
- La aplicación consulta datos de cuentas o transacciones de la red Solana a través de la capa de conexión RPC.
- 02Enviar una transacción ya firmada
- Una transacción firmada previamente por el sistema del cliente se remite a la infraestructura de Solana mediante la conexión RPC.
- 03Consultar el resultado de la transacción
- El sistema del cliente obtiene el resultado comunicado por la infraestructura de Solana y lo interpreta conforme a sus propias reglas.
La capa de conexión transporta consultas, solicitudes de envío y respuestas de la red. No crea firmas del cliente ni decide cómo registrar un resultado en sus procesos operativos.
Recorrido de la transacción
De la aplicación a la conciliación del cliente
El recorrido separa la lógica de la aplicación, la firma, el transporte RPC, el procesamiento en la red Solana y el seguimiento posterior del cliente.
- 01
Aplicación
La aplicación determina la operación y prepara los datos de Solana o las instrucciones de transacción que necesita.
- 02
Firma del cliente
La cartera o el servicio de firma del cliente revisa el contenido y genera la firma bajo control del cliente.
- 03
Capa de conexión de ERPC
ERPC transporta la solicitud presentada hasta la infraestructura RPC de Solana y devuelve a la aplicación la respuesta recibida de la red.
- 04
Procesamiento en Solana
La red Solana procesa la solicitud según su situación en ese momento y las reglas del protocolo.
- 05
Confirmación y conciliación del cliente
El sistema del cliente decide cómo supervisar la confirmación y conciliar su propio estado operativo.
Cada etapa puede revisarse mediante la solicitud, la firma controlada por el cliente, la respuesta RPC y los registros de conciliación de su sistema.
Límites de responsabilidad
La función jurídica de cada parte depende de la configuración concreta y de la jurisdicción aplicable.
- Firma del cliente
- El cliente controla la cartera, la autorización de la firma y el significado operativo de la transacción.
- Capa de conexión de ERPC
- ERPC proporciona la conexión RPC elegida y transporta la solicitud y la respuesta de la red.
- Procesamiento en Solana
- La red Solana procesa la transacción conforme a su situación y a las reglas del protocolo.
- Confirmación y conciliación del cliente
- El sistema del cliente decide cómo supervisar la confirmación y conciliar su propio estado operativo.
Casos de uso operativos
Flujos de stablecoins con límites claros entre sistemas
Una misma capa de conexión puede atender distintos procesos de negocio, mientras la firma, las decisiones operativas y la conciliación permanecen en el sistema del cliente.
01
Pago en caja
En un pago en caja, la aplicación prepara el flujo, el cliente autoriza la transacción y el sistema del comercio asocia la respuesta observada en la red con el pedido.
02
Liquidación B2B, pagos y tesorería
En liquidaciones B2B, desembolsos o tesorería, el sistema del cliente puede enviar transacciones firmadas y conciliar sus resultados con facturas, autorizaciones y libros internos.
03
Pagos API con x402
Los clientes y servidores pueden intercambiar requisitos de pago x402 y PaymentPayloads específicos del esquema y la red. Este flujo de pago HTTP está separado del flujo general de la aplicación; en el esquema exact de Solana, el payload puede contener una transacción de pago serializada y parcialmente firmada para su verificación y liquidación.
04
Conciliación e integración de sistemas
Las integraciones pueden relacionar respuestas RPC y datos posteriores de la red con pedidos, contabilidad o sistemas de gestión del cliente sin trasladar a ERPC la lógica de conciliación.
x402 y pagos API
Un flujo específico para pagos de acceso a API
x402 describe un intercambio basado en HTTP de requisitos y evidencias de pago; los sistemas participantes definen cómo ejecutar y conciliar el pago concreto.
El PaymentPayload de x402 depende del esquema y la red seleccionados. En el esquema exact de Solana, puede contener una transacción de pago de Solana serializada y parcialmente firmada para su verificación y liquidación.
- 01
Solicitud del recurso
Un cliente solicita al servicio un recurso HTTP protegido o una función de la API.
- 02
Requisitos de pago 402
El servicio responde con HTTP 402 e indica los requisitos de pago que acepta para dar acceso al recurso.
- 03
Carga de pago API firmada
El cliente crea y firma la carga de pago API prevista por x402 y la adjunta a una nueva solicitud.
- 04
Verificación y liquidación
Los sistemas responsables verifican la carga de pago y realizan la liquidación prevista bajo las condiciones de la red y del protocolo aplicables.
- 05
Respuesta del recurso y la liquidación
Tras la verificación, el servicio devuelve el recurso HTTP o un error junto con la información disponible sobre el resultado de la liquidación.
Límites de responsabilidad
Separar las responsabilidades por capa del sistema
Una arquitectura clara distingue las decisiones del cliente, el alcance de ERPC seleccionado y el procesamiento que realiza la red Solana.
Cliente o socio
El sistema del cliente decide cómo supervisar la confirmación y conciliar su propio estado operativo.
- Pago en caja
- Conciliación e integración de sistemas
Alcance seleccionado de ERPC
ERPC no custodia claves privadas del cliente ni firma transacciones de la aplicación del cliente.
- Conectividad RPC de Solana
- Operaciones en VPS dedicado
- Infraestructura de servidores físicos
Red Solana
Solana procesa las transacciones presentadas según el estado de la red y las reglas del protocolo.
- Procesamiento en Solana
La función jurídica de cada parte depende de la configuración concreta y de la jurisdicción aplicable.
Evidencia técnica
Comprobar la implementación en superficies concretas
Los equipos pueden evaluar por separado la conexión, la documentación y el entorno operativo, y conservar evidencias del alcance elegido.
Conectividad RPC de Solana
Compruebe en la interfaz RPC qué consultas y vías de envío de Solana necesita la aplicación, y qué respuestas de red procesa.
Abrir evidencia de RPCDocumentación técnica
Use la documentación para revisar métodos, parámetros, casos de error y la separación de responsabilidades de la integración.
Abrir la documentaciónOperaciones en VPS dedicado
Valore un entorno VPS dedicado para servicios del cliente, componentes de integración y procesos operativos bajo su control.
Ver opciones de VPSInfraestructura de servidores físicos
Examine los servidores físicos como una decisión de infraestructura independiente para cargas cuyo entorno quiera planificar directamente el cliente.
Ver opciones de servidor físicoPlanifique la capa de conexión antes de producción
Delimitemos la arquitectura adecuada para su stablecoin.
Hablemos de requisitos RPC, límites de firma, respuestas de red y conciliación del cliente para su caso concreto.