Submarine Swap cambia normalmente bitcoin on-chain por un pago Lightning; Reverse Submarine Swap va en sentido contrario. Condiciones de hash y tiempo enlazan ambas ramas para que un cliente que verifica correctamente no entregue al servicio custodia ilimitada del principal.
En un swap normal, el usuario bloquea bitcoin on-chain y el servicio paga su factura Lightning. En Reverse Submarine Swap aporta un pago Lightning condicionado y reclama una salida on-chain. No implica necesariamente cambiar a otra moneda ni cerrar simplemente su propio canal. [Boltz — Swap types and states]
Una preimage que coincide con el hash SHA256 permite liquidar el pago vinculado y reclamar la salida bloqueada. En el flujo inverso, el cliente crea la preimage y el servicio mantiene pendiente el HTLC Lightning hasta que se revele. El claim on-chain puede revelar el secreto; la vía cooperativa puede entregarlo al servicio fuera de la cadena. Un pago pendiente no es liquidación definitiva. [Boltz — Swap types and states] [Lightning Loop — Architecture]
Antes de financiar, el cliente debe comprobar red, importes con comisiones, hash, claves, plazo y vinculación del script o árbol Taproot con la dirección de destino. La factura debe coincidir con el hash y el importe acordados. Una criptografía correcta no ayuda si la aplicación paga sin comprobar cualquier dirección de una API. [Boltz — Client verification]
Los swaps Taproot pueden usar una firma MuSig2 key-path de ambas partes, ahorrando espacio y ocultando el script. Si la contraparte no coopera, el cliente debe soportar el claim o refund script-path correspondiente. El reembolso cooperativo rápido añade una opción; no elimina la condición temporal de la recuperación unilateral. [Boltz — Claims and refunds] [Lightning Loop — Architecture]
En un swap normal fallido con fondos on-chain bloqueados, el cliente construye y difunde activamente una transacción refund; la vía unilateral espera al timelock. En un pago Lightning inverso sin liquidar, el HTLC puede cancelarse y liberar fondos sin esa transacción del usuario. Sin embargo, tras revelar la preimage no debe suponerse que un pago ya liquidado se devuelve automáticamente. [Boltz — Swap types and states] [Boltz — Claims and refunds]
Un swap tiene costes de servicio, enrutamiento y on-chain; un swap normal fallido puede añadir una comisión de reembolso. Revelar la preimage antes de confirmar el claim crea una carrera contra el plazo. Loop documenta expresamente que subir la comisión de sweep cerca del timeout puede superar el límite original. Una estimación de precio no limita incondicionalmente todos los riesgos. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]
Conserve la clave refund o rescue key y los datos del swap según el cliente utilizado; una semilla habitual de otra cartera no recupera universalmente un swap. Boltz restore deriva claves y busca swaps, pero un xpub solo no firma. También importan el script, la salida y el timeout, no solo el identificador del servicio. [Boltz — Swap restore] [Boltz — Claims and refunds]
En el flujo inverso de Boltz, invoice.settled puede significar que la factura Lightning se liquidó tras revelar la preimage, mientras Boltz no sigue si el cliente difundió el claim. Compruebe su salida de destino y las confirmaciones necesarias antes de marcarlo terminado o repetir el pago. Taproot key-path reduce la visibilidad del script, no el conocimiento del proveedor sobre importes y tiempos. [Boltz — Swap types and states] [Boltz — Client verification]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CHECKLOCKTIMEVERIFY. También enlazan con esta entrada Liquidez de Lightning, Inbound Liquidity, Boltz.