Liquid pausa su puente tras la salida de 4.000 BTC: qué ocurrió con L-BTC

Liquid Network suspendió la actividad de su puente después de que cerca de 4.000 BTC —unos 320 millones de dólares según la cotización de entonces— salieran de la cartera de la federación que respalda L-BTC. La retirada equivalía a alrededor del 95% de la reserva reportada. La información disponible apunta a un presunto fallo de inflación en el software Elements, no a un robo de claves de la federación ni de la clave de autorización de SideSwap; sin embargo, los detalles técnicos públicos siguen siendo incompletos. 413

Qué se habría producido

La secuencia reportada es relativamente clara, aunque la vulnerabilidad de fondo todavía no se ha explicado por completo:

1. Un actor habría creado L-BTC sin que existiera BTC bloqueado como respaldo, debido a un fallo de Elements.
2. Ese L-BTC se habría enviado al servicio habitual de peg-out —salida de Liquid hacia la red principal de Bitcoin— de SideSwap.
3. La operación utilizó la clave de autorización de peg-out o PAK de SideSwap, que Liquid y SideSwap afirman que no fue comprometida.
4. La infraestructura de la federación de Liquid autorizó una salida de BTC. Los reportes sitúan el pago en unos 3.996 BTC y el total del incidente en torno a 4.000 BTC. 26

En otras palabras, el problema reportado no sería el robo de las claves que controlan la reserva. La hipótesis es que una retirada superó las comprobaciones de autorización del sistema pese a que el L-BTC presentado para el canje no tenía un respaldo económico legítimo.

Por qué los HSM pudieron firmar sin que se robaran claves

Liquid utiliza un modelo de Strong Federation: sus miembros operan colectivamente la cadena lateral y controlan la reserva de BTC mediante firmas de umbral. La documentación técnica de Liquid denomina a este modelo de consenso Strong Federations.

Los módulos de seguridad de hardware, o HSM, protegen las claves de firma y aplican las políticas configuradas. No son un árbitro independiente que reconstruya todo el historial de emisión y compruebe, por sí solo, que cada unidad de un activo tenga respaldo válido.

Si una solicitud de peg-out presenta elementos que el sistema reconoce como correctos —incluida una ruta de autorización válida—, los HSM pueden firmarla sin que nadie haya extraído una clave privada. Esa es la diferencia esencial en este caso reportado:

• Autorización: el peg-out se habría procesado usando la PAK legítima de SideSwap.
• Procedencia y respaldo: el L-BTC canjeado habría sido creado mediante un fallo de Elements, no a través de una emisión normal respaldada por BTC. 2

SideSwap declaró que la salida de unos 4.000 BTC pasó por su servicio como una orden de cliente, que su PAK no fue comprometida y que el L-BTC procedía de un fallo de Elements, no de los sistemas de SideSwap.

Por tanto, la lectura reportada no es que fallaran la criptografía de las firmas de umbral ni los HSM. Un defecto compartido de validación o emisión puede hacer que firmantes automáticos, funcionando conforme a sus reglas, autoricen una retirada que nunca debió poder ejecutarse. Una firma válida demuestra que se cumplió la política de firma; no demuestra por sí sola que el activo canjeado estuviera correctamente respaldado.

¿Eran realmente «white hats»?

Los actores adjuntaron un mensaje en cadena que decía: “we are whitehats. contact us on chain” («somos white hats; contáctennos en cadena»). 16

También se informó de que Blockstream/Liquid contactó con ellos mediante mensajes firmados en cadena y de que ofrecieron devolver «la mayor parte» de los fondos una vez que la vulnerabilidad estuviera corregida en toda la red. 418

Estos elementos indican que los actores alegaron actuar como investigadores de seguridad y dejaron un canal de comunicación. No demuestran de forma independiente que sean white hats. Al momento de los reportes, no se había confirmado la devolución de los fondos, ni la publicación de un parche, ni la reapertura de la red. 13

Por eso, la descripción más precisa es la de supuestos white hats. Esa etiqueta no debería darse por buena hasta que se verifiquen de manera independiente la devolución, los detalles del exploit y la corrección aplicada.

La respuesta de Liquid, SideSwap y los exchanges

Liquid desactivó los nodos del puente y pausó operaciones, interrumpiendo el movimiento normal entre Bitcoin y Liquid. También avisó a los exchanges para que pausaran, o se prepararan para pausar, los depósitos y retiros de L-BTC. 48

SideSwap indicó que suspendió los peg-ins —entradas desde Bitcoin a Liquid— y los peg-outs mientras Liquid siguiera pausada.

