El hackeo de Liquid Network drena 320 millones de dólares y luego devuelve la mayor parte de los Bitcoin
El hackeo de Liquid Network extrajo casi 4.000 BTC de la cartera de la federación de la sidechain el 6 de septiembre, lo que representaba aproximadamente el 95 % de sus reservas declaradas. Los actores no identificados se autodenominaron white hats y exigieron una corrección de software antes de devolver el dinero.
Inicialmente, esa afirmación ofrecía poca tranquilidad. La retirada ya había convertido Bitcoin de Liquid aparentemente sin respaldo en bitcoin real mediante un proceso de peg-out autorizado. Liquid pausó la actividad de la red, mientras los exchanges suspendieron los depósitos y retiros relacionados con su activo respaldado por Bitcoin.
La historia cambió después. Los actores devolvieron 3.400 BTC tras afirmar Blockstream que los nodos de puente afectados habían sido parcheados. Sin embargo, aproximadamente 598,5 BTC, valorados en cerca de 47 millones de dólares al momento de la información, seguían bajo su control el 8 de septiembre.
No se trató de una vulneración de la propia red Bitcoin. Fue un fallo dentro de Liquid, una sidechain federada que utiliza software y operadores designados para conectar su activo interno con Bitcoin. Esta distinción protege a la capa base de Bitcoin frente al incidente, pero también expone la promesa central que Liquid debe reparar ahora.
El hackeo de Liquid Network convirtió una retirada válida en un vaciamiento de reservas
El hecho determinante no es simplemente que se movieran bitcoin, sino que la maquinaria normal de canje de Liquid habría aprobado el movimiento.
Liquid Network reveló que aproximadamente 4.000 BTC, valorados entonces en unos 320 millones de dólares, habían sido retirados de su cartera de federación. Antes del incidente, la cartera contenía presuntamente unos 4.200 BTC.
Por tanto, la retirada eliminó alrededor del 95 % del saldo de esa cartera. Según la información inicial sobre el incidente de seguridad, Liquid desactivó los nodos de puente y se coordinó con los exchanges para detener los depósitos y retiros de L-BTC.
Liquid Bitcoin, normalmente escrito como L-BTC o LBTC, representa bitcoin transferido a la sidechain Liquid. La documentación de Liquid indica que cada LBTC debería estar respaldado por una cantidad equivalente de BTC mantenida por la federación.
El proceso de conversión se denomina anclaje bidireccional. Un peg-in bloquea bitcoin y crea el LBTC correspondiente. Un peg-out destruye LBTC y libera bitcoin de la cartera de la federación.
Los actores aparentemente atacaron la contabilidad antes de la retirada, en lugar de robar las claves de firma de la cartera. SideSwap afirmó que 4.000 LBTC llegaron a su servicio de peg-out con autorización válida. El servicio quemó esos tokens y la federación liberó alrededor de 3.996 BTC a la dirección de Bitcoin proporcionada.
SideSwap afirmó que sus sistemas y su Peg-out Authorization Key no fueron comprometidos. Una Peg-out Authorization Key, o PAK, restringe las retiradas a operadores registrados y formatos de destino aprobados.
Esta distinción importa porque la transacción pasó por los canales previstos. La federación no necesariamente detectó una solicitud de retirada claramente falsificada. En cambio, habría procesado tokens que nunca debieron existir sin una garantía coincidente.
Los actores no identificados colocaron posteriormente un mensaje corto dentro de una transacción de Bitcoin. Afirmaron: “somos whitehats. contáctanos on chain”.
El campo OP_RETURN de Bitcoin permite que una transacción incluya una pequeña cantidad de datos arbitrarios. En este caso, se convirtió en un canal público de comunicación entre los actores y Blockstream.
Blockstream respondió con instrucciones de contacto, seguidas de mensajes cifrados y firmados criptográficamente. Los actores dijeron entonces que devolverían el dinero después de que cada nodo afectado recibiera una corrección.
Esa secuencia hizo que el exploit de Liquid Network fuera inusualmente visible. Cualquiera podía inspeccionar las transacciones y los mensajes, incluso mientras las identidades e intenciones de los actores seguían siendo desconocidas.
Por tanto, el vaciamiento produjo dos registros simultáneos. Liquid y SideSwap describieron la respuesta operativa, mientras Bitcoin conservó la retirada, los mensajes posteriores y la eventual devolución parcial.
El software aceptó Bitcoin que nunca fue depositado
El fallo reportado rompió la relación entre el suministro de LBTC y la reserva de bitcoin sin comprometer las claves de la federación.
SideSwap afirmó que Blockstream rastreó el incidente hasta un error en Elements, el software de código abierto sobre el que se basa Liquid. Según ese relato, la vulnerabilidad permitió a los actores crear LBTC sin respaldo.
Ese mecanismo ataca el invariante más importante de cualquier puente de activos. Un sistema nunca debe liberar más de su activo de reserva de lo que los usuarios bloquearon previamente.
La documentación de anclaje de Liquid describe un modelo estricto de uno a uno. Cada LBTC debería corresponder a bitcoin mantenido por la federación. Destruir un LBTC debería liberar un BTC.
Si el software acepta una transacción inválida que aumenta el suministro de la sidechain, esa garantía falla antes de que comience el peg-out. El atacante puede entonces presentar LBTC recién creados a un servicio de retirada legítimo.
El servicio de retirada ve tokens autorizados. Los quema según lo previsto y pide a la federación que libere bitcoin real. Cada componente puede parecer desempeñar su función asignada, aunque el resultado para todo el sistema sea inválido.
Esta es la inversión central del hackeo de Liquid Network. Según los informes, los controles de autorización funcionaron, pero autorizaron una reclamación basada en una contabilidad de suministro corrompida.
El diseño multifirma de la cartera de la federación no evitó ese resultado. Multisignature significa que varios titulares de claves designados deben aprobar una transacción antes de que la reserva pueda moverse.
Ese acuerdo protege contra una clave robada o un firmante malicioso. No detecta automáticamente un fallo ascendente de consenso o validación que presenta una retirada como legítima.
Un análisis on-chain publicado por Bitquery rastreó dos pequeños peg-ins antes de la gran retirada. Los investigadores también identificaron actividad de prueba y patrones criptográficos repetidos en Liquid antes de la transacción final.
Su reconstrucción de la transacción informó de un pago de 3.996 BTC de la federación a las 14:28 UTC del 6 de septiembre. El análisis también documentó los mensajes intercambiados tras la retirada.
Estos hallazgos sugieren preparación, más que una transacción accidental. Sin embargo, los actores no se han identificado públicamente ni han proporcionado una divulgación técnica completa.
Algunos informes han relacionado el fallo con la validación de pruebas de rango. Una prueba de rango es evidencia criptográfica de que el importe oculto de una transacción confidencial sigue siendo válido y no crea activos de forma indebida.
Liquid utiliza Confidential Transactions, que ocultan los activos e importes transferidos al tiempo que permiten a los nodos de la red comprobar la validez de las transacciones. Un fallo en ese proceso de comprobación puede ser especialmente grave porque los nodos se basan en pruebas, no en importes visibles.
La causa raíz exacta todavía requiere un análisis postmortem detallado de Blockstream. La información pública respalda la conclusión más amplia de que LBTC sin respaldo entraron en la ruta de peg-out, pero no establece cada paso técnico.
Esa brecha de verificación debe mantenerse explícita. Una reconstrucción plausible no equivale a una divulgación completa del proveedor, un parche auditado o una reproducción independiente.
La seguridad de Liquid Bitcoin depende ahora de demostrar más que la integridad de las claves. Blockstream debe mostrar por qué los nodos aceptaron el estado inválido, qué versiones se vieron afectadas y cómo el parche bloquea variantes relacionadas.
La promesa uno a uno de Liquid está ahora bajo presión
El incidente presiona a Liquid porque la promesa de su producto depende tanto de la validación criptográfica como del criterio operativo de la federación.
Liquid está diseñada para ofrecer una liquidación más rápida y mayor privacidad de las transacciones que la red base de Bitcoin. También admite activos como stablecoins y valores tokenizados.
Estas características proceden de una blockchain separada con supuestos de confianza diferentes. Los mineros de Bitcoin no validan las transacciones de Liquid, y las reglas de consenso de Bitcoin no imponen el suministro de LBTC.
En su lugar, Liquid depende de una federación de functionaries para firmar bloques y gestionar el anclaje bidireccional. Otros participantes de la federación pueden prestar servicios, pero la seguridad del sistema no reproduce la minería de Bitcoin.
Este modelo no es inherentemente defectuoso. Toda sidechain o puente introduce supuestos adicionales de software, gobernanza y custodia. Los usuarios aceptan esos supuestos a cambio de capacidades no disponibles en la capa base.
El incidente expuso cómo interactúan esos supuestos durante un fallo. Liquid pudo pausar su red, desactivar nodos de puente, coordinarse con exchanges, distribuir un parche y negociar con los actores.
Estas acciones limitaron daños adicionales. También demostraron que la respuesta de emergencia de Liquid depende de operadores identificables que pueden detener infraestructura e influir en el movimiento de activos.
Bitcoin no se pausó. Sus mineros continuaron procesando bloques, incluidas las transacciones que contenían los mensajes de los actores y los fondos devueltos.
Este contraste no significa que todas las aplicaciones deban ejecutarse directamente sobre Bitcoin. Significa que los usuarios deben separar la seguridad de Bitcoin de la seguridad de los activos que representan bitcoin en otros lugares.
La propia visión técnica general de Liquid describe nodos de puente, hardware de los functionaries, controles de firma y mecanismos de recuperación de emergencia. La arquitectura combina criptografía con coordinación institucional.
La presión recae ahora sobre Blockstream y la federación para explicar cómo fallaron conjuntamente esas capas. Decir que no se comprometieron claves privadas responde solo a una parte de la cuestión.
Los usuarios también necesitan saber por qué los firmantes liberaron bitcoin por LBTC creados de forma indebida. Los exchanges necesitan pruebas de que reanudar los depósitos no puede exponerlos a una discrepancia de suministro sin resolver.
Los emisores de activos afrontan una preocupación relacionada. Liquid afirmó que otros activos emitidos no se vieron afectados, pero la pausa de la red siguió interrumpiendo la infraestructura compartida que los transporta.
Un activo puede mantenerse técnicamente intacto mientras resulta temporalmente difícil de transferir o canjear. La disponibilidad operativa se convierte, por tanto, en parte de la evaluación de seguridad.
La recuperación parcial mejoró la posición de reservas, pero no borró el evento. Un sistema anunciado como respaldado uno a uno perdió brevemente la mayor parte del bitcoin que sustentaba esa afirmación.
Los 598,5 BTC restantes también plantean una cuestión contable. Blockstream debe explicar cómo afecta el importe pendiente al respaldo de LBTC, los pasivos y cualquier compromiso de recuperación.
Un activo devuelto no revierte la pérdida de disponibilidad, la incertidumbre de mercado ni la necesidad de controles en los exchanges. Tampoco demuestra que no quede una vulnerabilidad relacionada en otra parte.
Los operadores de Liquid enfrentan tanto una auditoría técnica como una prueba de credibilidad. La primera pregunta si el error está corregido. La segunda pregunta si los usuarios pueden verificar esa respuesta de forma independiente.
Una devolución parcial no resuelve la cuestión del white hat
La devolución de 3.400 BTC respalda la intención declarada por los actores, pero retener casi 600 BTC impide una conclusión clara de white hat.
Después de que Blockstream afirmara que sus nodos de puente habían sido parcheados, los actores transfirieron 3.400 BTC de vuelta a la dirección de la federación. La transacción restauró aproximadamente el 85 % del importe retirado.
Una actualización sobre la recuperación del 8 de septiembre informó que casi 47 millones de dólares en bitcoin seguían pendientes de recuperación. Las conversaciones sobre el saldo continuaban.
Los actores habían indicado previamente a Blockstream que corrigiera primero el fallo. Afirmaron que todos los nodos necesitaban el parche antes de poder devolver los fondos de forma segura.
Ese mensaje coincide con un aspecto del trabajo de seguridad de sombrero blanco. Publicar o demostrar una vulnerabilidad antes de remediarla puede exponer a otros usuarios a ataques imitadores.
Sin embargo, la divulgación responsable convencional suele comenzar con un informe privado y pruebas coordinadas. No empieza retirando el 95 % de la reserva de un sistema sin autorización documentada.
Por tanto, la etiqueta de los actores es una afirmación, no una condición profesional verificada. El uso inicial de Liquid de la expresión “presuntos hackers de sombrero blanco” preservó adecuadamente esa incertidumbre.
Los fondos restantes agudizan la cuestión. Ninguna evidencia pública revisada para este artículo establece que Blockstream aprobara una recompensa de 598,5 BTC.
Sin dicha aprobación, retener las monedas puede parecer una tarifa unilateral, una herramienta de presión para negociar o la posesión continuada de activos apropiados indebidamente. La devolución parcial por sí sola no puede determinar el motivo ni la responsabilidad legal.
Tampoco existe una identidad pública con la que los lectores puedan evaluar experiencia, autorización o conducta previa. Una firma on-chain demuestra el control sobre una dirección, no el carácter ético de quien la controla.
Esta ambigüedad tiene un precedente histórico. En 2021, un atacante retiró más de 600 millones de dólares de Poly Network y posteriormente devolvió la mayor parte de los activos.
Poly Network calificó a ese atacante como sombrero blanco y ofreció una recompensa. La cobertura contemporánea de Poly Network mostró cómo una devolución importante podía cambiar la narrativa pública sin eliminar las cuestiones legales o de gobernanza.
El caso de Liquid no es idéntico. El mecanismo reportado, los activos, los operadores y las comunicaciones difieren. Aun así, ambos incidentes muestran cuán rápidamente un “hacker” pasa a ser un “sombrero blanco” cuando la recuperación depende de la cooperación.
Ese lenguaje puede cumplir una función práctica durante las negociaciones. Atacar públicamente a una contraparte cooperativa podría reducir las probabilidades de recuperar los fondos.
Sin embargo, la diplomacia operativa no debe sustituir a la clasificación de seguridad. Un investigador autorizado, un explotador oportunista y un extorsionador pueden devolver fondos por razones distintas.
La evidencia útil procederá de la resolución final de los BTC restantes y de cualquier acuerdo divulgado. Un informe técnico completo también podría aclarar si los actores intentaron antes un contacto privado.
Hasta entonces, la descripción más precisa sigue siendo sombreros blancos autodenominados o presuntos. Calificar la operación como una prueba de seguridad aprobada excedería la evidencia disponible.
El exploit revive un viejo problema para los puentes de Bitcoin
La arquitectura de Liquid difiere de la de muchos puentes cripto, pero el fallo sigue un patrón conocido: una reclamación falsa llegó a una reserva que contenía activos reales.
Los sistemas cross-chain concentran riesgo porque traducen actividad entre entornos con reglas de seguridad diferentes. Un sistema debe decidir si un evento en otro sistema justifica liberar valor.
En el caso de Liquid, esa decisión conecta LBTC en la sidechain con BTC retenido en Bitcoin. La cartera de la federación es la reserva, mientras que las reglas de validación de Liquid rigen las reclamaciones sobre ella.
El fallo reportado creó una discrepancia entre esos dos libros contables. La sidechain aceptó LBTC sin bitcoin correspondiente, y después el proceso de peg-out atendió la reclamación falsa.
Un patrón económico similar ha aparecido en otros incidentes de puentes. El exploit de Wormhole en 2022 permitió a un atacante crear activos envueltos sin el depósito que debería haberlos respaldado.
El puente de Ronin falló por una vía distinta. Los atacantes obtuvieron suficientes claves de validadores para autorizar retiradas de su reserva.
Estos mecanismos difieren técnicamente, pero alcanzan el mismo punto de presión. El puente debe mantener una relación estricta entre las reclamaciones emitidas y la garantía bloqueada.
Los datos históricos muestran por qué ese límite recibe un escrutinio sostenido. Chainalysis estimó que los atacantes robaron 2.000 millones de dólares en 13 hackeos de puentes durante parte de 2022.
Su análisis de riesgos de puentes indicó que esos incidentes representaban el 69 % de las criptomonedas robadas ese año en el momento de la publicación. Las cifras describen 2022, no el mercado actual, pero la lección arquitectónica sigue siendo relevante.
Los puentes acumulan activos en ubicaciones predecibles. Su código de validación y sus políticas de firmantes también crean vías estrechas por las que pueden moverse grandes reservas.
La federación de Liquid proporciona un conjunto de operadores más estructurado que un puente de contratos inteligentes anónimo. Puede coordinar actualizaciones, detener servicios y comunicarse directamente con exchanges.
Estas ventajas ayudaron a la respuesta. No detuvieron el drenaje inicial de la reserva porque la vulnerabilidad reportada estaba en la lógica que determina qué transacciones eran válidas.
Esta distinción debería orientar las futuras auditorías. Probar solo la custodia de claves y los controles de acceso pasará por alto fallos de inflación, validación de pruebas y consistencia de estado.
Los auditores también deberían probar toda la ruta de canje. Esa ruta incluye la creación de activos, la validación, la autorización, la quema, la firma de la federación y el pago final en Bitcoin.
El exploit de Liquid Network demuestra por qué la corrección local es insuficiente. SideSwap afirma que su clave de autorización permaneció segura; aun así, su servicio válido pasó a formar parte de un resultado de sistema inválido.
Los firmantes de la federación también parecen haber seguido las reglas previstas. Según los informes, el defecto cambió la información que recibían esas reglas.
Por lo tanto, los operadores necesitan controles que comparen múltiples fuentes de verdad. Los cambios de suministro, el historial de peg-in, el volumen de peg-out y el movimiento de reservas deberían conciliarse antes de que se complete una retirada extraordinaria.
Una única solicitud que implique la mayor parte de las reservas también debería recibir una revisión excepcional, incluso si las reglas del protocolo la marcan como válida. La validez del software y la plausibilidad operativa son comprobaciones distintas.
Ese enfoque introduce fricción, algo que Liquid fue diseñado en parte para reducir. El compromiso de seguridad es inevitable cuando una liquidación más rápida puede mover casi una reserva entera por una sola vía.
Tres señales decidirán si Liquid ha contenido los daños
La siguiente etapa depende del bitcoin pendiente, una explicación técnica reproducible y un retorno controlado a las operaciones normales.
La primera señal son los 598,5 BTC restantes. Una devolución completa reforzaría el relato de sombrero blanco de los actores, aunque no establecería retroactivamente una autorización.
Una recompensa negociada también podría resolver el saldo, pero solo si Blockstream divulga información suficiente para distinguir un acuerdo de una retención unilateral. El silencio continuado o el movimiento hacia direcciones no relacionadas debilitarían la interpretación de sombrero blanco.
La segunda señal es el informe técnico posterior al incidente de Blockstream. Debería identificar las versiones vulnerables de Elements, la regla de validación que falló, la ruta de transacción afectada y la protección precisa del parche.
Una divulgación útil también debería explicar si desarrolladores independientes reprodujeron el fallo. La reproducción importa porque una descripción cerrada deja a los usuarios dependientes de la misma organización cuyo software falló.
El informe debería abordar el momento de la detección. El análisis público de transacciones sugiere que hubo actividad preparatoria antes del peg-out principal, lo que plantea preguntas sobre la monitorización y los umbrales de anomalías.
La tercera señal es el proceso de reinicio de Liquid. Los exchanges y los usuarios necesitan una ruta definida para depósitos, retiradas y verificación de reservas antes de que se reanude la actividad habitual.
Reiniciar los nodos del puente no equivale a restaurar la confianza. Los operadores deben conciliar el suministro de LBTC con el bitcoin retenido por la federación tras la devolución parcial.
También deberían explicar cómo se cubre el déficit restante. Esa respuesta determina si los tenedores asumen alguna exposición residual o si otra parte la absorbe.
Un reinicio prudente incluiría comprobaciones de versión en los functionaries y los nodos del puente. También ofrecería una confirmación visible de que el software obsoleto no puede volver a conectarse a la red de producción.
La cuestión más amplia sobre la seguridad de Liquid Bitcoin seguirá vigente después de que se reanuden los servicios. La federación debe demostrar que ha añadido defensas tanto contra el defecto divulgado como contra fallos de validación comparables.
Para los desarrolladores, la lección es seguir las garantías de seguridad a través de los límites entre componentes. Una clave protegida no puede rescatar un sistema que autoriza la transacción equivocada.
Para los exchanges, la lección es supervisar la garantía de forma independiente. La apariencia normal de un token no garantiza que su relación con la reserva permanezca intacta.
Para los tenedores de activos, la pregunta inmediata es más sencilla. Deberían seguir los avisos oficiales del servicio, los datos de reservas y el estado de las retiradas en los exchanges antes de considerar cerrado el incidente.
La devolución parcial convirtió una pérdida catastrófica en una crisis recuperable. No restableció por sí sola la promesa de paridad uno a uno.
El hackeo de Liquid Network solo estará contenido cuando se resuelva el saldo restante, el fallo se comprenda de forma independiente y las retiradas normales se reanuden con reservas conciliadas. Hasta que esas condiciones sean visibles, “la mayoría de los fondos ha sido devuelta” es una actualización, no un final.
