DxSale Publica Aclaración sobre Incidente: Contratos de Bloqueo de Liquidez v2 y Posteriores Permanecen Inafectados
DxSale Publica Aclaración sobre Incidente: Contratos de Bloqueo de Liquidez v2 y Posteriores Permanecen Inafectados
Un reciente incidente de explotación en la cadena BNB con un bloqueador de liquidez reavivó una pregunta familiar en DeFi: ¿puede la "infraestructura antigua" volver a ser peligrosa cuando la cadena subyacente evoluciona? A finales de mayo de 2026, los atacantes se dirigieron a bloqueos de liquidez heredados de DxSale, que datan de 2021, provocando movimientos de fondos en la cadena y una ola de preocupación entre los proyectos que alguna vez dependieron de la arquitectura temprana de bloqueo de DxSale.
En una aclaración de seguimiento publicada alrededor del 30 o 31 de mayo de 2026 (dependiendo de la zona horaria), DxSale declaró que el problema está aislado a su contrato de bloqueo v1 y que las versiones v2 y posteriores (v2, v3, etc.) no se vieron afectadas, informándose que los contratos posteriores fueron auditados y los activos bloqueados de los usuarios permanecieron seguros.
A continuación, se presenta un desglose práctico de lo sucedido, por qué las características de ejecución "atómicas" a nivel de cadena pueden sacar a la luz casos extremos en contratos antiguos y qué deben hacer los LP y los equipos de tokens a continuación.
Qué Sucedió en la Cadena BNB (29 de mayo de 2026)
El 29 de mayo de 2026, surgieron informes de que aproximadamente 1.400 posiciones de LP antiguas, principalmente de la era de 2021, fueron drenadas en la cadena BNB, con pérdidas estimadas en alrededor de 7,3 millones de dólares. Múltiples análisis que rastrearon el incidente señalaron que el atacante utilizó un enfoque consistente con la manipulación de propiedad/control privilegiado, y luego canalizó activos a través de intercambios y depósitos.
Una dirección de atacante citada frecuentemente en el incidente es:
- 0xC4574DDE...2EeaFA69 — visible en el rastreo de direcciones de BscScan
Los resúmenes públicos también describieron al atacante consolidando fondos en BNB, moviendo 2.958 BNB (~1,87 millones de dólares en ese momento) a dos billeteras principales, y luego canalizándolos a direcciones de depósito de exchanges y realizando intercambios a través de PancakeSwap. Para una visión general accesible del incidente, consulte el informe de Cointelegraph reflejado en TradingView.
El Punto Clave de DxSale: El Radio de Acción es Solo v1
La aclaración de DxSale enfatiza tres afirmaciones clave:
- Los contratos afectados son los contratos tempranos de bloqueo de liquidez "v1" lanzados en 2021
- Los contratos de bloqueo v2 y posteriores no se vieron afectados
- Los contratos de generación posterior se construyeron bajo una arquitectura diferente y han sido sometidos a revisión de seguridad / auditoría
Si bien los usuarios siempre deben verificar las direcciones de los contratos y el alcance de la auditoría para su bloqueo específico, puede cotejar el historial de seguridad y auditoría de proyectos de DxSale a través de la página del proyecto Skynet de CertiK para DxSale.
Para los usuarios no familiarizados con las versiones en DxSale, la propia documentación de DxSale distingue los bloqueadores más nuevos (por ejemplo, documentación de bloqueo de liquidez DxLock V2), lo que ayuda a confirmar qué herramientas y generación de contratos utilizó un proyecto determinado.
Por Qué las "Transacciones Atómicas" Pueden Romper Viejas Suposiciones
DxSale atribuyó la causa raíz a un problema de compatibilidad entre el estilo de ejecución de "transacción atómica" más nuevo de BNB Chain y el diseño temprano del bloqueador v1.
En los ecosistemas EVM modernos, "atómico" a menudo se refiere a agrupar múltiples acciones en una única transacción de todo o nada (de modo que los estados intermedios nunca persistan). Esta dirección se aceleró en 2025-2026 a través de una adopción más amplia de la abstracción de cuentas y primitivas de lotes, incluidos los mecanismos al estilo EIP-7702.
BNB Chain ha discutido públicamente las actualizaciones de billeteras inteligentes y abstracción de cuentas; consulte el anuncio del hard fork Pascal de BNB Chain. Para el estándar subyacente que popularizó los conceptos de delegación/lote de transacciones únicas, consulte el EIP-7702 en EIPs de Ethereum.
La lección clave para la seguridad en DeFi
Incluso cuando un contrato heredado "ha funcionado durante años", los nuevos patrones de transacción pueden invalidar modelos de amenaza antiguos, especialmente si el contrato dependía de privilegios de administrador, flujos de propiedad inusuales o suposiciones sobre cómo se pueden componer las llamadas.
Esta es una de las razones por las que las conversaciones sobre seguridad en DeFi en 2025-2026 se centran cada vez más en:
- El riesgo de contratos inmutables versus actualizables,
- Los roles con privilegios y los límites de propiedad,
- Y si los contratos siguen siendo seguros bajo nuevas características de la cadena y entornos de ejecución.
Qué Deben Hacer Ahora los Proveedores de Liquidez y los Equipos de Tokens
1) Confirme qué versión del bloqueador utilizó su LP
Si usted es un miembro de la comunidad en un proyecto antiguo de BNB Chain, no asuma que "bloqueado" significa seguro. Pida al equipo que proporcione:
- la dirección exacta del contrato del bloqueador,
- el ID del bloqueo / página del bloqueo,
- y confirmación de si es v1 vs v2+.
Si solo tiene una dirección, comience con BscScan e inspeccione el tiempo de creación del contrato, las funciones de propiedad y las transacciones históricas.
2) Trate la "auditoría" como necesaria, no suficiente
Las auditorías reducen el riesgo, pero no lo eliminan, especialmente a medida que el comportamiento de la cadena evoluciona. Utilice las referencias de auditoría como punto de partida y luego evalúe:
- ¿Siguen presentes las funciones privilegiadas?
- ¿Se puede cambiar la propiedad?
- ¿Hay parámetros controlados por el administrador que afecten los retiros?
3) Suponga que los atacantes atacarán contratos olvidados
El incidente ilustra un patrón recurrente: los atacantes a menudo cazan liquidez inactiva y contratos heredados porque el monitoreo es más débil y los respondedores son más lentos.
4) Proteja sus claves de firma durante migraciones y acciones de emergencia
Incidentes como este a menudo desencadenan "migraciones urgentes", que son el momento ideal para el phishing y las solicitudes de firma maliciosas.
Una billetera de hardware como OneKey puede ayudar al mantener las claves privadas fuera de línea y requerir confirmación en el dispositivo para las transacciones, lo que reduce la posibilidad de que una computadora comprometida o una extensión del navegador apruebe silenciosamente acciones dañinas. Esto no soluciona un contrato DeFi vulnerable, pero mejora materialmente la seguridad operativa personal cuando interactúa con dApps bajo presión.
En Resumen
- El incidente de mayo de 2026 destaca cómo los contratos de bloqueo de liquidez heredados pueden volver a ser un riesgo sistémico, especialmente en cadenas de rápida evolución donde las características de ejecución evolucionan rápidamente.
- La declaración de DxSale enmarca el problema como aislado a los bloqueadores v1 de la era de 2021, con contratos v2 y posteriores inafectados.
- Para usuarios y equipos, la conclusión práctica es inventariar los bloqueos antiguos, verificar las versiones de los contratos y actualizar las prácticas de seguridad para que coincidan con las realidades de 2026: lotes atómicos, ejecución delegada y guiones de juego de atacantes de más rápida evolución.
Si administra tesorería o firma transacciones DeFi habitualmente en BNB Chain, considere usar OneKey como parte de una postura de seguridad más amplia: aislamiento de claves respaldado por hardware, gestión cuidadosa de permisos y flujos de trabajo de respuesta a incidentes tranquilos y verificables.
