Le talon d’Achille de l’open source : 9 000 étoiles pour Nofx en 2 mois — et son Hackgate, Infighting-gate et Open-source-gate

Je suis un simple analyste et observateur de cette saga. Au moment de l’émergence de Nofx, j’ai lancé un projet open source indépendant baptisé nof0, inspiré de la tendance des "Alpha Arena" de nof1, tout en échangeant des notes techniques avec deux des principaux contributeurs de Nofx, Tinkle et Zack. Ce point de vue privilégié permet d’aller au-delà des apparences : l’histoire de Nofx n’est pas seulement celle d’un dépôt GitHub qui explose, c’est aussi une étude de cas sur la rapidité avec laquelle les projets crypto x IA peuvent croître — et s’exposer, aussi vite, aux problèmes de sécurité, de gouvernance et de licences.

Au 22 décembre 2025, le dépôt GitHub de Nofx compte environ 9 200 étoiles, une croissance fulgurante en un peu moins de deux mois (l’un des premiers commits mis en cause dans les analyses de sécurité date du 31 octobre 2025). La page du dépôt est accessible ici :
GitHub : NoFxAiOS/nofx.
Nofx se présente comme un "système d’exploitation de trading agentique", destiné à connecter plusieurs exchanges crypto, intégrant des modèles IA modulables avec un tableau de bord unifié. Il s’inscrit dans la lignée d’expérimentations d’arènes de trading IA, popularisées notamment par le projet Hyperliquid. Pour mieux comprendre cette dynamique, consultez le contexte technique d’Hyperliquid :
IQ.wiki : Hyperliquid milestones

Voici une analyse concrète et sans langue de bois des trois crises successives qui ont éclaté : Hackgate (vulnérabilité de sécurité), Infighting-gate (frictions communautaires) et Open-source-gate (licence et attribution). À chaque étape, nous en tirerons des leçons utiles pour les développeurs crypto et les auto-hébergeurs.

Hackgate : quand un mode admin par défaut met en péril les clés d’API

Le 17 novembre 2025, SlowMist publie une analyse indiquant qu’un commit du 31 octobre avait introduit un mode admin activé par défaut, permettant de contourner certaines protections d'API dans des déploiements spécifiques. Même après des correctifs, SlowMist souligne que des secrets JWT codés en dur et des réponses sensibles d’API pouvaient toujours exposer, dans certains cas, des clés API CEX (exchange centralisé) ou des clés privées DEX (exchange décentralisé) si l’on utilisait les configurations par défaut.

Plusieurs exchanges auraient été contactés à temps pour réduire le risque. Les détails techniques de la vulnérabilité, le code en cause et les commits sont dans le rapport complet :
Analyse SlowMist (17 nov 2025)

Un cas d’école de failles types OWASP (autorisation brisée par niveau de fonction, mauvaise configuration de sécurité) dans un outil crypto open source. Si vous déployez un système auto-hébergé, prenez l’OWASP API Top 10 (2023) comme check-list de base :
OWASP API Security Top 10 : 2023

Bonnes pratiques pour la sécurité des clés d’API (avec ou sans Nofx) :

• Rotation régulière des clés – ne jamais stocker de secrets dans le code ; utiliser des clés asymétriques si possible.
  Binance.US : bonnes pratiques clés API
  Types de clés selon Binance développeurs
• Liste blanche IP obligatoire – distinguer les clés selon leur fonction (lecture seule vs trading) pour limiter les risques.
  Binance Academy : guide de sécurité
• Utiliser des architectures API courtiers/OAuth quand possible, avec des flux "Fast API" intégrant les IP whitelist automatiquement côté exchange.
  Présentation Fast API d’OKX
• Auditez votre déploiement selon les recommandations OWASP 2023 – autorisation fine, gestion des secrets, réponses API les plus minimales par défaut : non négociables.
  Introduction OWASP API Security

Si vous utilisez Hyperliquid ou d’autres venues de trading perpétuel on-chain, tenez aussi compte du risque structurel, de la robustesse opérationnelle et du comportement des oracles en cas de stress marché.
IQ.wiki : étapes clés d’Hyperliquid

Infighting-gate : croissance communautaire sans gouvernance claire

Quand un projet explose, l’absence de règles claires sur la gouvernance peut faire surgir frictions et chaos. Dans le cas de Nofx, des tensions sont apparues publiquement sur la question de qui décidait de la feuille de route, et comment les changements rapides de code devaient être communiqués aux forks et intégrateurs. Ces frictions sont évidentes dans les issues GitHub et les posts sociaux des contributeurs clés.

Le vrai enseignement ici n’est pas de savoir qui avait raison, mais comment éviter les goulets d’étranglement liés aux egos personnels :

• Définir un modèle de contribution le plus tôt possible (mainteneurs vs relecteurs), avec des décisions déposées dans les issues / pull requests, pas dans des chats éphémères.
• Donner priorité aux correctifs de sécurité sur les nouvelles fonctionnalités, et publier des avis/clés de migration même sans version "officielle".
• Si vous cherchez l’adoption par des fonds ou brokers, considérez vos notes de changement et politiques de sécurité comme partie intégrante de votre produit.

L’activité du dépôt GitHub de Nofx reflète une demande massive et une avalanche de signalements de bugs, typique de ces outils open source crypto en pleine explosion.
GitHub : NoFxAiOS/nofx

