Liquid Network tras el retiro de 4.000 BTC: cinco lecciones para infraestructura Web3

Una infraestructura puede conservar sus claves privadas y aun así perder el control de sus reservas. El incidente de Liquid Network es una advertencia para equipos que operan bridges, activos respaldados o flujos cross-chain.

Según la cobertura inicial de The Block y su seguimiento, cerca de 4.000 BTC salieron de la reserva de la federación mediante un peg-out con L-BTC creados a través de un fallo en Elements. La autorización PAK de SideSwap no fue comprometida, según el estado oficial inicial, pero el flujo no distinguió un activo inválidamente creado.

La lección central es directa: una autorización criptográficamente válida no garantiza que una operación sea económicamente válida.

Qué ocurrió en Liquid Network

Liquid es una sidechain de Bitcoin construida sobre Elements. Representa bitcoin como L-BTC y lo mueve entre Bitcoin y Liquid mediante peg-ins y peg-outs:

1. Un peg-in bloquea BTC y habilita L-BTC.
2. Un peg-out destruye L-BTC y libera BTC de las reservas de la federación.
3. El L-BTC redimible nunca debe superar el respaldo válido en BTC.

Según The Block, el 6 de septiembre un usuario envió 4.000 L-BTC al servicio de peg-out de SideSwap. La solicitud tenía autorización válida, los L-BTC fueron quemados y la federación envió aproximadamente 3.996 BTC. Blockstream determinó después que esos L-BTC se habían creado mediante un fallo en Elements. SideSwap dijo que no podía diferenciarlos de L-BTC ordinarios y que su clave no había sido comprometida.

El texto inicial de estado de Blockstream indicó que aproximadamente 4.000 BTC fueron retirados mediante el PAK de SideSwap, que el PAK no fue comprometido, que exchanges pausaron LBTC y que los nodos públicos del bridge fueron deshabilitados.

Actualización: 8 de septiembre de 2026

El 7 de septiembre, aproximadamente 3.400 BTC volvieron a una dirección de la Liquid Federation, cerca del 85% del retiro original. La transacción es pública en mempool.space. Al 8 de septiembre, aproximadamente 598,5 BTC seguían fuera de la billetera de la Federación, con un valor cercano a US$47 millones. No es una recompensa acordada: ni Blockstream ni Liquid habían confirmado públicamente tal acuerdo. The Hacker News también reportó la devolución parcial.

Al 8 de septiembre, el estado oficial aún describía Liquid como pausada y los nodos públicos del bridge como deshabilitados. La cobertura informó software parcheado y preparativos para un reinicio coordinado. Esto es un reporte periodístico, no un cambio del estado oficial.

Lo que dice el análisis técnico independiente

No hay un post-mortem final oficial que publique los binarios exactos usados por cada functionary.

Un análisis independiente de CertiK atribuye la falla a una construcción ambigua del hash de caché de firmas. El código concatenaba campos de longitud variable sin codificar sus longitudes. Con una entrada de caché preparada, distintos conjuntos de campos podían producir la misma secuencia de bytes y el mismo hash. El parche de Elements muestra el cambio relevante.

No es una conclusión oficial definitiva ni permite afirmar qué binario ejecutaba cada miembro. La lección para auditorías es que serializar estructuras ambiguas en límites de validación puede convertir una caché en una decisión de seguridad.

1. Una firma válida puede autorizar un estado inválido

🔐 Proteger claves, multisigs y permisos es necesario, pero no suficiente. La ruta de peg-out recibió una autorización válida, pero el activo presentado para redención no debía existir.

Separa tres propiedades:

• Autenticidad: una entidad autorizada firmó la solicitud.
• Validez: la solicitud cumplió las reglas criptográficas del flujo.
• Solvencia: el activo redimido correspondía a reservas reales y legítimas.

Un protocolo seguro verifica las tres. Si solo controla las dos primeras, puede romper su respaldo económico.

Acción recomendada: documenta las condiciones previas a liberar reservas y prueba entradas válidas que provienen de estados inaceptables.

2. Los invariantes económicos deben monitorearse en tiempo real

📊 La relación entre BTC bloqueados y L-BTC emitidos es un invariante de seguridad. Define alertas para detectar:

• aumentos de oferta sin el evento de respaldo correspondiente;
• redenciones que concentran una proporción inusual de las reservas;
• divergencias entre emisión, quema y activos custodiados;
• cambios abruptos en proveedores de peg-out;
• operaciones válidas que exceden límites históricos o de riesgo.

Una transferencia de miles de BTC debe activar límites por volumen, demoras, revisión distribuida y procedimientos de emergencia. Superpone controles independientes para que un fallo no atraviese todo el sistema.

3. El límite de confianza incluye todo el stack

🧩 La seguridad de L-BTC depende de Elements, consenso, nodos de la federación, emisión, SideSwap, autorización de peg-out y custodia. Auditar solo el componente visible deja fuera dependencias capaces de producir una pérdida total.

Una revisión cross-chain debería incluir:

• implementación del protocolo base;
• validación de emisión y destrucción;
• software y configuración de nodos;
• servicios que autorizan redenciones;
• actualizaciones y compatibilidad de versiones;
• monitoreo de reservas y oferta;
• mecanismos de pausa y recuperación.

La pregunta no es solo qué componente falló, sino qué conjunto permitió que un estado inválido alcanzara la reserva.

4. Una pausa contiene daños, pero revela centralización operativa

⏸️ Pausar Liquid pudo limitar la superficie mientras se investigaba y desplegaban correcciones. Pero también expone costos: usuarios sin depósitos o retiros, dependencia de un grupo limitado, incertidumbre para integraciones y presión para parchear rápido.

Todo sistema que pueda pausarse debe definir quién puede hacerlo, con qué evidencia, cómo se comunica y qué permite reiniciar. Un botón de emergencia sin un procedimiento probado no es un plan de respuesta.

5. “White hat” describe una intención declarada, no elimina el incidente

⚠️ La parte responsable dijo que devolvería la mayoría de los fondos tras confirmar un parche. Hubo devolución parcial, pero los BTC restantes seguían fuera de la billetera de la Federación al 8 de septiembre. La intención no cambia el análisis: los fondos salieron, la red fue pausada y el respaldo quedó expuesto.

Los equipos necesitan divulgación responsable con canales privados verificables, recompensas proporcionales al impacto, reglas para pruebas y fondos, contacto de emergencia, proceso de parches y comunicación basada en evidencia. Si un investigador debe retirar casi toda la reserva para demostrar una vulnerabilidad, el proceso ya falló.

Qué deberían revisar hoy los equipos Web3

• ¿Cada token emitido puede vincularse con respaldo verificable?
• ¿Una firma válida podría autorizar la redención de un activo creado incorrectamente?
• ¿Existen límites por operación y por período para retirar reservas?
• ¿La oferta, las quemas y la custodia se concilian de forma independiente?
• ¿Los monitores detectan estados imposibles, no solo transacciones sospechosas?
• ¿La pausa fue ensayada y tiene criterios claros de reinicio?
• ¿Las actualizaciones críticas prueban invariantes económicos contra regresiones?
• ¿La divulgación ofrece una alternativa rápida y segura a mover fondos?

Conclusión

Liquid muestra una verdad incómoda: proteger claves no protege por sí solo las reservas. Si un sistema acepta un activo inválido como legítimo, una firma correcta puede convertirse en el último paso de una pérdida masiva.

Una revisión debe abarcar código, consenso, emisión, redención, integraciones, monitoreo y respuesta. Sobre todo, debe probar los invariantes que sostienen la solvencia bajo estados adversos.

Si tu protocolo administra activos respaldados, bridges o flujos cross-chain, solicita un diagnóstico inicial a Seclat. Identificaremos estos límites de confianza y definiremos un alcance de revisión antes de que una falla llegue a las reservas.

Fuentes

• The Block, Liquid Network pausa tras el retiro de aproximadamente 4.000 BTC, 6 de septiembre de 2026
• The Block, la parte responsable afirma que devolverá la mayoría de los BTC, 7 de septiembre de 2026
• Blockstream Status, actualización del incidente de Liquid
• CertiK, Liquid Network incident analysis
• Elements, parche en sigcache.cpp
• The Hacker News, retorno de aproximadamente 3.400 BTC
• Documentación de Liquid, peg-in y peg-out