Ахиллесова пята Open Source: 9 000 звёзд Nofx за 2 месяца — и его Hackgate, Раскол‑гейт и Open‑source‑гейт

Я выступаю здесь как сторонний наблюдатель и аналитик этой истории. Во время стремительного взлёта Nofx я создал собственный независимый open-source проект под названием nof0, вдохновлённый трендом nof1 и «Альфа-Ареной», и обменивался техническими заметками с ключевыми участниками Nofx — Tinkle и Zack. Это даёт мне полезную перспективу: дело здесь не только в популярности на GitHub, а в том, как проекты на стыке крипты и ИИ могут взлетать за ночь — и с такой же скоростью сталкиваться с проблемами безопасности, управления и лицензирования.

На 22 декабря 2025 года репозиторий Nofx насчитывает около 9,2 тыс. звёзд — результат, достигнутый менее чем за два месяца с конца октября (один из первых коммитов, упомянутых в отчётах по безопасности, датирован 31 октября 2025 года). Более актуальные цифры можно увидеть на странице репозитория: GitHub: NoFxAiOS/nofx. Сам проект позиционируется как «ОС агентной торговли» для мультибиржевой криптоторговли с возможностью подключения ИИ-моделей и дашбордом — часть более широкой волны экспериментов в сфере «ИИ на полях сражений трейдинга», которые нашли отклик на платформах вроде Hyperliquid. Для понимания контекста см. материалы об архитектуре и этапах развития Hyperliquid: IQ.wiki: Этапы Hyperliquid

Ниже приведён практико‑ориентированный обзор трёх критических точек: Hackgate (проблемы безопасности), Раскол‑гейт (сообщество и процессы), и Open‑source‑гейт (лицензирование и авторство). И, по ходу, я выделю ключевые уроки для крипторазработчиков и тех, кто работает в модели self-hosted.

Hackgate: как дефолтный режим админа стал источником утечки ключей

17 ноября 2025 года команда SlowMist опубликовала технический анализ, показавший, что коммит от 31 октября ввёл режим «админ по умолчанию», позволяющий обойти защищённые API‑маршруты в ряде конфигураций. Несмотря на последующие правки, SlowMist отмечает, что в коде оставались жёстко заданные секреты для JWT и чувствительные API-ответы, в результате чего при развертывании с настройками по умолчанию можно было утечь как ключи CEX, так и приватные ключи DEX. Команда координировала уведомления с крупными биржами, чтобы минимизировать последствия. Полную информацию смотрите в отчете: SlowMist: анализ риска (17 ноября 2025)

Это классический пример появления уязвимостей из списка OWASP API Security — таких как неверная авторизация на уровне функций (Broken Function Level Authorization) и ошибки конфигурации (Security Misconfiguration) — в быстрорастущем open-source криптопроекте. Если вы используете self-hosted фреймворк, обязательно проверьте его по OWASP API Top 10: 2023.

Полезные практики безопасности ключей и API при работе с биржами (и в случае с Nofx, и без него):

• Регулярно меняйте API‑ключи, не храните их в коде, и по возможности используйте асимметричную криптографию. Best practices для Binance.US, Типы ключей в Binance
• Внедрите ограничение по IP‑адресам и разделение ключей по функциям (например, чтение / торговля). Гид по безопасности от Binance Academy
• При наличии такой поддержки используйте брокерские или OAuth‑стиль «Fast API»‑процессы — они позволяют изначально ограничить ключи по IP‑белым спискам. Обзор OKX Fast API
• Проверьте ваше приложение на соответствие гайдам OWASP 2023 — особенно в отношении авторизации, управления секретами, и «минимально необходимой чувствительности» в ответах API. Введение в OWASP API Security

Если ваш стек взаимодействует с Hyperliquid или другими on-chain фьючерсными платформами, принимайте во внимание также особенности рыночной инфраструктуры, ореклов и поведения биржи в стрессовых режимах. Ссылки по теме: IQ.wiki: этапы Hyperliquid

Раскол‑гейт: рост сообщества без рабочего управления

Стремительное масштабирование обостряет разногласия вокруг того, кто принимает решения, как коммуницируются изменения и каковы роли участников. В случае с Nofx это проявилось в публичных обсуждениях вокруг управления дорожной картой и взаимодействия с другими форками и интеграциями. Напряжённость можно увидеть в issue‑трекерах и социальных постах участников. Главный урок — не выяснение, кто прав, а понимание необходимости системного управления:

• Сформируйте модель участия с самого начала (напр., мейнтейнеры vs ревьюеры), фиксируйте решения в issues или pull‑requests, а не в чатах
• Безопасность должна иметь приоритет над фичами; даже в ранней стадии публикуйте рекомендации по миграции при всех уязвимостях
• Если вы рассчитываете на работу с фондами или брокерами — лог изменений и политика безопасности становятся частью вашего «продукта»

Репозиторий Nofx сохранил массу обсуждений и отчётов о багах — как типичный open-source кейс, внезапно попавший в центр внимания. Изучать его стоит как пример масштабирования без процессов: GitHub: NoFxAiOS/nofx

Open‑source‑гейт: AGPL, авторство и конфликт с ChainOpera

