Boltz

Empieza por la dirección. Si tienes bitcoin en la cadena principal y quieres cargar un monedero Lightning, utilizas un Submarine Swap: pagas on-chain, mediante una transacción registrada en la blockchain, y recibes por Lightning. Un Reverse Swap funciona al revés. Pagas una factura Lightning, una solicitud de pago con los datos necesarios, y puedes recoger fondos en la cadena. Un Chain Swap conecta dos cadenas, como Bitcoin y Liquid. En los dos últimos casos, tu aplicación debe emitir un claim, la transacción que realmente recoge tus fondos. Pagar no termina por sí solo tu parte del proceso. Además, en Liquid recibes L-BTC, un activo de esa red separada, no una salida normal de la cadena principal de Bitcoin. Comprueba también la red de destino antes de confirmar. [1]

Imagina que el servidor te da una dirección y un importe. Sin más comprobaciones, solo estarías confiando en que coinciden con el swap acordado. El cliente Boltz, la aplicación que se ejecuta en tu dispositivo, debe calcular el importe y comprobar el hash de pago de la factura Lightning. El hash es una huella calculada que vincula el pago al intercambio correcto. También verifica la dirección y el script, las condiciones que determinan quién puede gastar los fondos y cuándo. Con Taproot, una forma de construir una salida de Bitcoin, esto incluye las claves y el árbol de scripts, que organiza las posibles condiciones de gasto. No se espera que hagas estos cálculos a mano: importa usar un cliente que sí los haga. El código abierto de boltz-web-app permite revisarlo, pero no demuestra por sí solo que otra integración o la aplicación cargada en tu navegador sea correcta. [5] [9]

Una dirección de swap no es una cuenta donde acumular poco a poco el importe necesario. La documentación de Boltz exige una única transacción lockup, el primer envío que bloquea los fondos según las reglas del intercambio. Los pagos posteriores a esa dirección no se suman; solo el primero se usa para el swap. Si envías menos de lo debido, no mandes automáticamente la diferencia. En un Chain Swap, el cliente puede ofrecer una nueva cotización basada en lo recibido en lugar de devolverlo. Debe quedar tiempo suficiente, el importe ha de respetar los límites y no puede haberse creado una firma de refund, o devolución. También hacen falta fondos disponibles en el servicio. Es un procedimiento concreto para un Chain Swap mal financiado, no una forma general de completar cualquier envío fallido. [2] [8]

Para comparar costes, sigue todo el recorrido y no solo el porcentaje anunciado. Boltz cobra por el servicio y las transacciones en cada cadena tienen costes propios. En un Reverse Swap, el dato técnico onchainAmount indica el importe que Boltz bloquea para ti después de considerar su comisión de lockup. Todavía no es el neto que llega al monedero, porque también pagas tu claim, la transacción que recoge los fondos. En un Chain Swap pagas además tu envío inicial. Compara, por tanto, el gasto total con lo que finalmente recibes. Tarifas, mínimos y límites dependen de la dirección y del par de redes, y pueden cambiar con las condiciones de la red. Un ejemplo publicitario antiguo no es una oferta actual. [6]

Si un Submarine Swap o un Chain Swap falla después de enviar fondos, recuperarlos puede requerir una transacción tuya. Necesitas la clave de refund y los datos guardados del swap. Con Taproot, la cooperación de Boltz puede permitir un key path refund más rápido, una devolución firmada conjuntamente sin esperar la condición temporal. Sin cooperación, el script path permite devolver los fondos conforme al script previsto una vez cumplido el timelock, la restricción temporal de las reglas de la transacción. Esa posibilidad no emite nada por sí sola: debe hacerlo el cliente. Es distinto cancelar un pago Lightning aún no liquidado de un Reverse Swap, liberando los fondos pendientes. De ahí no se deduce una devolución automática tras cualquier fallo de la aplicación o un claim que no se haya realizado a tiempo. [3]

En un Reverse Swap, liquidar el pago Lightning y recoger tus fondos en la cadena son hechos distintos. El estado invoice.settled puede significar que Boltz recibió el preimage, un valor secreto que permite completar el pago vinculado a su hash. El servidor no sigue si tu aplicación emite realmente el claim después. El cliente debe comprobar su propia salida, los fondos destinados a ti, y recogerlos antes del timeout, el límite tras el cual la otra parte puede recuperarlos. Una aplicación cerrada, datos perdidos o una comisión demasiado baja pueden complicar el final. Una notificación puede despertar la aplicación, pero no sustituye una transacción emitida. Evalúa el resultado por la recepción real, no solo por un aviso verde de éxito. [1] [2]

Una copia normal del monedero puede no contener todo lo necesario para un swap pendiente. Boltz Rescue Key es un conjunto de palabras de respaldo para un procedimiento compatible de recuperación. Swap Restore permite reconstruir los swaps UTXO admitidos, que trabajan con salidas individuales de transacciones todavía no gastadas. El cliente deriva un xpub, una clave pública extendida para localizar los swaps asociados, y las claves privadas correspondientes. Para el claim también debe recuperar correctamente el preimage. Un seed cualquiera, el secreto inicial de otra aplicación, no sirve automáticamente: deben coincidir el método de derivación y el formato de recuperación. Las claves privadas permanecen en el dispositivo. Enviar el xpub no permite gastar, pero revela el historial de swaps al servidor de Boltz. Guarda también los registros del cliente concreto y los posibles archivos refund antiguos junto con la copia habitual del monedero. [4] [2]

Una transacción puede aparecer en la red antes de entrar en un bloque. Aceptarla entonces se llama 0-conf, sin confirmaciones. Según su documentación, Boltz no acepta estos depósitos de usuarios en la cadena principal de Bitcoin debido a la adopción de full-RBF: reglas que, bajo ciertas condiciones, permiten sustituir una transacción sin confirmar por otra con mayor comisión incluso sin haber indicado inicialmente esa posibilidad. En un Reverse Swap, en cambio, quien recibe asume el riesgo si acepta una transacción sin confirmar. Las reglas de un par de redes no se pueden extender a todos los demás. Tampoco una documentación accesible demuestra que el servicio tenga ahora fondos suficientes para tu transferencia. Antes de pagar, comprueba los parámetros actuales, el tiempo disponible y el estado de ese swap. [7] [6]