El Talón de Aquiles del Código Abierto: Nofx consigue 9.000 estrellas en dos meses — y su Hackgate, Infighting-gate y Open-source-gate

Soy un observador y analista de esta saga. Durante el auge de Nofx, desarrollé un proyecto independiente de código abierto llamado nof0, inspirado en la tendencia “Alpha Arena” de nof1, y estuve intercambiando notas técnicas con dos colaboradores clave de Nofx, Tinkle y Zack. Esa perspectiva me ayuda a ofrecer una visión más amplia, ya que esta historia no trata solo de un repositorio que creció rápidamente en GitHub — es un caso de estudio sobre cómo los proyectos que cruzan cripto e IA pueden escalar de la noche a la mañana... y también tropezar con problemas de seguridad, gobernanza y licencias exactamente igual de rápido.

Al 22 de diciembre de 2025, el repositorio de Nofx muestra unas 9.200 estrellas — crecimiento logrado en alrededor de dos meses desde finales de octubre (uno de los primeros commits referenciados en informes de seguridad tiene fecha del 31 de octubre de 2025). Puedes ver las cifras actuales aquí: GitHub: NoFxAiOS/nofx. Nofx se presenta como un “sistema operativo de trading agente” para operar criptomonedas en múltiples exchanges con modelos de IA enchufables y un panel de control, en línea con la tendencia más amplia de “arenas de trading con IA” que despegó en torno a Hyperliquid y plataformas similares. Para contexto sobre esa tendencia, puedes consultar esta recopilación sobre la arquitectura y evoluciones de Hyperliquid: IQ.wiki: Hitos de Hyperliquid

A continuación, desgloso de forma clara y enfocada en los practicantes los tres puntos críticos que marcaron esta historia: Hackgate (seguridad), Infighting-gate (comunidad/proceso) y Open-source-gate (licencia y atribución). A lo largo del análisis, destacaré lo que realmente importa para desarrolladores cripto y quienes autohospedan sus infraestructuras.

Hackgate: cómo un patrón de administrador por defecto se convirtió en un riesgo real de filtrado de credenciales

El 17 de noviembre de 2025, SlowMist publicó un análisis técnico mostrando que un commit del 31 de octubre introdujo un “modo administrador por defecto”, que permitía eludir rutas protegidas de la API en ciertas implementaciones. Incluso después de cambios posteriores, SlowMist señaló que seguían existiendo secretos JWT codificados y respuestas de API sensibles que podían exponer claves privadas de DEX y claves de API de exchanges centralizados (CEX) si los operadores desplegaban el sistema con las configuraciones predeterminadas. El informe menciona también que contactaron a los principales exchanges para mitigar riesgos. Puedes leer todos los detalles aquí: Análisis de SlowMist (17 de noviembre de 2025)

Esto es un ejemplo manual de problemas típicos en la seguridad de APIs según OWASP — como Autoridad de Función Rota y Configuraciones de Seguridad Incorrectas — en una herramienta cripto de código abierto en rápido desarrollo. Si estás operando cualquier framework de trading autohospedado, revisa la lista OWASP API Top 10 (edición 2023) antes de desplegar. OWASP API Security Top 10: 2023

Prácticas que puedes aplicar hoy para protegerte, uses o no Nofx:

• Rota las claves de API con frecuencia; nunca almacenes secretos en el código; y usa claves asimétricas si están disponibles. Buenas prácticas de API de Binance.US y Guía para desarrolladores de Binance
• Habilita listas blancas de IP para cada clave; separa claves por función (lectura vs trading) para minimizar riesgos. Guía de seguridad de cuenta de Binance Academy
• Si está disponible, usa flujos tipo broker/OAuth con “Fast API”, para que las claves ya vengan con listas blancas desde el exchange. Resumen de Fast API en OKX
• Audita tu sistema contra las guías de OWASP 2023 — autorización, gestión de secretos y respuestas mínimas por defecto son esenciales. Introducción OWASP API Security

Si estás integrando con Hyperliquid o algún otro exchange on-chain de derivados (perps), también considera riesgos relacionados con su estructura de mercado, medidas operativas de seguridad y el comportamiento de oráculos en eventos extremos. Este contexto te será útil al diseñar límites de riesgo o mecanismos de desconexión. IQ.wiki: Hitos de Hyperliquid

Infighting-gate: crecimiento sin una estructura de gobernanza

El crecimiento rápido suele acentuar las tensiones sobre reconocimiento, dirección del proyecto y flujos de trabajo. En el caso de Nofx, hubo roces públicos en torno a quién tomaba decisiones sobre el roadmap y cómo se comunicaban los cambios a los forks e integradores. Puedes ver esos problemas emergentes tanto en los issues de GitHub como en publicaciones de los contribuyentes clave. La lección no es quién tenía razón, sino cómo evitar cuellos de botella creados por personalismos:

• Establece desde el inicio un modelo claro de contribuciones (por ejemplo, mantenedores vs revisores), y registra las decisiones en issues o PRs, no solo en chats.
• Prioriza solucionar problemas de seguridad por encima de agregar nuevas funciones, y publica avisos de seguridad aunque no hagas lanzamientos formales.
• Si quieres que brokers o fondos adopten tu software, trata tu security changelog y política de cambios como parte esencial de tu producto.

El repositorio público y sus issues exhiben una oleada intensa de reportes de errores y solicitudes — muy típico de herramientas cripto open source que se vuelven virales. Este caso es valioso para entender cómo escalar la gobernanza de forma efectiva. GitHub: NoFxAiOS/nofx

Open-source-gate: AGPL, atribución y el conflicto con ChainOpera

