Un error de validación vinculado a Ironwood habría permitido crear 39,8 millones de ARRR, cerca de una quinta parte de la oferta en circulación, según el reporte citado. El equipo pidió a los usuarios que no movieran sus fondos y propuso regresar la cadena al estado del 14 de octubre a las 20:00 UTC.
***
- Según el reporte, el equipo atribuyó el problema a dos fallos de validación relacionados con Ironwood, actualización activada el 3 de octubre.
- Las monedas presuntamente creadas sin autorización habrían pasado al pool blindado Sapling, lo que podría dificultar su rastreo.
- Pirate Chain propuso descartar los bloques posteriores a las 20:00 UTC del 14 de octubre; el reporte también señala que NonKYC restringió operaciones vinculadas al incidente.
🚨 Pirate Chain propone revertir la cadena tras una presunta emisión de 39,8 millones de ARRR, cerca del 20% de la oferta circulante.
El equipo atribuye el incidente a fallos de validación de Ironwood y pide no mover fondos.
La reversión propuesta aún no está confirmada. NonKYC… pic.twitter.com/fC8hHqB3Kz
— Diario฿itcoin (@DiarioBitcoin) October 16, 2026
Pirate Chain propone revertir la cadena tras la presunta creación no autorizada de 39,8 millones de ARRR
Un fallo de validación vinculado a la actualización Ironwood habría permitido crear cerca de 39,8 millones de ARRR sin autorización, una cantidad equivalente a aproximadamente el 20% de la oferta en circulación, según un reporte de Crypto Briefing publicado el 15 de octubre de 2026. Pirate Chain pidió a sus usuarios que no movieran fondos mientras el equipo evaluaba una reversión de la blockchain para retirar los bloques asociados al incidente.
El reporte indica que la red seguía funcionando, pero que el equipo también recomendó a exchanges y pools de minería pausar voluntariamente sus operaciones. La propuesta apunta a devolver la cadena a su estado de las 20:00 UTC del 14 de octubre y descartar los bloques producidos después de ese momento.
Dos fallos asociados a Ironwood
La vulnerabilidad salió a la luz el 14 de octubre, después de que el equipo relacionara la presunta creación no autorizada de monedas con dos fallos de validación separados, según el reporte. Ambos estaban vinculados a Ironwood, una actualización que Pirate Chain activó el 3 de octubre. Por tanto, el problema se habría reportado cuando el nuevo software llevaba 11 días en funcionamiento.
En una blockchain, las reglas de validación determinan qué transacciones y cambios de saldo puede aceptar la red. Según la descripción del incidente, los fallos habrían permitido que un atacante generara ARRR que no correspondían a una emisión autorizada, en lugar de limitarse a transferir monedas existentes entre usuarios. El reporte no detalla el mecanismo técnico de cada error, por lo que no permite precisar cómo se habría producido la emisión.
El reporte cifra la cantidad en 39,8 millones de ARRR y la sitúa cerca del 20% de la oferta en circulación en ese momento. Esa proporción se refiere a la oferta circulante, no a la oferta máxima del proyecto.
El equipo no habría reportado indicios de que el incidente comprometiera las claves notariales de Pirate Chain ni su criptografía zk-SNARKs, según el reporte. Esa aclaración acota lo que se conoce del problema, pero no elimina la falla de validación descrita: el origen se habría encontrado en la forma en que el software comprobó las reglas de la red tras la actualización Ironwood.
Las monedas llegaron al pool blindado Sapling
Después de la presunta creación no autorizada, las monedas se habrían movido rápidamente al pool blindado Sapling, según el reporte. Pirate Chain usa transacciones protegidas por zk-SNARKs de forma obligatoria, de modo que la privacidad no opera como una opción que el usuario pueda activar o desactivar para cada movimiento.
Ese diseño puede tener consecuencias durante una investigación: según la descripción del equipo recogida en el reporte, el carácter blindado de las transacciones podría dificultar el seguimiento de los fondos una vez que entran al pool. La información citada no ofrece un recorrido posterior de las monedas ni identifica destinos finales, por lo que no permite afirmar si el atacante consiguió convertirlas o retirarlas.
NonKYC respondió restringiendo depósitos relacionados con el exploit y bloqueando retiros para limitar el riesgo adicional, según el reporte. La medida buscó impedir que las monedas señaladas se movieran desde el exchange hacia otros activos, aunque la información publicada no precisa cuántos depósitos quedaron afectados ni cuánto ARRR logró detener la plataforma.
El equipo pidió a los usuarios que mantuvieran quietos sus fondos y recomendó a los exchanges y pools de minería suspender voluntariamente su actividad. La coordinación resulta clave porque una reversión no depende únicamente de anunciar una decisión: mineros y operadores de nodos tendrían que dejar de procesar la cadena anterior y adoptar el estado que el equipo propone recuperar.
Una reversión que exige coordinación
La propuesta de Pirate Chain consiste en regresar la red al estado que tenía a las 20:00 UTC del 14 de octubre y descartar los bloques producidos después de ese momento. El plan busca eliminar de la historia aceptada por la red los bloques posteriores a esa hora, en vez de permitir que la emisión no autorizada permanezca en circulación. La propuesta fue reportada, pero la información citada no confirma que la reversión ya se haya ejecutado.
La reversión también plantea un desafío operativo: si algunos participantes siguen construyendo sobre la cadena antigua mientras otros adoptan la versión recuperada, la red podría quedar dividida entre historiales diferentes. El reporte subraya por eso la importancia de la pausa voluntaria de exchanges y pools de minería, aunque no confirma que todos los actores hayan detenido sus operaciones.
El equipo describió la red como activa y, al mismo tiempo, pidió precaución a sus usuarios mientras definía cómo revertir el daño, según el reporte. Esas dos circunstancias no se contradicen necesariamente: una blockchain puede continuar produciendo bloques mientras sus responsables coordinan una intervención, pero la continuidad por sí sola no aclara qué historial terminará aceptando la mayoría de los participantes.
La información citada tampoco confirma que la reversión se haya completado ni fija una hora para reanudar las operaciones normales. Entre los puntos pendientes están si el regreso al estado de las 20:00 UTC se completa, cuándo exchanges y pools vuelven a operar y si el equipo publica un desglose técnico de los dos fallos de validación.
El alcance del incidente para una moneda privada
Pirate Chain se distingue por hacer obligatorio el uso de zk-SNARKs en sus transacciones, en contraste con redes donde la privacidad puede ser opcional. Esa característica protege la información de las transferencias, pero el incidente también muestra por qué la precisión de las reglas de emisión y validación resulta especialmente importante cuando los observadores externos tienen menos herramientas para seguir movimientos dentro de un pool blindado.
La privacidad no aparece identificada como la causa técnica del presunto exploit: el problema se habría vinculado a dos fallos de validación asociados a Ironwood. Sin embargo, el uso de Sapling podría complicar el rastreo posterior de las monedas, según la descripción atribuida al equipo, y desplaza parte de la capacidad de respuesta hacia los desarrolladores y los participantes que pueden coordinar una pausa o una modificación del historial.
El caso también pone en primer plano una decisión delicada para una red descentralizada: corregir el incidente mediante una reversión implica acordar qué bloques conservar y cuáles descartar. El reporte presenta la medida como una propuesta del equipo, no como una operación ya completada, por lo que su resultado dependerá de la coordinación entre quienes mantienen y utilizan la red.
Por ahora, la recomendación atribuida al equipo es no mover fondos, mientras intenta contener las consecuencias del fallo y acuerda los pasos técnicos de recuperación. La resolución permitirá conocer si Pirate Chain logra descartar la emisión no autorizada y restablecer la actividad, así como si puede explicar con suficiente detalle cómo Ironwood habría permitido crear ARRR a esta escala.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Estafas
Sharjah desmantela cuatro redes de ciberdelincuencia y arresta a 33 sospechosos
Europa
Anthropic libera Code Review con hasta USD $50.000 en créditos, pero excluye a empresas europeas
AltCoins
LIT cae 10,08% el 15 de octubre y eleva la presión sobre los compradores
AltCoins
