DxSale pierde $7.3M tras hackeo a proveedores de liquidez (LP) en BNB Chain

DxSale pierde $7.3M tras hackeo a proveedores de liquidez (LP) en BNB Chain
Charles Thuo
29 may 2026, 16:11 P. M.

con tecnología de

Invezz
Comprar BIFI (exposición 'risk-off' en infraestructura de BNB Chain)

De segundo orden: la explotación golpea la infraestructura de lockers compartida, por lo que los proveedores de liquidez y los equipos de lanzamiento se moverán hacia mecanismos de bloqueo/primitivas DeFi más seguros y transparentes en BNB Chain. Comprar BIFI (Beefy Finance) como proxy del capital que rota hacia estrategias de rendimiento/LP con mayor transparencia operativa y alejándose de plataformas de bloqueo “set-and-forget” como DxSale.

Riesgo clave: La rotación de capital se mantiene dentro de BNB Chain pero fluye hacia otros lockers/herramientas de lanzamiento en lugar de BIFI, o el riesgo de contratos inteligentes de BIFI aumenta con el estrés generalizado en DeFi.

Vender DxSale (DXS)

El producto principal de DxSale es el bloqueo de liquidez, y este hack demuestra que el sistema puede ser controlado por administradores y drenado a través de más de 1.400 pools. Espere presión sobre el valor del token por daño reputacional, retiros de usuarios y posible escrutinio legal/regulatorio. Vender DXS y evitar nuevos lanzamientos vinculados a DxSale hasta que la gobernanza y los controles de contrato demuestren ser más sólidos.

Riesgo clave: DxSale demuestra rápidamente que los contratos del locker están ahora totalmente asegurados/inmutables y lanza una compensación creíble, restaurando la confianza y la demanda de DXS.

  • El exploit a DxSale drena $7.3M de más de 1.400 LPs en BNB Chain.
  • El ataque empleó cambios de control administrativo ocultos a través de 80 transferencias de carteras.
  • La falla de seguridad expuso riesgos en el diseño no inmutable del locker de DxSale.

DxSale, una plataforma con larga trayectoria para el lanzamiento de tokens y el bloqueo de liquidez, ampliamente utilizada durante el auge temprano de memecoins en BNB Chain, ha sufrido una explotación importante que drenó un estimado de $7.3 millones en fondos de proveedores de liquidez (LP).

El incidente afectó a más de 1.400 piscinas de liquidez, según el seguimiento on-chain compartido tras el suceso.

Las piscinas estaban repartidas entre múltiples proyectos de tokens más antiguos, muchos de los cuales no habían tenido desarrollo activo ni actividad de negociación en años, pero aún mantenían liquidez bloqueada dentro de los contratos de DxSale.

Es notable que la explotación no pareció dirigirse a un único token o proyecto. En cambio, impactó una capa de infraestructura compartida utilizada por cientos de despliegues, amplificando la escala de las pérdidas.

Cómo ocurrió el ataque a los LPs de BNB Chain

Análisis on-chain y desgloses de investigadores de Tahax sugieren que la explotación no fue repentina.

En lugar de eso, se desarrolló mediante una serie de cambios administrativos controlados que ocurrieron meses antes del drenado real.

Aproximadamente 269 días antes del incidente, el desplegador de DxSale supuestamente transfirió la propiedad de un contrato locker clave a una nueva cartera. La transición no fue anunciada públicamente y no se emitió ningún aviso de migración a los usuarios ni a los equipos de tokens que dependían del sistema.

Con el tiempo, el control de la propiedad no permaneció estático. Los derechos de administrador fueron, según se informa, trasladados a través de aproximadamente 80 transferencias de carteras separadas, cada una diseñada para oscurecer la pista de cambios de custodia.

Estos movimientos redujeron la visibilidad sobre quién controlaba finalmente el sistema de locker, al tiempo que mantenían intactos los privilegios administrativos.

Dos días antes de que comenzara la explotación, la propiedad se consolidó en una única cartera:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

La cartera era recién creada y, según se informa, fue financiada a través de Bybit, con actividad de enrutamiento vinculada a infraestructura de puentes cross-chain frecuentemente usada para ocultar el origen de los fondos.

A las pocas horas de esta consolidación, comenzó la actividad de drenaje de liquidez en cientos de piscinas de tokens.

Ejecución técnica del drenaje

Un desglose detallado de analistas de seguridad on-chain de Coinsult describió el mecanismo utilizado para extraer fondos del sistema de locker de DxSale.

El contrato atacante, desplegado poco antes del incidente, no estaba verificado y fue construido con Solidity 0.8.33. Funcionaba como un único orquestador, permitiendo que múltiples acciones se ejecutaran en una sola transacción mediante lógica de auto-invocación.

La secuencia de ejecución apuntó a la mecánica interna del contrato locker.

Primero, el atacante activó una función que redujo la tarifa de bloqueo a 1 wei, eliminando efectivamente las barreras de coste para modificar las posiciones bloqueadas.

A esto le siguió una segunda acción que fijó la marca temporal de expiración del bloqueo a 68 segundos después de la época Unix, restableciendo efectivamente el bloqueo a un momento que ya no protegía la liquidez depositada.

Después de esto, el parámetro de tarifa se elevó a un valor extremadamente alto, aproximadamente 1e29, que parece haber sido usado para alterar el comportamiento normal de interacción con el contrato durante la ejecución.

Una vez modificado el estado interno, el atacante inició llamadas de retirada repetidas que permitieron extraer tokens del locker.

Estos fondos fueron luego convertidos en WBNB y BNB antes de ser movidos por múltiples rutas para ocultar la pista de transacciones.

La estructura del contrato implicaba que, una vez cambiados los parámetros administrativos, el estado “bloqueado” de la liquidez ya no reflejaba restricciones reales de retirada.

Por qué el sistema de locker de LPs fue objetivo

DxSale fue ampliamente utilizado durante el auge de memecoins de 2021 en BNB Chain como herramienta por defecto para el bloqueo de liquidez.

Muchos lanzamientos de tokens dependieron de él para demostrar seguridad a los inversores iniciales bloqueando tokens de los pools de liquidez por períodos prolongados.

Sin embargo, el modelo de seguridad del sistema dependía en gran medida del control administrativo en lugar de una lógica de contrato totalmente inmutable.

Según el análisis, funciones como el ajuste de tarifas y la configuración de bloqueos seguían siendo accesibles a través de roles privilegiados de propiedad.

Los analistas de seguridad señalaron que la explotación fue posible porque el contrato locker aún tenía una clave de propietario activa capaz de modificar parámetros críticos.

Esto significaba que la liquidez “bloqueada” no estaba estrictamente aplicada por código inmutable, sino gobernada por ajustes de contrato susceptibles de modificarse.