Japão
No Japão, devem ser analisadas as normas aplicáveis e as publicações da Agência de Serviços Financeiros e de outras entidades competentes.
Infraestrutura para stablecoins
Crie sistemas de stablecoins na Solana.
Defina a camada de conexão, as responsabilidades e as evidências técnicas que a sua equipa pode analisar.
Conceba sistemas de stablecoins na Solana com uma camada de conexão RPC claramente delimitada e evidências operacionais verificáveis.
Contexto regulamentar
Conceber para as jurisdições em que opera.
A arquitetura técnica e os processos operacionais devem considerar as regras aplicáveis; a classificação concreta deve ser avaliada separadamente para cada oferta.
Material de referência analisado:
União Europeia
Na União Europeia, a análise deve considerar o MiCA e as orientações das autoridades europeias e nacionais competentes.
Estados Unidos
Nos Estados Unidos, a classificação pode depender de regras federais e estaduais e das competências dos organismos relevantes.
Exemplos de mercado
JPYC
A documentação pública do JPYC apresenta uma iniciativa de stablecoin dirigida ao mercado japonês; a adequação a cada caso de uso deve ser avaliada de forma independente.
JPYC Inc.Documentação pública do JPYCJPYSC
As informações publicadas sobre o JPYSC oferecem outro exemplo do Japão; a sua posição jurídica, disponibilidade e adequação técnica devem ser verificadas para cada projeto.
SBI GroupDocumentação pública do JPYSCEsta página fornece contexto técnico, não aconselhamento jurídico, fiscal ou regulatório.
Camada de conexão RPC
Função técnica da camada de conexão RPC
O ERPC pode fornecer uma camada de conexão RPC que as aplicações usam habitualmente para consultar o estado da Solana, enviar transações já assinadas e consultar o respetivo resultado. A carteira ou o signatário do cliente cria e controla as assinaturas. O ERPC encaminha o pedido para a infraestrutura RPC da Solana e devolve a resposta da rede; o acompanhamento e a conciliação ficam a cargo do sistema do cliente.
- 01Consultar o estado da Solana
- A aplicação consulta dados de contas ou transações da rede Solana através da camada de conexão RPC.
- 02Enviar uma transação já assinada
- Uma transação previamente assinada pelo sistema do cliente é encaminhada para a infraestrutura da Solana através da conexão RPC.
- 03Consultar o resultado da transação
- O sistema do cliente obtém o resultado comunicado pela infraestrutura da Solana e interpreta-o segundo as suas próprias regras.
A camada de conexão transporta consultas, pedidos de envio e respostas da rede. Não cria assinaturas do cliente nem decide como um resultado deve ser registado nos processos operacionais.
Percurso da transação
Da aplicação à conciliação pelo cliente
O percurso separa a lógica da aplicação, a assinatura, o transporte RPC, o processamento na rede Solana e o acompanhamento posterior pelo cliente.
- 01
Aplicação
A aplicação determina a operação e prepara os dados da Solana ou as instruções de transação necessários.
- 02
Signatário do cliente
A carteira ou o serviço de assinatura do cliente analisa o conteúdo e gera a assinatura sob controlo do cliente.
- 03
Camada de conexão ERPC
O ERPC transporta o pedido submetido para a infraestrutura RPC da Solana e devolve à aplicação a resposta recebida da rede.
- 04
Processamento na Solana
A rede Solana processa o pedido de acordo com o seu estado naquele momento e com as regras do protocolo.
- 05
Confirmação e conciliação pelo cliente
O sistema do cliente decide como acompanhar a confirmação e conciliar o seu próprio estado operacional.
Cada etapa pode ser analisada através do pedido, da assinatura controlada pelo cliente, da resposta RPC e dos dados de conciliação do seu sistema.
Limites de responsabilidade
O papel jurídico de cada parte depende da configuração adotada e da jurisdição aplicável.
- Signatário do cliente
- O cliente controla a carteira, a autorização da assinatura e o significado operacional da transação.
- Camada de conexão ERPC
- O ERPC fornece a conexão RPC selecionada e transporta o pedido e a resposta da rede.
- Processamento na Solana
- A rede Solana processa a transação segundo o estado da rede e as regras do protocolo.
- Confirmação e conciliação pelo cliente
- O sistema do cliente decide como acompanhar a confirmação e conciliar o seu próprio estado operacional.
Casos de uso operacionais
Fluxos de stablecoins com limites claros entre sistemas
Uma única camada de conexão pode apoiar diferentes processos empresariais, enquanto a assinatura, as decisões operacionais e a conciliação permanecem no sistema do cliente.
01
Finalização de compra
Na finalização de uma compra, a aplicação prepara o fluxo de pagamento, o cliente autoriza a transação e o sistema do comerciante associa a resposta observada na rede à encomenda.
02
Liquidação B2B, pagamentos e tesouraria
Em liquidações B2B, desembolsos ou operações de tesouraria, o sistema do cliente pode enviar transações assinadas e conciliar os resultados com faturas, aprovações e registos internos.
03
Pagamentos API com x402
Clientes e servidores podem trocar requisitos de pagamento x402 e PaymentPayloads específicos do esquema e da rede. Este fluxo de pagamento HTTP é separado do fluxo geral da aplicação; no esquema exact da Solana, o payload pode conter uma transação de pagamento serializada e parcialmente assinada para verificação e liquidação.
04
Conciliação e integração de sistemas
As integrações podem relacionar respostas RPC e estados posteriores da rede com encomendas, contabilidade ou sistemas de gestão do cliente sem transferir a lógica de conciliação para o ERPC.
x402 e pagamentos API
Um fluxo próprio para pagamentos de acesso a API
O x402 descreve uma troca baseada em HTTP de requisitos e comprovativos de pagamento; os sistemas participantes definem como executar e conciliar o pagamento concreto.
O PaymentPayload x402 depende do esquema e da rede escolhidos. No esquema exact da Solana, pode conter uma transação de pagamento Solana serializada e parcialmente assinada para verificação e liquidação.
- 01
Pedido de recurso
Um cliente solicita ao serviço um recurso HTTP protegido ou uma função da API.
- 02
Requisitos de pagamento 402
O serviço responde com HTTP 402 e descreve os requisitos de pagamento aceites para dar acesso ao recurso.
- 03
Payload de pagamento API assinado
O cliente cria e assina o payload de pagamento API previsto pelo x402 e junta-o a um novo pedido.
- 04
Verificação e liquidação
Os sistemas responsáveis verificam o payload de pagamento e executam a liquidação prevista segundo as condições de rede e de protocolo aplicáveis.
- 05
Resposta do recurso e da liquidação
Após a verificação, o serviço devolve o recurso HTTP ou um erro, juntamente com as informações disponíveis sobre o resultado da liquidação.
Limites de responsabilidade
Separar responsabilidades por camada do sistema
Uma arquitetura clara distingue as decisões do cliente, o escopo selecionado do ERPC e o processamento realizado pela rede Solana.
Cliente ou parceiro
O sistema do cliente decide como acompanhar a confirmação e conciliar o seu próprio estado operacional.
- Finalização de compra
- Conciliação e integração de sistemas
Escopo selecionado do ERPC
O ERPC não mantém sob custódia as chaves privadas do cliente nem assina transações da aplicação do cliente.
- Conectividade RPC da Solana
- Operações em VPS dedicado
- Infraestrutura de servidor físico
Rede Solana
A Solana processa as transações submetidas segundo o estado da rede e as regras do protocolo.
- Processamento na Solana
O papel jurídico de cada parte depende da configuração adotada e da jurisdição aplicável.
Evidências técnicas
Analisar a implementação em superfícies concretas
As equipas podem avaliar separadamente a conexão, a documentação e o ambiente operacional e registar evidências do escopo escolhido.
Conectividade RPC da Solana
Verifique na interface RPC quais as consultas e vias de envio da Solana de que a aplicação necessita e que respostas de rede processa.
Abrir evidências RPCDocumentação técnica
Use a documentação para analisar métodos, parâmetros, situações de erro e os limites de responsabilidade da integração.
Abrir a documentaçãoOperações em VPS dedicado
Avalie um ambiente VPS dedicado para serviços do cliente, componentes de integração e processos operacionais sob o seu controlo.
Ver opções de VPSInfraestrutura de servidor físico
Analise os servidores físicos como uma decisão de infraestrutura independente para cargas cujo ambiente o cliente pretenda planear diretamente.
Ver opções de servidor físicoPlaneie a camada de conexão antes da produção
Vamos delimitar a arquitetura certa para a sua stablecoin.
Fale connosco sobre requisitos RPC, limites de assinatura, respostas da rede e conciliação pelo cliente no seu caso concreto.