Un análisis de las transacciones compensatorias, la liquidación parcial y los límites de la atomicidad en los pagos entre cadenas
Muchas instituciones y desarrolladores siguen considerando que un comprobante de transacción exitosa en la cadena del emisor demuestra que el pago se ha completado. En los sistemas entre cadenas, a menudo no es así.
Al revisar documentación técnica y observar comportamientos básicos en entornos controlados, aparece siempre el mismo patrón: el débito en la cadena de origen puede confirmarse correctamente, mientras que la cadena de destino aún puede fallar en una etapa posterior. Cuando eso ocurre, los fondos no se devuelven automáticamente. Por lo general, el sistema ejecuta una **transacción compensatoria**.
Atomicidad parcial
La documentación oficial de Rayls (*Enviar transacciones Enygma* y *Cómo funciona Enygma*) describe claramente los límites de la atomicidad:
- La llamada de origen es atómica: la quema y la solicitud de transferencia se confirman o fallan juntas.
- Cada tramo individual de destino es atómico: la acuñación y los pasos del programa correspondientes a ese tramo se confirman o fallan juntos.
- Todos los tramos de un único pago **no** son atómicos. Los tramos pueden liquidarse de forma independiente.
La documentación afirma explícitamente que «Los fallos se revierten, no se deshacen». La transacción del Hub y la acuñación en la cadena de destino son transacciones distintas. Si la acuñación o un paso del programa falla en el destino, el retransmisor ejecuta una transacción compensatoria para devolver el valor al remitente. No se trata de una única transacción atómica entre cadenas.
Hasta que se haga efectivo el reembolso, el saldo del remitente en la cadena de origen sigue reducido por el importe que falló.
¿Qué es una transacción compensatoria?
Una transacción compensatoria es una transacción **nueva e independiente** creada para corregir un fallo. No es una reversión de la transacción original.
Según la documentación de RaylsEnygmaHandler, si se revierte cualquier paso del programa, falla todo el tramo (incluida la acuñación). Luego, el retransmisor devuelve el valor al remitente en la cadena de origen mediante un mecanismo compensatorio. El reembolso aparece con el **mismo ID de referencia** y se registra con el estado `RECEIVED` en la cadena de origen, en lugar de ser una simple reversión del débito original.
Un ejemplo sencillo que concuerda con el comportamiento descrito en la documentación:
- El origen debita 10.
- Uno de los destinos recibe correctamente 4.
- Otro destino falla durante la ejecución.
- Una transacción compensatoria independiente devuelve 6 al remitente.
El resultado final es 4 entregados + 6 devueltos = 10. La transacción original en el origen sigue registrada como exitosa.
Diagramas
Flujo básico:
Atómico frente a varios tramos:
Ejemplo de liquidación parcial:
Riesgos prácticos que conviene tener en cuenta
Según la documentación y las observaciones en entornos controlados, a menudo se pasan por alto varios aspectos:
1. Los reembolsos no son instantáneos
La propia documentación de Rayls señala que, hasta que se efectúe el reembolso, el saldo del remitente sigue reducido. Los retrasos del retransmisor o los problemas al generar pruebas pueden dejar los fondos pendientes durante más tiempo del esperado.
2. La conciliación debe hacerse por tramo
Un único comprobante de origen no es suficiente. Hay que cotejar lo que salió del origen, lo que llegó a cada destino, lo que falló y lo que realmente se devolvió mediante la transacción compensatoria (normalmente con el mismo ID de referencia).
3. Dependencia de componentes fuera de la cadena
La detección de fallos y el inicio de los reembolsos suelen depender de retransmisores. Incluso en pruebas locales, pueden aparecer advertencias relacionadas con los compromisos de saldo o la generación de pruebas. Estos riesgos son mayores en producción.
4. Los resultados controlados ≠ garantías de producción
Un comportamiento impecable en un entorno de pruebas con fallos provocados deliberadamente no se traslada automáticamente a entornos de producción con carga simultánea, problemas de red o incoherencias de estado.
Conclusión
Un comprobante de éxito en la cadena de origen solo demuestra que se confirmó el débito. No demuestra que todos los destinos hayan recibido los fondos ni que se haya devuelto cualquier parte que haya fallado.
La ejecución exitosa en el origen, la liquidación en el destino y los reembolsos compensatorios son eventos relacionados, pero **no son el mismo evento**. Comprender esta distinción es importante al diseñar u operar flujos de liquidación entre cadenas.
La documentación oficial de Rayls ya describe abiertamente este patrón compensatorio. Lo importante es no tratar los resultados obtenidos en entornos controlados como una prueba completa de la fiabilidad en producción.
---
Aviso legal:
Este artículo es un análisis basado en la documentación de Rayls disponible públicamente y en observaciones técnicas realizadas en entornos controlados. No constituye una auditoría formal, asesoramiento de inversión ni una garantía sobre el comportamiento de ningún sistema en producción. Los lectores deben verificar los detalles directamente en la documentación oficial.
Fuentes
- Enviar transacciones Enygma: https://docs.rayls.com/docs/send-enygma-transactions
- Cómo funciona Enygma: https://docs.rayls.com/docs/how-enygma-works
- RaylsEnygmaHandler: https://docs.rayls.com/docs/raylsenygmahandler