HTLC explicados para desarrolladores: la lógica detrás de los swaps con mínima confianza
Cada swap entre cadenas tiene que responder una pregunta incómoda: ¿qué impide que una de las partes se quede con el dinero y se vaya? Los HTLC son la respuesta a la que recurren la mayoría de los sistemas que minimizan la confianza, y el diseño entre cadenas de Omniston es un ejemplo funcional de cómo se ve esa respuesta en producción.
Pregunta a la mayoría de los desarrolladores qué hace un puente y te darán una respuesta razonablemente clara: bloquea activos aquí, acuña una representación allí. Pregunta a esos mismos desarrolladores cómo un swap entre cadenas sin un puente garantiza realmente que ambas partes completen, y las respuestas se vuelven más vagas muy rápido. Ese vacío vale la pena cerrarlo, porque el mecanismo subyacente, el Contrato de Timelock con Hash, es genuinamente elegante cuando ves la forma completa, y es exactamente la pieza de infraestructura que hace posible el enfoque de Omniston para los swaps entre cadenas.
Mi opinión: los HTLC se tratan como una primitiva resuelta y aburrida porque la idea central es genuinamente simple. Lo que no es aburrido es cuántas formas tiene un protocolo de atomic swap “simple” de fallar en silencio si las suposiciones de tiempo no se manejan con verdadero cuidado.
🧩 El problema que realmente resuelven los HTLC
Imagina la versión más básica de una operación cross-chain: Alice tiene USDT en Ethereum, Bob tiene TON, y quieren intercambiar directamente, de persona a persona, sin un intermediario que custodie los fondos. El enfoque ingenuo obvio — Alice envía primero y luego Bob envía — tiene un modo de fallo obvio. Si Alice envía y Bob simplemente no lo hace, Alice pierde sus fondos sin recurso. Si se invierte el orden, entonces Bob asume el mismo riesgo. Alguien siempre tiene que moverse primero, y quien lo haga queda expuesto.
Un Hashed Timelock Contract elimina esa exposición al vincular ambos lados de la operación al mismo secreto, revelado en una cadena y reutilizable para desbloquear la otra. Ninguna de las partes tiene que confiar en las buenas intenciones de la otra: la criptografía y la lógica del contrato hacen la aplicación de las reglas en su lugar.
🔻 Cómo funciona realmente el mecanismo, paso a paso
El truco central es un hash y su preimagen. Una parte genera un valor secreto, lo hashea y comparte públicamente solo el hash.
La parte que inicia bloquea fondos en la Chain A, dentro de un contrato que solo los liberará a la contraparte si esa contraparte puede producir el secreto que corresponde al hash conocido — o los reembolsará automáticamente al iniciador tras un timeout establecido.
La contraparte, al ver los fondos bloqueados y el hash, bloquea sus propios fondos en la Chain B, bajo la misma condición: liberarlos al iniciador si se revela el secreto correspondiente, o reembolsarlos a la contraparte tras un timeout más corto.
La parte que inicia revela el secreto para reclamar los fondos bloqueados en la Chain B. Este es el momento decisivo: revelar el secreto para desbloquear un lado hace que necesariamente se vuelva público.
La contraparte ahora también tiene el secreto, visible on-chain a partir de la transacción de reclamación del iniciador, y lo usa para reclamar los fondos bloqueados en la Chain A.
Si cualquiera de las partes deja de responder en cualquier punto antes de que ambos bloqueos estén establecidos, en realidad todavía no se ha movido nada: los fondos simplemente esperan hasta el timeout y se reembolsan. La única forma de robar es interrumpir el proceso después de que el secreto se vuelva público pero antes de que la otra parte reclame, y ese es בדיוק el caso que la estructura de timeout está diseñada para impedir.
⏱️ Por qué la asimetría del timeout es la parte que realmente importa
Aquí está el detalle que separa una implementación correcta de HTLC de una sutilmente rota: los dos timeouts no pueden ser iguales, y el orden en que se establecen no es arbitrario. El bloqueo de la contraparte — el segundo en crearse — necesita expirar antes de que lo haga el bloqueo del iniciador.
Mi opinión: este es el lugar más común donde he visto explicaciones de HTLC volverse vagas, tratando ambos timeouts como simétricos cuando todo el modelo de seguridad depende de que no lo sean. Si lo entiendes al revés, has construido algo que parece correcto en el caso feliz y falla exactamente cuando alguien intenta explotarlo.
Si los timeouts fueran iguales, o si el timeout del iniciador expirara primero, habría una ventana en la que el iniciador podría revelar el secreto, reclamar los fondos de la contraparte y luego también recuperar con éxito sus propios fondos originales mediante reembolso antes de que la contraparte logre usar el secreto, ahora público: se iría con ambos lados. Escalonar los timeouts para que la ventana del iniciador permanezca abierta más tiempo que la de la contraparte elimina por completo esa condición de carrera. Es un pequeño detalle de diseño con una consecuencia enorme si se pasa por alto.
🌊 Qué te aporta esto frente a un bridge clásico
Un diseño clásico de bridge bloquea los activos en un vault custodiado compartido en la cadena de origen y acuña una representación envuelta en la cadena de destino. Ese vault es un objetivo único y concentrado, y una proporción desproporcionada de las mayores pérdidas en la historia de DeFi se remonta exactamente a ese tipo de punto de custodia concentrado, no a pools AMM individuales.
Los atomic swaps basados en HTLC eliminan por completo ese objetivo concentrado. No hay un vault compartido que comprometer, porque no existe custodia compartida en ningún momento: los fondos de cada lado están en un contrato que solo la contraparte de ese lado puede reclamar, bajo condiciones impuestas por hash y tiempo, no por la honestidad de un operador. El modo de fallo también cambia de naturaleza: un bridge roto puede significar que los fondos se pierden. Un swap HTLC fallido, si está bien estructurado, significa un reembolso tras el timeout: activos que nunca dejaron realmente el control efectivo del propietario.
🔐 Dónde los HTLC siguen teniendo límites reales
Nada de esto hace que los swaps cross-chain sean libres de riesgo, y vale la pena ser honestos sobre dónde están realmente los límites del modelo. Los HTLC requieren que ambas cadenas involucradas soporten las primitivas necesarias de hashlock y timelock — algo que no está garantizado en todas las arquitecturas de cadena. También requieren liveness: si una contraparte simplemente desaparece antes de revelar nada, los fondos permanecen bloqueados hasta el timeout en lugar de estar disponibles al instante, lo cual es un costo de experiencia de usuario incluso cuando no es un fallo de seguridad. Y los HTLC por sí solos no resuelven la liquidez ni el precio: son una garantía de liquidación, no un mecanismo de routing o cotización, que es precisamente la brecha que una red de resolvers debe cubrir encima.
🧭 Dónde se sitúa realmente Omniston sobre esto
Todo lo anterior es la primitiva general. Aquí es donde deja de ser teoría y se convierte en la cosa concreta que funciona bajo un swap cross-chain de STONfi.
La capa de ejecución cross-chain de Omniston está construida exactamente sobre esta lógica de atomic swap basada en HTLC, no sobre un vault custodiado compartido. Cuando haces un swap cross-chain a través de STONfi, no existe un equivalente al pool bloqueado de un bridge funcionando como un único punto de fallo: cada tramo del swap es su propio intercambio asegurado por hash y timelock.
El resolver que compite por ejecutar tu orden cross-chain es la contraparte en el HTLC, no un custodio. Esta es la razón práctica y directa por la que la arquitectura de Omniston se describe como basada en resolvers y no en bridges: los resolvers se ganan el derecho a ejecutar tu orden compitiendo en precio, y la estructura de atomic swap es lo que los mantiene honestos sin que tengas que confiar en ellos.
El requisito de timeouts escalonados descrito arriba es exactamente por qué los swaps cross-chain en STONfi tardan más que un swap intra-chain. Ese tiempo extra no es fricción por sí misma: es la ventana que el modelo de seguridad realmente necesita para funcionar correctamente, y entender los HTLC es lo que hace que esa espera tenga sentido en lugar de parecer un retraso inexplicable.
Que un intento cross-chain fallido se reembolse en vez de desaparecer es la consecuencia directa y visible de este diseño, no una promesa del equipo de soporte. Si un resolver abandona a mitad del swap, la estructura de timeout y reembolso es lo que devuelve tus fondos automáticamente en lugar de dejarlos en una cola de tickets de soporte.
🧭 Conclusión
Los HTLC resuelven un problema específico y estrecho: cómo pueden dos partes en dos cadenas diferentes intercambiar sin que ninguna tenga que confiar en la otra ni en un intermediario; y lo hacen con una cantidad realmente pequeña de mecanismos: un hash, un secreto y dos timeouts cuidadosamente escalonados. La elegancia es real, pero también lo es la cantidad de formas en que una gestión descuidada de los timeouts puede reintroducir silenciosamente exactamente el riesgo que el diseño existe para eliminar. La capa cross-chain de Omniston es una implementación funcional de hacer bien esa maquinaria, y por eso un swap cross-chain de STONfi no necesita que confíes en un vault: solo en las matemáticas.
❓ Preguntas frecuentes
¿Qué pasa si mi contraparte nunca responde después de que bloqueo mis fondos? Tus fondos quedan bloqueados hasta que expire el timeout que fijaste, y luego se te reembolsan automáticamente. No se pierde nada: simplemente la operación no se completa.
¿Por qué el timeout de la contraparte tiene que ser más corto que el del iniciador? Si no lo fuera, habría una ventana en la que el iniciador podría reclamar ambos lados de la operación — su propio reembolso y los fondos de la contraparte — usando el mismo secreto revelado. El escalonamiento temporal cierra esa ventana.
¿Los HTLC requieren que ambas cadenas soporten el mismo lenguaje de programación o VM? No, pero ambas cadenas sí necesitan soportar funcionalidad de hashlock y timelock de alguna forma. La implementación concreta puede diferir de una cadena a otra mientras existan las primitivas básicas.
¿Un swap basado en HTLC es instantáneo, igual que un swap intra-chain? No. La estructura de timeouts escalonados y la necesidad de coordinar dos cadenas separadas hace que tarde más que un swap de una sola cadena por diseño, no por accidente.
Divulgación: Embajador oficial de STONfi.
$BTC
