Puntos clave
- Stellar combina operaciones nativas con contratos Soroban escritos en Rust.
- Las rampas de entrada y salida conectan transferencias en red con dinero fuera de ella.
- El activo, su emisor y las condiciones de canje deben identificarse por separado.
¿Qué es Stellar?
Stellar proporciona una base para transferir valor y emitir activos, con funciones nativas de la red y contratos Soroban para lógica adicional. Una aplicación puede utilizar una operación de pago o necesitar reglas programables, según lo que deba ocurrir con el activo.
La distinción importa para no añadir complejidad innecesaria. Una transferencia sencilla y un producto con autorizaciones condicionales tienen alcances diferentes. El diseño también debe identificar al emisor del activo y la relación entre su saldo digital y cualquier obligación de entrega fuera de la red.
Cómo funciona
Stellar confirma operaciones mediante su protocolo de consenso. Las transacciones pueden incluir funciones nativas o invocar contratos Soroban. En este segundo caso, el código se desarrolla con herramientas que compilan al entorno WebAssembly de la red.
Los estándares SEP describen interfaces utilizadas por servicios del ecosistema, incluidas rampas que conectan activos digitales y otros sistemas de pago. La aplicación debe seguir tanto la transacción on-chain como el estado externo de depósito o retirada. Esos procesos pueden fallar o retrasarse de manera independiente y necesitan conciliación.
Stellar distingue las operaciones nativas del ledger de la ejecución de contratos Soroban. Las trustlines expresan relaciones con activos emitidos, mientras que contratos y datos persistentes tienen sus propios recursos y ciclo de almacenamiento. Un diseño que mezcla ambos debe aclarar dónde reside cada saldo y qué autorización necesita cada acción.
Qué aporta Stellar
Stellar puede encajar en aplicaciones de pago, distribución de fondos y activos emitidos cuando existen servicios que cubren el recorrido completo del usuario. Soroban amplía el alcance cuando el producto necesita reglas que no caben en operaciones nativas.
En Metlabs, evaluamos quién recibe el dinero, qué activo se mueve y cómo se resuelve el canje. Después elegimos entre integración de pagos, contrato propio o una combinación. La decisión incluye control de claves, tratamiento de errores y una trazabilidad que permita al equipo de operaciones resolver incidencias.
En pagos conectados con un proveedor de entrada o salida, la transferencia on-chain es una etapa del recorrido. El estado bancario, las verificaciones del proveedor y la entrega al destinatario siguen procesos externos. Se conservan referencias que permitan conciliar ambas partes y resolver devoluciones. Para Soroban, además, se contempla la vigencia de datos y su restauración cuando corresponda, porque la disponibilidad del estado forma parte del mantenimiento de la aplicación.
Limitaciones y criterios de elección
Una transferencia confirmada en Stellar no demuestra que se haya completado un pago bancario ni garantiza las obligaciones de un emisor. Las rampas y servicios externos tienen sus propios procesos, condiciones y disponibilidad. El producto debe reflejar esas dependencias.
Soroban añade programación, pero también pruebas, mantenimiento y gestión del almacenamiento del contrato. XRPL puede ser una alternativa para operaciones nativas; una red EVM puede encajar cuando las dependencias son Solidity. La comparación debe abarcar todo el recorrido del dinero y no únicamente la comisión de red.
