Kasplex pierde reservas de ZEAL y NACHO tras una falla en su indexador KRC-20

Una falla en el indexador de Kasplex permitió que un atacante moviera 186.425.259 ZEAL y 54.397.983.246 NACHO sin controlar la clave privada de la cartera puente. El incidente no comprometió el consenso de Kaspa, pero dejó tokens KRC-20 sin respaldo y hundió hasta 99,6 % del valor en KAS de algunos fondos de liquidez.
***

• Un atacante falsificó cinco transferencias de ZEAL y NACHO mediante una firma vacía aceptada por el indexador.
• Los fondos de liquidez afectados perdieron entre 94 % y 99,6 % de su valor en KAS.
• Igra suspendió operaciones clave mientras los operadores preparan un parche y una reindexación del historial.

---

Kasplex pierde reservas de ZEAL y NACHO por una falla en su indexador KRC-20.

Un atacante falsificó 5 transferencias con una firma vacía y movió 186,4M ZEAL y 54,4B NACHO sin la clave privada.

La liquidez cayó hasta 99,6%. Igra pausó operaciones y prepara un parche. pic.twitter.com/WrT8Iq5fHH

— Diario฿itcoin (@DiarioBitcoin) September 21, 2026

Un atacante sustrajo 186.425.259 ZEAL y 54.397.983.246 NACHO desde una cartera de custodia del puente KRC-20 de Kaspa sin disponer de su clave privada, según informó Bitcoin.com. La operación no vulneró la cadena base de Kaspa, pero sí engañó a un indexador fuera de cadena para que reconociera transferencias que nadie había firmado, dejando tokens puenteados sin respaldo completo.

Después de mover los activos, el atacante los recicló como depósitos aparentemente normales del puente, los acuñó en las redes de capa dos de Igra Labs y Kasplex L2, y los vendió en fondos de liquidez de Zealous Swap. Cuando terminó la secuencia, algunos fondos habían perdido entre 94 % y 99,6 % de su valor en KAS, mientras los saldos de ZEAL y NACHO controlados por el atacante en esas redes quedaron vacíos.

Causas de movimientos recientes

(a) Confirmado: el movimiento de los fondos estuvo directamente relacionado con el ataque al indexador de Kasplex. Zealous Swap informó que sus operaciones habían sido pausadas después de que un atacante explotara el indexador KRC-20 de Kasplex en Kaspa L1 y utilizara el puente para acuñar ZEAL y NACHO sin respaldo en Igra y Kasplex. La pérdida de liquidez se produjo cuando esos tokens fueron introducidos en los fondos afectados. No hay base suficiente para atribuir el incidente a una causa distinta del exploit.

Una transferencia válida para Kaspa, falsa para el indexador

Los tokens KRC-20 no dependen exclusivamente del consenso de Kaspa para determinar la propiedad de cada unidad. Sus instrucciones viajan dentro de transacciones de la red, pero un indexador de Kasplex interpreta esos datos fuera de cadena y construye el registro que indica qué dirección posee cada token.

En condiciones normales, una transferencia incluye una clave pública, las instrucciones correspondientes al token y una firma válida. El atacante conservó la estructura esperada, pero presentó una firma vacía y añadió la operación OP_NOT después de OP_ENDIF, una combinación que permitió que el script fuera considerado válido por la capa de consenso.

Una firma vacía hace que OP_CHECKSIG devuelva falso, en lugar de provocar el rechazo inmediato de la transacción, mientras que OP_NOT invierte ese resultado y lo convierte en verdadero. Kaspa, por tanto, procesó una transacción válida desde el punto de vista de sus reglas, aunque el indexador debía haber comprobado que el script coincidiera exactamente con el formato canónico de KRC-20.

La diferencia entre ambas capas resultó decisiva: la red principal no registró un fallo de consenso, pero el indexador interpretó como legítima una transferencia falsificada. La API de Kasplex incluso devolvió el indicador «opAccept: 1» en la primera operación falsa de ZEAL, una señal de que el sistema reconoció el movimiento antes de que los operadores detectaran el problema.

Cinco transacciones y reservas expuestas

El atacante no necesitó descubrir credenciales ocultas ni comprometer la clave privada de la cartera puente. Una dirección estándar de Kaspa expone la clave pública necesaria para construir la operación KRC-20 manipulada, por lo que trasladar los tokens a otra dirección no elimina el riesgo mientras el indexador conserve la misma lógica permisiva.

En total, cinco transacciones falsificaron las transferencias de ZEAL y NACHO desde la dirección de custodia. También se registraron nueve retiros pequeños de una unidad que sí fueron firmados por el servicio custodial y que, de acuerdo con la información disponible, parecen haber servido como pruebas para verificar si la vía de salida funcionaba antes de mover cantidades mayores.

El monedero de custodia contenía aproximadamente otros 50 tokens KRC-20, pero el atacante eligió dos reservas concretas. Esa selección concentró el impacto en ZEAL y NACHO, cuyos activos fueron reenviados a la misma dirección de custodia como si fueran depósitos ordinarios, antes de acuñarse en las redes de capa dos y terminar en los fondos de liquidez de Zealous Swap.

Bitcoin.com reportó que Igra calculó que todas las tenencias de ZEAL y NACHO de la cartera de custodia habían sido sustraídas. Como consecuencia, quedaron 97.651.212 ZEAL y 42.570.879.908 NACHO en redes de capa dos sin respaldo completo en la capa uno, mientras otros 4.500 millones de NACHO permanecían en manos del atacante en Kaspa L1.

Suspensiones, pérdidas y una reparación pendiente

Igra suspendió las salidas de iKAS hacia Kaspa L1 y las transferencias hacia Hyperlane después de identificar la anomalía. La empresa también advirtió a los usuarios que no hicieran puentes con tokens KRC-20, no compraran ZEAL o NACHO en los intercambios descentralizados de capa dos y no añadieran liquidez a los fondos afectados.

Las advertencias buscaron evitar que nuevos participantes compraran activos cuyo respaldo ya no coincidía con los saldos representados en las redes secundarias. Al mismo tiempo, se indicó que los activos nativos KAS, el consenso de Kaspa y los activos de Igra que no fueran tokens KRC-20 puenteados no resultaron afectados por el incidente.

El parche por sí solo no resolverá la discrepancia histórica. Los operadores de KRC-20 deben actualizar el indexador, rechazar firmas vacías, detectar etiquetas malformadas y descartar scripts que continúen después de OP_ENDIF; además, tendrán que reindexar el historial para eliminar las transferencias que el sistema aceptó de forma incorrecta.

Nacho the Kat afirmó que la comunidad pretende avanzar hacia el estándar KCC-20, diseñado para incorporar las reglas de los tokens dentro de scripts que la propia red se encarga de hacer cumplir. El caso vuelve a mostrar que un activo puede depender de componentes fuera de la cadena principal y que una validación más flexible de lo previsto puede convertir una transacción técnicamente válida en una pérdida económica.

El incidente ocurre en un periodo de mayor presión sobre la seguridad de los servicios relacionados con criptomonedas. En las semanas recientes también se reportaron problemas en Blink Wallet, donde fueron vaciadas unas pocas docenas de cuentas custodiales, y en las carteras de la aplicación DCENT App Wallets, aunque esos episodios son distintos del fallo que afectó a Kasplex.

---

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.