Pontos-chave
- Stellar combina operações nativas com contratos Soroban escritos em Rust.
- As rampas de entrada e saída conectam transferências na rede com dinheiro fora dela.
- O ativo, seu emissor e as condições de resgate devem ser identificados separadamente.
O que é Stellar?
Stellar fornece uma base para transferir valor e emitir ativos, com funções nativas da rede e contratos Soroban para lógica adicional. Uma aplicação pode usar uma operação de pagamento ou precisar de regras programáveis, conforme o que deva acontecer com o ativo.
A distinção importa para não acrescentar complexidade desnecessária. Uma transferência simples e um produto com autorizações condicionais têm alcances diferentes. O design também deve identificar o emissor do ativo e a relação entre seu saldo digital e qualquer obrigação de entrega fora da rede.
Como funciona
Stellar confirma operações por meio de seu protocolo de consenso. As transações podem incluir funções nativas ou invocar contratos Soroban. Neste segundo caso, o código é desenvolvido com ferramentas que compilam para o ambiente WebAssembly da rede.
Os padrões SEP descrevem interfaces utilizadas por serviços do ecossistema, incluindo rampas que conectam ativos digitais a outros sistemas de pagamento. A aplicação deve acompanhar tanto a transação on-chain quanto o estado externo de depósito ou saque. Esses processos podem falhar ou atrasar de forma independente e precisam de conciliação.
Stellar distingue as operações nativas do ledger da execução de contratos Soroban. As trustlines expressam relações com ativos emitidos, enquanto contratos e dados persistentes têm seus próprios recursos e ciclo de armazenamento. Um design que combina os dois deve esclarecer onde reside cada saldo e qual autorização cada ação exige.
O que Stellar oferece
Stellar pode se encaixar em aplicações de pagamento, distribuição de fundos e ativos emitidos quando existem serviços que cobrem a jornada completa do usuário. O Soroban amplia o alcance quando o produto precisa de regras que não cabem em operações nativas.
Na Metlabs, avaliamos quem recebe o dinheiro, qual ativo se move e como o resgate é resolvido. Depois escolhemos entre integração de pagamentos, contrato próprio ou uma combinação. A decisão inclui controle de chaves, tratamento de erros e uma rastreabilidade que permita à equipe de operações resolver incidentes.
Em pagamentos conectados a um provedor de entrada ou saída, a transferência on-chain é uma etapa da jornada. O estado bancário, as verificações do provedor e a entrega ao destinatário seguem processos externos. Conservam-se referências que permitam conciliar as duas partes e resolver devoluções. No caso do Soroban, considera-se ainda a vigência dos dados e sua restauração quando necessário, porque a disponibilidade do estado faz parte da manutenção da aplicação.
Limitações e critérios de escolha
Uma transferência confirmada em Stellar não demonstra que um pagamento bancário tenha sido concluído nem garante as obrigações de um emissor. As rampas e os serviços externos têm seus próprios processos, condições e disponibilidade. O produto deve refletir essas dependências.
O Soroban acrescenta programação, mas também testes, manutenção e gestão do armazenamento do contrato. XRPL pode ser uma alternativa para operações nativas; uma rede EVM pode se encaixar quando as dependências são Solidity. A comparação deve abranger toda a jornada do dinheiro, e não apenas a taxa de rede.
