Lo primero que aprendí sobre los intercambios entre cadenas (cross-chain swaps) es que “fallar” no significa automáticamente “perdido.”
Cuando algo sale mal, la pregunta importante es qué hace la arquitectura subyacente a continuación.
Una transferencia mediante un puente (bridge) y un intercambio atómico entre cadenas pueden fallar de maneras completamente distintas.
Es posible que te deje intentando averiguar si todavía está pendiente una retransmisión (relay), una transacción de destino o el paso de reembolso (refund).
El otro puede diseñarse de modo que, si el intercambio no se completa, los contratos se desplacen automáticamente hacia una reversión (unwind).
Esa distinción es importante cuando estás moviendo activos reales entre cadenas.
La falla depende de la arquitectura
Una transacción entre cadenas no es un solo evento.
Puede haber una transacción en la cadena de origen, confirmaciones, una transacción del lado de destino, liquidez o ejecución del resolver, y la liquidación.
Si una parte no se completa, lo que sucede después depende de cómo se diseñó el sistema.
En algunas arquitecturas de puente, los fondos pueden permanecer bloqueados en un contrato, esperar a que se ejecute un proceso de relé (relay), o requerir un reembolso manual o un reintento.
Eso no significa necesariamente que los fondos hayan desaparecido. Significa que la ruta entró en un estado intermedio que necesita resolverse.
Por eso la arquitectura importa tanto cuando una transacción falla como cuando tiene éxito.
La diferencia entre “Atascado” y “Atómico”
Aquí es donde encuentro interesante la idea de la ejecución atómica.
Una ruta entre cadenas abierta puede dejar al usuario preguntando:
¿Dónde se detuvieron mis fondos?
¿Confirmó la transacción de origen?
¿Falló la transacción del destino?
¿El relayer todavía lo está procesando?
¿Hay algún reembolso disponible?
Un diseño atómico intenta reducir esas posibilidades.
El objetivo es simple:
O el intercambio acordado se completa, o los activos se devuelven según las condiciones de reembolso del protocolo.
Eso no significa que las fallas nunca ocurran.
Significa que el fallo se ha considerado como parte del diseño de la transacción, en lugar de tratarse como una situación inusual que requiere que alguien averigüe qué hacer después.
Cómo Omniston maneja el caso de falla
Omniston adopta un enfoque basado en resolvers usando Contratos de Timelock Hashed (HTLC) emparejados.
Para un intercambio entre cadenas, hay un HTLC en el lado de origen y otro en el lado de destino.
Ambas cosas están conectadas a la misma condición criptográfica.
El resolver bloquea el activo del lado de destino.
El activo del lado del usuario también está bloqueado.
Cuando se revela el secreto requerido, las condiciones permiten que el intercambio se liquide: el usuario recibe el activo del destino, mientras que el resolver puede reclamar el activo de origen.
Ese es el camino exitoso.
Pero lo más interesante es lo que ocurre cuando ese camino no se completa.
¿Qué pasa si el resolver no responde?
Supongamos que solicito un intercambio entre cadenas y un resolver se compromete con la cotización, pero no completa su parte de la transacción.
El sistema no debería dejar mis fondos ahí, esperando indefinidamente.
El HTLC tiene un timelock.
Si no se cumple la condición requerida dentro de la ventana de tiempo definida, el timelock permite que la parte adecuada recupere sus fondos bloqueados.
Para el usuario, eso significa que la transacción puede deshacerse en lugar de convertirse en un misterio de final abierto.
¿Qué pasa si el secreto nunca se revela?
Se aplica el mismo principio si el secreto necesario para completar la liquidación nunca se divulga.
Sin el secreto, los HTLC enlazados no pueden completar la ruta normal de liquidación.
Una vez que el timelock relevante expira, los activos bloqueados se pueden reembolsar según la lógica del contrato.
Esto es lo que hace que el diseño sea de todo o nada.
El resultado previsto no es:
«“El intercambio falló, así que un lado se queda con el dinero.”»
Es:
«“El intercambio se completó, o los fondos relevantes se vuelven recuperables a través del timelock.”»
STON.fi describe el diseño de Omniston como que tiene tres resultados posibles: ambas partes reciben los activos cotizados, el usuario recibe un reembolso si el resolver no responde, o el resolver recibe un reembolso si el secreto nunca se revela.
Un deshacer (unwind) no significa que tu dinero desaparezca
Probablemente esta sea la parte más importante de entender.
Cuando ves la palabra unwind, puede sonar como si algo hubiera salido terriblemente mal.
Pero en este contexto, el deshacer (unwind) en realidad es un mecanismo de protección.
Los activos se bloquearon temporalmente para hacer posible la liquidación entre cadenas.
Si no se cumplen las condiciones de liquidación, el timelock proporciona el camino de regreso al propietario original.
Así que la secuencia se parece más a:
Bloquear → intentar la liquidación → se cumplen las condiciones → completar
o
Bloquear → la liquidación no se completa → timelock → reembolso
El segundo camino no es un fallo del mecanismo de protección.
Es el mecanismo de protección que está funcionando.
¿Qué deberías revisar cuando un intercambio parece atascado?
No enviaría inmediatamente otra transacción.
Primero, yo revisaría el estado del original.
1. Revisa el estado de la transacción
Mira el estado que muestra la aplicación que maneja el intercambio.
¿Está pendiente?
¿La transacción de origen está confirmada?
¿El tramo del destino todavía se está procesando?
¿Hay un mensaje de error?
El estado puede decirte qué parte de la ruta estás esperando realmente.
2. Guarda el hash de la transacción
El hash de la transacción es una de las piezas de información más útiles que puedes tener.
Te da una forma de rastrear lo que pasó on-chain.
Si eventualmente necesitas soporte, enviar el hash de la transacción es mucho más útil que simplemente decir:
«“Mi intercambio está atascado.”»
3. Revisa el explorador de la blockchain relevante
No te fíes solo de la interfaz de la app.
Mira la transacción de la cadena de origen y, cuando aplique, la transacción del lado de destino.
Puedes verificar si la transacción fue confirmada, revertida o si todavía está pendiente.
4. Comprueba si el timelock ha expirado
En una transacción basada en HTLC, el momento de la condición de reembolso es importante.
Si el intercambio no se ha completado y el timelock relevante no ha expirado, los fondos pueden seguir simplemente bloqueados bajo las condiciones del contrato.
Si ya ha expirado, revisa la billetera y el estado relevante del contrato para confirmar que el camino de reembolso se completó.
¿Qué información deberías recopilar antes de contactar con soporte?
Si alguna vez necesito contactar con soporte sobre una transacción entre cadenas, recopilaría todo primero.
Como mínimo:
- Dirección de la billetera de origen
- Dirección de la billetera de destino
- Hash de la transacción
- Red de origen
- Red de destino
- Activo enviado
- Activo esperado
- Cantidad
- Tiempo aproximado en que se inició el intercambio
- Estado actual de la transacción
- Cualquier mensaje de error mostrado por la aplicación
- Enlaces relevantes del explorador
Esto hace mucho más fácil identificar en qué punto se detuvo la transacción.
Y, lo más importante, nunca compartas tu frase semilla ni tu clave privada con nadie que afirme estar proporcionando soporte.
Un hash de transacción es útil.
Una clave privada no es algo que el soporte debería necesitar jamás.
Por qué esto importa
Los intercambios entre cadenas son más complicados que los intercambios normales en la misma cadena porque intervienen múltiples redes y condiciones de liquidación.
Así que el manejo de fallos merece la misma atención que el flujo de la transacción exitosa.
Esa es una de las razones por las que el modelo de Omniston me interesa.
La arquitectura emparejada de HTLC no pretende que todas las transacciones entre cadenas siempre salgan perfectamente.
En su lugar, crea un camino de recuperación definido dentro de la propia transacción.
Completa el intercambio cotizado, o deja que la lógica del timelock deshaga los fondos bloqueados.
Para mí, ese es un estado de falla mucho más fácil de entender que simplemente preguntarse a dónde fueron mis activos.
Un sistema entre cadenas no debería responder solo:
“¿Cómo consigo que lleguen mis activos a través de la cadena?”
También debería responder:
“¿Qué pasa con mis activos si el intercambio no se completa?”
Esa segunda pregunta es donde la arquitectura realmente empieza a importar.
🌐 STON.fi: app.ston.fi
📝 Blog de STON.fi: blog.ston.fi
#STONfi #TON #Omniston #DeFi: #CrossChain $HYPE $TRUMP $G