Son medidas de contención: limitan nuevos movimientos por el puente mientras los operadores investigan la vulnerabilidad reportada, evalúan el estado de las reservas y definen las condiciones para un reinicio seguro. El plan de recuperación reportado dependía de corregir el fallo, actualizar los nodos afectados y resolver qué ocurrirá con los BTC retirados. 1318

Qué implica para quienes tienen L-BTC

L-BTC está diseñado para representar BTC dentro de Liquid. Pero, en la práctica, su equivalencia con BTC canjeable depende de que el puente esté operativo y de que su respaldo sea creíble.

Con unos 4.000 BTC retirados de una reserva reportada de aproximadamente 4.200 BTC, y con el puente pausado, el canje ordinario de L-BTC quedó interrumpido. El déficit de reserva reportado pasó a ser el problema inmediato para los tenedores. 313

Esto no determina todavía el resultado final. Sí significa que, durante el incidente, tener L-BTC no era operativamente equivalente a tener BTC que pudiera retirarse libremente en la capa base de Bitcoin. El desenlace dependerá de la recuperación de fondos, la corrección del presunto fallo, las decisiones de la federación y las políticas de los proveedores de servicios.

Otros activos emitidos en Liquid

Que hayan salido BTC de la cartera de la federación no implica automáticamente que otros activos emitidos en Liquid hayan perdido las reservas de sus emisores. Liquid afirmó que activos como USDT, DePix y los RWA no se vieron afectados directamente por el incidente.

No obstante, «no afectados» no significa «sin riesgo». Una pausa de red puede afectar el acceso a billeteras, el soporte de los exchanges, la liquidez, la disponibilidad de transacciones y el uso de L-BTC como activo para comisiones y puente. El respaldo directo de cada activo sigue dependiendo de su propio emisor y de su esquema de custodia; su uso operativo depende de que la infraestructura de Liquid vuelva a funcionar con normalidad.

La lección de arquitectura: federación frente a un puente tipo BitVM

El diseño actual de Liquid se apoya en una federación conocida y autorizada que controla la reserva de Bitcoin mediante firmas de umbral. Es distinto de un modelo en el que el consenso de Bitcoin verifica directamente que cada canje tiene respaldo.

Peg federado actual	Dirección propuesta tipo BitVM de 1 de n
Una federación fija controla la reserva de Bitcoin mediante firmas de umbral.	Blockstream lo describe como una iniciativa de investigación a largo plazo, no como un reemplazo ya desplegado para Liquid.
La seguridad depende de la protección de claves, la operación de los firmantes y la corrección del software común de validación y políticas.	El objetivo es reducir los supuestos de confianza frente a los diseños convencionales de firmas de umbral.
Un fallo de software compartido puede llevar a todos los firmantes automáticos a aceptar la misma interpretación inválida.	Los sistemas tipo BitVM emplean verificación optimista y mecanismos de impugnación; su seguridad depende de un diseño correcto y de que exista al menos un impugnador honesto y activo.

Un modelo tipo BitVM no elimina el riesgo de los puentes: lo traslada a otras condiciones. Los impugnadores deben poder y querer actuar, el proceso de pruebas de fraude debe ser correcto y las retiradas pueden ser más complejas o lentas. La investigación sobre puentes basados en BitVM caracteriza el objetivo de seguridad como un sistema que requiere al menos un participante honesto, mientras que BitVM2 busca permitir que cualquiera impugne una afirmación inválida durante la ejecución.

Si se confirma el mecanismo reportado, el caso de Liquid ilustra por qué importa esta diferencia. Una federación de firmas de umbral puede resistir el robo de claves y, aun así, quedar expuesta si todos sus firmantes dependen de la misma interpretación defectuosa del software sobre si un activo es válido para su canje.

En síntesis

El incidente reportado de Liquid, valorado en unos 320 millones de dólares, parece una crisis de validación del puente y no un robo convencional de claves privadas. Un lote de L-BTC presuntamente sin respaldo habría atravesado una ruta de peg-out autorizada, lo que llevó a la federación a liberar BTC reales. 24

Las preguntas pendientes son relevantes: cuál fue exactamente la vulnerabilidad de Elements, cuál es la posición final de reservas y respaldo de L-BTC, si se devuelven los fondos y qué controles deberán cambiar antes de reanudar el puente. Hasta que esas respuestas sean verificadas públicamente, el episodio debe tratarse como un caso no resuelto, no como una divulgación rutinaria de un white hat ni como una interrupción técnica menor.