A mediados de diciembre de 2025, varios medios informaron que Tinkle, uno de los principales colaboradores de Nofx, acusó a la testnet de ChainOpera AI Foundation de utilizar una versión antigua del código de Nofx, apenas modificando su interfaz y manteniendo el branding original, sin atribución ni transparencia. El equipo de Nofx reiteró que el proyecto está bajo licencia AGPL y que “no ha cedido el control del código”, destacando la importancia de respetar la reciprocidad que exige esta licencia cuando el software se ejecuta como un servicio en red. Cobertura completa en: Odaily, ChainCatcher y PANews

En términos sencillos, ¿qué exige la AGPL?:

• Si modificas software bajo AGPL y lo ofreces a través de una red, debes ofrecer públicamente el código fuente correspondiente y mantener la atribución al proyecto original. Puedes leer el texto de la licencia en: FSF: GNU AGPLv3 y Anuncio original del FSF

Para equipos cripto, esto implica:

• Si ofreces un fork de Nofx a clientes o comunidades, publica tu código fuente y deja claro de dónde proviene.
• Si necesitas mantener partes propietarias cerradas, negocia una licencia comercial o separa tu código privado del núcleo AGPL (consulta a un abogado especializado).
• Documenta tus cambios para que el equipo original pueda integrar mejoras de seguridad o fiabilidad, si aplica.

Sin importar cómo termine esta disputa, respetar la AGPL no solo es un tema legal, sino también una cuestión de reputación para cualquier iniciativa Web3.

¿Por qué esto explotó tan rápido? El product‑market fit en la frontera entre IA y cripto

Nofx se ubica justo en la intersección entre agentes de IA autohospedados, acceso a exchanges y la nueva generación de plataformas de trading con derivados. Su crecimiento en GitHub refleja que su enfoque como “sistema operativo de trading agente” conectó con los desarrolladores que quieren controlar el ciclo completo: datos → razonamiento → ejecución → monitoreo. Esto queda bien plasmado en su README. Nofx README

El concepto más amplio de “arena de trading para IAs” surgió de Alpha Arena de nof1, e inspiró numerosos forks, clones e implementaciones, incluido mi propio proyecto nof0. Si quieres entender cómo estas “arenas Alpha” estructuran sus reglas, prompts y tablas de clasificación, aquí tienes una explicación clara de la comunidad: Artículo explicativo de Datawallet sobre Alpha Arena

Lista de control práctica para trading stacks autohospedados

• Secretos y claves

  • Nunca lances tu sistema con secretos por defecto; obliga a generarlos de forma aleatoria al primer uso.
  • Guarda las credenciales API de CEX en un gestor de secretos; enmascara o hashea campos sensibles en respuestas de API.
  • Restringe permisos de retiro y usa subcuentas. Buenas prácticas de claves API en Binance.US

• Autorización y red

  • Separa claramente los roles de administrador y operador.
  • Bloquea los endpoints que exportan secretos con verificación secundaria.
  • Limita el acceso por IP; expón interfaces de administrador/API solo en redes privadas o perímetros de confianza cero. OWASP API Top 10: 2023

• Riesgos operativos

  • Aplica límites de riesgo por cuenta, “modo seguro” en caso de problemas de conexión, y mecanismos de apagado de emergencia.
  • Registra cada decisión y evento con identificadores estables para facilitar revisiones post-mortem.

• Licencias y atribución

  • Si haces un fork basado en AGPL y lo ofreces como servicio, publica tu código y añade atribución visible en la UI y la documentación. FSF: AGPLv3

Una nota sobre OneKey y la higiene de la autocustodia

Los frameworks de trading de código abierto suelen manejar dos tipos de secretos muy distintos: claves privadas on-chain y credenciales API de exchanges. Es fundamental mantenerlos lógicamente y físicamente separados. Para activos on-chain, una cartera de hardware con firmware open source y medidas sólidas de seguridad de la cadena de suministro te ayuda a evitar que las claves estén presentes en el servidor. Los dispositivos OneKey están diseñados para esta separación de roles y funcionan muy bien con flujos PSBT o firmas en equipos desconectados durante operaciones críticas. Para las claves API de exchange, sigue controles del lado del exchange: subcuentas, prohibiciones de retiro, listas blancas de IP, etc. Nunca almacenes claves en texto plano junto a los agentes de IA.

Reflexiones finales

• Hackgate nos recuerda que escalar sin configurar correctamente la seguridad puede tener consecuencias reales. Análisis de SlowMist
• Infighting-gate demuestra que incluso en proyectos pequeños, tener una estructura mínima de gobernanza clara importa tanto como el código.
• Open-source-gate evidencia que en pleno auge cripto x IA en 2025, respetar la AGPL no es negociable. Cobertura de Odaily · ChainCatcher · PANews

Si piensas adoptar o bifurcar Nofx, mantente al día con los boletines de seguridad y cuida la seguridad de las claves de exchange. Trata la atribución y las licencias con el mismo rigor que cualquier otro aspecto de tu producto. Y si estás construyendo tu propio “arena” o sistema operativo como nof0, empieza desde el día uno con plantillas seguras por defecto y una política de seguridad bien definida.

Recursos para profundizar:

• Repositorio y documentación de Nofx: GitHub: NoFxAiOS/nofx
• Análisis técnico de SlowMist: Threat Intelligence sobre Nofx
• Requisitos de AGPL: FSF: GNU AGPLv3
• Riesgos API según OWASP: Top 10 2023
• Antecedentes de Hyperliquid: IQ.wiki: Hitos de Hyperliquid

Divulgación: soy un observador independiente que desarrolló el proyecto nof0 durante el ciclo de auge de Nofx, y discutí implementaciones y colaboración open source con Tinkle y Zack.