Open-source-gate : AGPL, attribution et conflit avec ChainOpera

Mi-décembre 2025, plusieurs médias rapportent que Tinkle, contributeur principal de Nofx, accuse ChainOpera AI Foundation d’avoir déployé en testnet une version antérieure de Nofx, avec peu de modifications visuelles et en conservant le branding d’origine — sans attribution ni transparence.

Nofx rappelle que le code est sous licence AGPL (copyleft fort), et que l’équipe n’a pas abandonné ses droits sur le projet. L’enjeu : quand un logiciel AGPL est utilisé en réseau, le code source complet ET l’attribution doivent être rendus accessibles.

Sources :
Article Odaily,
ChainCatcher,
PANews

Que dit l’AGPL en clair ?

• Si vous modifiez un logiciel AGPL et que vous l’exécutez comme un service sur réseau, vous êtes tenu de partager le code modifié avec les utilisateurs, et de maintenir l’attribution d’origine.
  Texte officiel AGPLv3 – FSF

Implications pour les projets crypto :

• Si vous proposez un fork de Nofx en service public, vous devez publier le code source de votre version et mentionner clairement Nofx.
• Si vous avez besoin de garder des modules fermés, obtenez une licence commerciale ou cloisonnez votre architecture pour que ces modules ne soient pas considérés comme dérivés.
• Documentez les modifications afin que les améliorations notables puissent être remontées en amont.

Au-delà des litiges spécifiques, respecter l’AGPL est un impératif légal et réputationnel dans un Web3 dominé par l’open source.

Pourquoi cette crise a pris une telle ampleur : product-market fit au croisement IA x crypto

Nofx touche un point névralgique : agents IA auto-hébergés + connectivité exchange + marchés perpétuels nouvelle génération. L’évolution de ses étoiles GitHub montre que l’idée de "trading agentique intégral" — du traitement de données à l’exécution multi-plateformes — séduit profondément les développeurs.
README de Nofx

Le concept général des "arènes IA de trading" provient de nof1 et son Alpha Arena, donnant naissance à de nombreux forks et clones, dont nof0. Pour un résumé neutre de ce que sont ces expériences (prompts, règles, classements), lisez cette synthèse communautaire :
Présentation Alpha Arena par Datawallet

Check-list pratique de sécurité pour une stack de trading auto-hébergée

• Secrets et clés

  • Ne jamais livrer avec des secrets par défaut ; forcer la génération aléatoire au premier run.
  • Stocker les clés API dans un gestionnaire de secrets ; masquer ou hacher les champs sensibles dans les réponses d’API.
  • Restreindre les autorisations de retrait et utiliser des sous-comptes.
    Binance.US : pratiques clés API

• AuthZ et réseau

  • Séparer les rôles admin et opérateur.
  • Protéger les endpoints critiques ("export des clés") avec une double vérification.
  • Appliquer des listes blanches IP ; restreindre l’API et le panneau admin aux réseaux privés ou périmètres zero-trust.
    OWASP API Top 10 : 2023

• Risque opérationnel

  • Implémenter des limites de risque par compte, des "modes sûrs" en cas de panne exchange, et des coupe-circuits.
  • Journaliser chaque décision avec des identifiants persistants pour analyses a posteriori.

• Licence et attribution

  • Si vous hébergez du code AGPL, offrez le code source de votre fork et une attribution visible dans l’interface et la documentation.
    FSF : AGPLv3

Note sur OneKey et l’hygiène de la self-custody

Les frameworks de trading open source manipulent deux catégories sensibles : clés privées on-chain et clés API exchange. Séparez-les strictement, tant logiquement que physiquement.
Pour les actifs on-chain, un wallet matériel avec firmware open source type OneKey permet d’éviter toute exposition brute des clés. OneKey s’adapte bien aux flux type PSBT ou au fonctionnement en mode air-gapped pour les opérations de trésorerie.

Côté exchange, appliquez les meilleures pratiques natives des exchanges (sous-comptes, blocage des retraits, whitelists IP) et ne stockez jamais les clés en clair sur le serveur exécutant vos agents IA.

Conclusion

• Hackgate : une croissance fulgurante sans sécurité par défaut ouvre la porte aux pertes concrètes. SlowMist
• Infighting-gate : même dans l’open source, la gouvernance documentée est cruciale.
• Open-source-gate : à l’ère de la boom IA x crypto, respecter l’AGPL n’est plus une option.
  Odaily · ChainCatcher · PANews

Si vous adoptez ou forkez Nofx, surveillez activement les bulletins sécurité, gérez rigoureusement vos clés, et traitez votre politique de licence et d’attribution comme un pan entier de votre produit.
Si vous construisez un framework ou une arène, comme nof0, fournissez des modèles sécurisés par défaut dès le premier jour, avec une politique de sécurité claire.

Ressources pour aller plus loin :

• Dépôt et documentation Nofx :
  GitHub : NoFxAiOS/nofx
• Analyse technique de SlowMist :
  Analyse Nofx par SlowMist
• Exigences de l’AGPL :
  FSF : GNU AGPLv3
• OWASP 2023 :
  Top 10 risques pour API
• Hyperliquid :
  IQ.wiki : Hyperliquid milestones

Transparence : je suis un observateur tiers ayant construit nof0 pendant le battage autour de Nofx. J’ai discuté implémentation et collaboration open source avec Tinkle et Zack.