# Liquid Network: el fallo que movió casi 4,000 BTC Un fallo en Elements permitió retirar casi 4,000 BTC de Liquid. Reconstruimos el incidente, la devolución y las dudas aún abiertas. - URL: https://miguelramos.net/blog/liquid-network-fallo-movio-casi-4000-btc/ - Fecha: 2026-09-07 - Autor: Miguel Ramos - Tags: Ciberseguridad, Infraestructura --- import liquidPegOut from '@img/liquid-elements-peg-out-figure-1.png'; import liquidBitcoinReturn from '@img/liquid-bitcoin-return-figure-2.png'; Liquid Network sufrió uno de los incidentes más graves registrados en una infraestructura vinculada con Bitcoin: actores que se identificaron como hackers de sombrero blanco consiguieron retirar casi 4,000 BTC de la reserva que respalda a L-BTC. El movimiento equivalía entonces a unos 320 millones de dólares. La historia no terminó con la salida de los fondos. Después de una conversación pública mediante transacciones de Bitcoin, mensajes `OP_RETURN` y comunicaciones cifradas con PGP, los responsables devolvieron 3,400 BTC. Cerca de 598.5 BTC aproximadamente 47 millones de dólares al precio de ese momento permanecieron bajo su control. El incidente expuso un riesgo distinto al robo tradicional de claves: una operación puede estar correctamente firmada y recorrer un canal autorizado, pero partir de un estado que el software aceptó erróneamente como válido. ## Qué es Liquid Network Liquid es una sidechain de Bitcoin diseñada para transferencias rápidas y confidenciales, emisión de activos y liquidaciones entre empresas. Funciona como una red independiente conectada con Bitcoin mediante un mecanismo bidireccional. Cuando un usuario mueve BTC hacia Liquid, los bitcoins quedan bloqueados y se emite una cantidad equivalente de L-BTC. En sentido contrario, un `peg-out` destruye L-BTC y libera BTC desde la reserva de la federación. La premisa económica es que cada L-BTC legítimo permanezca respaldado uno a uno por bitcoin real. La red no utiliza el mismo modelo de seguridad de la capa base de Bitcoin. Según la documentación de [Blockstream sobre la Liquid Federation](https://help.blockstream.com/liquid-network/faqs/what-is-the-liquid-federation), más de 80 empresas participan en la federación y un subconjunto opera los functionaries: servidores especializados que producen bloques y administran el vínculo con Bitcoin mediante hardware de seguridad y una billetera multifirma. Los miembros autorizados también pueden ofrecer servicios de peg-out. Para ello utilizan Peg-out Authorization Keys, conocidas como PAK, que permiten reconocer los destinos habilitados para recibir BTC desde la reserva. ## La salida de casi toda la reserva El 6 de septiembre de 2026, la cuenta oficial de [Liquid Network](https://x.com/Liquid_BTC?lang=en) informó que aproximadamente 4,000 de los 4,200 BTC almacenados en la billetera de la federación habían sido retirados por actores descritos como “presuntos white hats”. El valor estimado rondaba los 320 millones de dólares. La cobertura de [Reuters](https://www.reuters.com/technology/bitcoin-based-liquid-network-says-320-million-withdrawn-hack-2026-09-07/) confirmó que Liquid detuvo las operaciones nuevas, advirtió que las billeteras se verían afectadas y comunicó que la salida había utilizado infraestructura asociada con SideSwap. Liquid deshabilitó sus bridge nodes y pidió a los exchanges suspender temporalmente los depósitos y retiros de L-BTC. Otros activos emitidos dentro de la sidechain, como stablecoins y activos tokenizados, no fueron retirados directamente durante el incidente. Bitcoin tampoco fue vulnerado. Las transacciones de la red principal continuaron operando normalmente. El fallo afectó la lógica y la reserva de Liquid, una infraestructura separada que representa BTC mediante L-BTC. ## Una operación autorizada basada en L-BTC inválidos La primera explicación oficial detallada llegó desde [SideSwap](https://x.com/side_swap/status/2096709838310928674), servicio utilizado para convertir L-BTC nuevamente en BTC. SideSwap informó que a las 14:05 UTC un cliente envió 4,000 L-BTC a su servicio de peg-out. El sistema procesó la solicitud como cualquier otra operación: verificó la autorización, destruyó los L-BTC y solicitó la liberación del bitcoin correspondiente. A las 14:28 UTC, la Liquid Federation había enviado aproximadamente 3,996 BTC a la dirección indicada por el cliente. Posteriormente, Blockstream determinó que los L-BTC presentados en esa operación habían sido creados mediante un fallo en Elements, el software de código abierto sobre el que funciona Liquid. SideSwap aseguró que ni sus sistemas ni su PAK habían sido comprometidos. Desde su perspectiva, los tokens recibidos eran indistinguibles de otros L-BTC y cumplían las condiciones que el servicio esperaba para iniciar el peg-out. El flujo puede resumirse así: 1. Un fallo de Elements permitió crear o aceptar L-BTC sin respaldo equivalente. 2. Los tokens llegaron al servicio autorizado de SideSwap. 3. SideSwap inició un peg-out válido y destruyó los L-BTC. 4. Los functionaries interpretaron la solicitud como legítima. 5. La federación liberó BTC reales desde su reserva.
--- No fue necesario falsificar las firmas de los miembros ni robar una clave de autorización. El sistema firmó una salida que parecía correcta porque el problema había ocurrido antes, al validar el estado de los L-BTC. ## Lo que todavía no explica un postmortem oficial Hasta el momento de redactar este artículo, Blockstream no había publicado un informe técnico final con la causa raíz, las versiones afectadas, el código vulnerable y la secuencia completa de explotación. Investigadores externos han señalado una posible deficiencia en la caché utilizada para verificar range proofs, una parte importante de las transacciones confidenciales de Elements. Estas pruebas permiten confirmar que las cantidades ocultas de una transacción cumplen determinadas condiciones sin revelar públicamente sus valores. La hipótesis plantea que un resultado de verificación almacenado en caché pudo reutilizarse bajo un contexto distinto al original. Esto habría permitido que ciertos nodos aceptaran una salida inválida, mientras otros la rechazaban. Sin embargo, esa reconstrucción no debe presentarse todavía como la explicación oficial definitiva. El dato confirmado por Liquid y SideSwap es más limitado: los L-BTC utilizados en el peg-out fueron creados a través de un bug de Elements y las claves conocidas no habían sido comprometidas. ## El primer mensaje de los responsables Después de recibir los BTC, quienes controlaban la dirección dejaron un mensaje dentro de una transacción de Bitcoin: > “we are whitehats. contact us on chain” El uso de `OP_RETURN` permite adjuntar una pequeña cantidad de datos a una transacción sin que esos datos funcionen como una salida gastable. En este caso se convirtió en un canal público para demostrar que los mensajes procedían de direcciones relacionadas con los fondos. Blockstream respondió enviando una pequeña transacción con su dirección de contacto de seguridad. A partir de ese momento comenzó una conversación que combinó texto visible, mensajes cifrados y firmas PGP. Una [reconstrucción técnica publicada en GitHub](https://gist.github.com/Sjors/9d24363e67529079cc2ae4305ff90fcd) documenta la secuencia, deriva las direcciones implicadas a partir de las transacciones y verifica las firmas con la clave de seguridad publicada por Blockstream. El hecho de que un mensaje esté firmado es distinto a que esté cifrado. La firma permite verificar quién lo emitió y si fue alterado. El cifrado limita quién puede leerlo. ## La condición para devolver los fondos Los actores propusieron enviar “la mayoría” de los BTC a una dirección de la federación. También solicitaron que Blockstream corrigiera primero la vulnerabilidad y confirmara que todos los nodos relevantes habían recibido el parche. Parte de la información técnica fue enviada en un mensaje cifrado mediante la clave pública de Blockstream. La cadena confirma la existencia y el destinatario criptográfico de esa comunicación, pero no permite al público leer su contenido. Solo quien posea la clave privada correspondiente puede descifrarla. Por eso no es posible comprobar públicamente si aquel mensaje incluía una explicación completa del fallo, una prueba de concepto, instrucciones exactas para corregirlo o condiciones económicas privadas. Blockstream respondió con mensajes firmados mediante PGP. Primero confirmó la dirección propuesta y posteriormente comunicó que los bridge nodes ya estaban parcheados y que era seguro devolver los fondos. La auditoría disponible en [GitHub](https://gist.github.com/Sjors/9d24363e67529079cc2ae4305ff90fcd) verificó que esas firmas coincidían con la clave oficial de seguridad de la empresa. ## La devolución de 3,400 BTC Después de la confirmación de Blockstream, el actor transmitió una operación que devolvió 3,400 BTC a la dirección de la federación. La transacción quedó registrada en el bloque 965,950 de Bitcoin.
--- La actualización de [The Block](https://www.theblock.co/news/defi/2026-09-07-liquid-network-attacker-says-they-will-return-most-of-4000-btc-after-bug-fix-413673) documentó la devolución y el saldo restante: aproximadamente 598.5 BTC, valorados entonces en 47.3 millones de dólares, continuaron en la dirección controlada por el actor. | Movimiento | Cantidad aproximada | | --- | ---: | | BTC controlados después de las salidas | 3,998.5 BTC | | BTC devueltos a la federación | 3,400 BTC | | BTC restantes bajo control del actor | 598.5 BTC | | Proporción devuelta | 85% | | Proporción restante | 15% | Las cantidades expresadas en dólares son referencias temporales. El saldo en BTC puede verificarse independientemente del precio de mercado, mientras su valor en moneda fiduciaria cambia constantemente. ## Los 598.5 BTC no son una recompensa confirmada La devolución parcial ha sido presentada en redes sociales como un acuerdo mediante el cual los responsables cobraron su propia recompensa. La evidencia pública no permite llegar todavía a esa conclusión. Los mensajes visibles muestran que el actor habló de regresar “la mayoría” de los fondos. Blockstream confirmó la dirección de retorno y comunicó que el parche estaba instalado, pero ninguna de esas comunicaciones establece públicamente: - Una recompensa de 600 BTC. - Un porcentaje autorizado del 15%. - Un acuerdo de bug bounty. - Permiso para conservar definitivamente el saldo. - Una renuncia de la federación a reclamar los fondos restantes. La cobertura de [Bitcoin.com](https://news.bitcoin.com/security/liquid-hackers-return-3400-btc-keep-47m-as-network-stays-frozen/) señala igualmente que no existe un mensaje público que describa el remanente como una recompensa acordada. Tampoco se trata de bitcoins técnicamente congelados. Los 598.5 BTC quedaron bajo el control criptográfico del actor y pueden volver a moverse. Su permanencia podría formar parte de una negociación privada, ser una retención temporal o representar una recompensa impuesta unilateralmente. Sin una declaración de las partes, ninguna de esas posibilidades puede tratarse como un acuerdo confirmado. ## ¿Puede considerarse una operación de sombrero blanco? Los responsables se identificaron como white hats, pero Liquid utilizó deliberadamente la expresión “purported white-hat hackers”: presuntos hackers de sombrero blanco. Un investigador que trabaja dentro de un programa autorizado conoce de antemano el alcance, las pruebas permitidas, el proceso de divulgación y las reglas de pago. Retirar casi toda una reserva y decidir después qué proporción devolver se encuentra fuera de las prácticas habituales de un bug bounty. Existen elementos que respaldan parcialmente la intención declarada: los actores advirtieron del fallo, mantuvieron los fondos rastreables, solicitaron que la vulnerabilidad fuera reparada antes de devolverlos y finalmente regresaron el 85%. También existe un elemento imposible de ignorar: alrededor de 47 millones de dólares permanecieron bajo su control sin que se haya publicado un acuerdo que lo autorice. La etiqueta definitiva dependerá del resultado de la negociación, de la devolución o disposición del saldo y de cualquier investigación legal posterior. ## Por qué este fallo es especialmente relevante La seguridad de una red federada no depende únicamente de proteger las claves. También depende de que todos los firmantes interpreten correctamente el estado que se les presenta. En un robo convencional, una firma no autorizada puede apuntar al compromiso de una clave, una semilla o un HSM. En este caso, las firmas aparentemente fueron auténticas y el canal de peg-out estaba autorizado. El problema fue que el software permitió llegar hasta ese canal con activos cuyo respaldo no existía. Esto convierte el incidente en una lección sobre validación compartida: - Una multifirma protege contra la actuación unilateral, pero no necesariamente contra un error de consenso que todos los firmantes aceptan. - Una PAK limita los destinos autorizados, pero no demuestra por sí sola que los tokens presentados para redención fueron emitidos correctamente. - Un servicio puede seguir sus reglas y aun así participar en una pérdida si el estado de entrada ya está contaminado. - Ejecutar código reciente en infraestructura crítica introduce riesgos incluso cuando las claves permanecen seguras. - La prueba de reservas debe considerar tanto el BTC custodiado como la cantidad legítima de activos emitidos contra esa reserva. ## Qué falta por conocer La devolución de 3,400 BTC redujo considerablemente el déficit inmediato, pero no cierra el incidente. Todavía se necesita información oficial sobre varios puntos: 1. La causa raíz exacta dentro de Elements. 2. Las ramas, versiones y configuraciones afectadas. 3. Por qué determinados nodos aceptaron el estado inválido. 4. Qué controles podían haber detenido el peg-out antes de liberar BTC. 5. Cómo se reconstruirá y verificará el respaldo uno a uno de L-BTC. 6. Cuándo se restablecerán completamente los bridge nodes y servicios asociados. 7. Qué ocurrirá con los 598.5 BTC restantes. 8. Si existió o existirá una recompensa formal. Hasta que Blockstream o la Liquid Federation publiquen un postmortem, cualquier descripción más específica del exploit debe distinguir claramente entre datos oficiales, observación de la cadena e hipótesis de investigadores externos. ## Conclusión El incidente de Liquid Network no fue un hack contra Bitcoin ni el resultado conocido de claves privadas robadas. Fue una falla en una infraestructura federada construida sobre Elements que permitió presentar L-BTC creados o aceptados incorrectamente ante un servicio legítimo de peg-out. El flujo autorizado terminó liberando casi 4,000 BTC reales desde la reserva. La comunicación posterior también quedó registrada públicamente: los actores se identificaron como white hats, pidieron que todos los nodos fueran parcheados y recibieron confirmaciones firmadas por Blockstream. Después devolvieron 3,400 BTC en el bloque 965,950. Los aproximadamente 598.5 BTC restantes no constituyen una recompensa confirmada. Siguen bajo control del actor y no existe una declaración pública que establezca que Blockstream o la federación hayan autorizado su retención. Más allá del desenlace financiero, el caso demuestra una limitación esencial de los sistemas federados: las firmas legítimas y las claves protegidas no bastan cuando el software que determina qué debe firmarse acepta un estado inválido.