В середине декабря 2025 года появились сообщения о том, что ключевой участник Nofx по имени Tinkle обвинил Foundation ChainOpera AI в том, что их тестнет использовал старую версию кода Nofx, практически не изменив UI и оставив прежний брендинг — без указания авторства и явно нарушая лицензию AGPL. Команда Nofx напомнила, что проект распространяется под AGPL и «не отказывался от контроля над кодом», подчёркивая важность копилефта при использовании в виде онлайн‑сервиса. Подробности: Odaily, ChainCatcher, PANews

Простыми словами, что требует AGPL:

• Если вы модифицируете AGPL‑код и предоставляете его как сервис в сети — вы обязаны предоставить исходный код и сохранять указание авторства. Подробнее — FSF: GNU AGPLv3, Официальное заявление FSF о AGPL

Что это значит для криптокоманд:

• Если вы запускаете форк Nofx для клиентов или сообщества — исходный код обязателен, как и видимое указание авторов
• Если вам нужно сохранить закрытые дополнения — нужно либо согласовать коммерческую лицензию, либо так отделить код, чтобы нововведения не считались производными (обратитесь к юристам)
• Документируйте изменения так, чтобы улучшения могли быть возвращены в основной проект

Вне зависимости от конкретного результата конфликта, соблюдение AGPL важно как с юридической, так и с репутационной точки зрения — особенно в мире Web3.

Почему проект взлетел так быстро: попадание в точку между криптой и ИИ

Nofx оказался на пересечении — self-hosted ИИ-агенты, подключение к биржам и новые форматы фьючерсной торговли (перпсы). Быстрый рост звёзд отражает, насколько идея «агентной торговой ОС» зашла разработчикам, желающим контролировать весь цикл: данные → логика → исполнение → мониторинг. Это отражено в README: Nofx README

Широкая идея «Арены» — соревнования ИИ в реальных рыночных условиях — сформировалась на базе nof1 и породила множество форков, клонов и альтернатив, в том числе проект nof0, над которым я сам работал. Объяснение по структуре промтов, правилам и таблицам лидерства — здесь: Datawallet: Alpha Arena

Чек‑лист безопасности для self‑hosted трейдинговых стеков

• Секреты и ключи

  • Изначально форсируйте генерацию случайных JWT/ключей; не используйте дефолтные значения
  • Используйте менеджеры секретов; в API‑ответах скрывайте чувствительные поля
  • Ограничьте права вывода средств, используйте суб‑аккаунты
  • Практики по ключам для Binance.US

• Авторизация и политика сети

  • Разделите роли админа и оператора
  • Требуйте двухфакторное подтверждение при экспорте секретов
  • Админку и API публикуйте только в приватной сети или с применением механизмов zero trust
  • OWASP API Security 2023

• Операционные риски

  • Введите лимиты на уровне аккаунта, безопасный режим при потере связи с биржей, и аварийные отключения
  • Логируйте все действия с привязкой к уникальным идентификаторам для ретроспектив

• Лицензия и авторство

  • Хостите форки AGPL‑кода только при условии публикации исходников и указания авторов в интерфейсе и документации
  • FSF: AGPLv3

Отдельно: OneKey и грамотное хранение приватных ключей

Open-source трейдинговые фреймворки работают сразу с двумя типами секретов: on-chain приватные ключи и API‑ключи бирж. Их следует логически и физически разделять. Для защиты on-chain активов лучше использовать аппаратные кошельки с open-source прошивкой и надёжной цепочкой поставки: устройства OneKey как раз созданы для подобной сегрегации. Они хорошо сочетаются с PSBT‑подобными сценариями или оффлайн‑подписью в операциях с капиталом. Что касается API‑ключей от бирж — следуйте биржевым рекомендациям (субаккаунты, заморозка вывода средств, IP‑блокировки) и не храните ключи в открытом виде на сервере, где работает ИИ.

Заключение

• Hackgate напомнил, что масштаб без защищённых дефолтов чреват утечками и потерями. Отчёт SlowMist
• Раскол‑гейт показал, что без лёгкой, но формальной системы управления проект начинает буксовать
• Open‑source‑гейт дал понять: в мире crypto x AI 2025 года лицензия AGPL — не опция, а необходимость. Odaily · ChainCatcher · PANews

Если вы внедряете или форкаете Nofx — внимательно следите за бюллетенями безопасности и соблюдайте гигиену при работе с ключами. Если вы строите собственную «арену» или ОС типа nof0 — с самого начала выпускайте безопасные шаблоны и публикуйте чёткую политику безопасности.

Полезные ресурсы:

• Репозиторий Nofx: GitHub: NoFxAiOS/nofx
• Анализ от SlowMist: Технический отчёт по Nofx
• Лицензирование AGPL: FSF: GNU AGPLv3
• Безопасность API по OWASP: Топ-10 угроз 2023 года
• Контекст по Hyperliquid: IQ.wiki: этапы развития

Разъяснение: я являюсь сторонним наблюдателем, создавшим проект nof0 во время шумихи вокруг Nofx и общавшимся с Tinkle и Zack на тему реализации и open-source сотрудничества.