CryptoGate 0.4.0 — локальный интеграционный стенд

Релиз включает кабинет магазина, казначейство с резервами, локальное разрешение владельца, ручные проверки и эксплуатационные инструменты. Это не готовый к реальным деньгам процессинг. Расходные блокчейн-транзакции не создаются и не подписываются. Реальные направления заблокированы независимо от настроек интерфейса.

С чего начать

Распакуйте весь архив. Откройте PUBLIC_UPLOAD/cryptogate.local/START_LOCAL.bat. Требуется PHP 8.2 или новее с PDO SQLite, Sodium, OpenSSL и Fileinfo. Пароли первого запуска случайные: файл storage/LOCAL_CREDENTIALS.txt. Сайт: http://127.0.0.1:8088/; администратор: /admin; кабинет магазина: /merchant. Полная инструкция находится в /help и docs/INSTALL_RU.md.

Обычный запуск не запускает сетевые фоновые процессы. START_FULL_LOCAL.bat запускает три обработчика и сайт. Закрывайте каждое окно при остановке. Обработчики не означают, что RPC настроены или сети проверены.

Границы релиза

В реестре сохранён снимок 124 активов, 141 направления и 14 сетей из v0.3. Это не перепроверенный сегодня перечень доступных продуктов стороннего сервиса. В локальном симуляторе используются фиктивные реквизиты TEST_..., фиксированные тестовые курсы и SIM_.../SIMOUT_... события. На них нельзя отправлять деньги. Импортированные реальные адреса симулятору не выдаются.

Приватные ключи кошельков находятся в PRIVATE_KEEP_LOCAL, которая никогда не копируется на сайт. Ключ владельца подписывает разрешение для симулятора, а не готовую транзакцию блокчейна. TON и Monero требуют отдельных библиотек и в среде сборки не исполнялись. Проверка 12 других генераторов не является внешним аудитом криптографии.

Полный список реализованного и ограничений: docs/MODULE_MATRIX.md, docs/KNOWN_LIMITATIONS.md. Свежие результаты проверок: QA_REPORTS в корне архива. Старое ТЗ сохранено как требования, а не заявление о реализации каждого пункта.

Установка и первый осмотр

1. Расположение папок

PUBLIC_UPLOAD/cryptogate.local содержит приложение. Только его подкаталог public является корнем веб-сервера. Файлы .env, storage, database, scripts и исходный код не должны раздаваться как статические файлы.

PRIVATE_KEEP_LOCAL содержит Python-программы, зашифрованные кошельки, ключ генератора, отдельный ключ разрешений и резервные копии. Храните папку вне C:\OSPanel\home и вне синхронизируемого на сервер каталога. Само название папки не даёт защиты: это организационное разделение.

Для локального осмотра удобнее распаковать архив, например, в C:\CryptoGate. В данной сборке Windows/OpenServer не запускались: проверялся PHP CLI и браузер в Linux. Пути с пробелами заключайте в кавычки.

2. PHP и настройки

Проверьте php -v и php -m. Основное приложение требует PHP >= 8.2, PDO, pdo_sqlite, sodium, openssl, fileinfo. cURL нужен для отправки webhook с закреплением IP; отсутствие cURL нельзя обходить небезопасным HTTP fallback. Для полноценного сетевого контура также нужно настроить RPC и внешние соединения. Наличие расширения не подтверждает правильность сетевого адаптера.

Запустите php scripts/preflight.php --json; для проверки зависимостей отправки уведомлений добавьте --full. В поставку не включены PHP, браузер и установщики ОС. Укажите PHP OpenServer в PATH либо запускайте команды его полным путём.

php scripts/init-local.php создаёт случайный служебный APP_KEY, локальную SQLite-базу и демонстрационные данные только при первой установке. Если .env уже существует, скрипт не должен генерировать новый ключ вместо старого. Если есть БД, но отсутствует .env, установка остановится: восстановите оригинальный ключ, а не создавайте новый.

3. Первый вход

Запустите START_LOCAL.bat. Откройте http://127.0.0.1:8088. Начальные учётные данные записываются в storage/LOCAL_CREDENTIALS.txt только на вашем компьютере. Паролей ChangeMe_123! в новом установочном сценарии нет. Файл содержит также тестовый API-ключ: не отправляйте его в переписку и не включайте в публичные архивы.

После входа смените пароль администратора и настройте TOTP в «Безопасность». Резервные одноразовые коды сохраните отдельно. Администратор и магазин используют разные сессии; вход в другой кабинет в том же браузере прекращает предыдущую роль. Для одновременного осмотра используйте разные профили браузера.

4. Что открыть по порядку

Главная показывает текущую версию и границы стенда. Затем откройте админский обзор, «Магазины», «Счета», «Казначейство», «Разрешения владельца», «Проверки и удержания», «Состояние системы» и «Аудит». Создайте тестовый счёт через API или кабинет магазина. Откройте его оплату, выберите тестовое направление и используйте симулятор из административной сессии.

Проверьте частичное поступление и доплату, переплату, повторную отправку того же запроса, резервирование выплаты, отмену и удержание. На странице оплаты реквизиты должны начинаться с TEST_. Не подменяйте их на реальный кошелёк.

5. Фоновые процессы

START_FULL_LOCAL.bat открывает сайт, operations-worker, network-worker и webhook-loop. Operations-worker планирует сверки, регулярные счета и завершение просроченных разрешений. Network-worker без RPC должен показывать «не настроен», а не «успешно синхронизирован». Webhook без получателя получает состояние no_endpoint.

Нельзя оставлять старые и новые версии обработчиков одновременно на одной базе. Перед обновлением остановите все окна. SQLite-вариант рассчитан на локальные проверки, не на заявленную нагрузку промышленного сервиса.

6. Типичные ошибки

could not find driver означает отсутствие pdo_sqlite именно в том PHP, который вызван командой. Наличие расширения у другого PHP не помогает. Ошибка расшифровки старого секрета после переустановки чаще связана с другим APP_KEY: восстановите исходную .env и данные вместе. Исчерпание тестового пула требует новых тестовых реквизитов, а не включения настоящего кошелька.

Если регистрация администратора прервана до сохранения пароля, используйте локальную команду сброса, когда она присутствует в scripts, либо восстановите новую чистую тестовую установку; не редактируйте хеши паролей вручную. Не запускайте reset-local.php на данных, которые хотите сохранить: это старый разрушительный инструмент, в релизе он заблокирован.

Обновление с v0.3.0

Сначала остановите веб-сервер и все фоновые обработчики. Сделайте копию всей старой папки приложения, включая скрытую .env, storage и SQLite-файлы. Отдельно сохраните PRIVATE_KEEP_LOCAL: генератор, vaults, generator_signing_key.vault.json и его публичную часть. Проверьте, что копии читаются. Старый архив кода сам по себе не заменяет резервную копию данных.

Распакуйте v0.4 в новую папку; не распаковывайте её вслепую поверх старой. Перенесите старую .env и runtime-каталог storage в новое приложение. Сохраните старый APP_KEY, имя БД, кошельки и публичные доверенные ключи. Не переносите старые app, database/migrations, public или resources поверх нового кода.

В новом приложении выполните php scripts/init-local.php. Для существующей базы он применяет идемпотентную миграцию, не повторяет seed и не заменяет пароли. В данной версии поддержана только SQLite-миграция. PostgreSQL-схема в старом проекте не означает, что все новые миграции и интеграционные тесты выполнены для PostgreSQL.

После миграции проверьте число магазинов, счетов, проводок и адресов; запустите сверку в админке. Выполните регрессионные тесты. Старая учётная запись остаётся с прежним паролем, который нужно сменить, если он был демонстрационным. Для старого магазина создайте сотрудника кабинета из раздела «Магазины»: новые случайные учётные данные seed создаются только на свежей базе.

PRIVATE_KEEP_LOCAL обновляйте отдельно: скопируйте новые файлы программ, не перезаписывая vaults, exports, owner, generator_signing_key.vault.json или generator_public.json. Разрешение владельца имеет отдельный новый ключ в подпапке owner. Старый ключ адресных манифестов для него не используется.

Совместимость изменения таблиц не является доказательством безопасного отката. Для возврата к v0.3 восстановите одновременно старый код, .env и БД из снимка перед миграцией. Не подключайте старый код к уже мигрированной БД.

Локальные кошельки, адреса и разрешения владельца

Три разных назначения ключей

Расходные ключи кошельков управляют адресами блокчейна. Ключ генератора адресных манифестов подписывает список публичных адресов для импорта. Ключ разрешений операций подтверждает выбранную владельцем локальную расходную операцию. Это разные ключи, разные файлы и разные полномочия. Пароль администратора не расшифровывает ни один из этих локальных ключей.

Хранилища Python шифруются AES-GCM; пароль преобразуется scrypt с фиксированными параметрами. Это реализация локального генератора, а не старый серверный owner-envelope из ТЗ. Серверные служебные секреты и документы защищены отдельно APP_KEY из .env; владелец сервера с этой .env может их расшифровать. APP_KEY не является вашим расходным ключом кошелька.

Установка Python

Используйте Python >= 3.10. Создайте виртуальное окружение внутри PRIVATE_KEEP_LOCAL, установите зависимости через INSTALL_DEPENDENCIES.bat. Установка библиотек требует интернета; сама генерация базовых ключей и подпись разрешения работают без отправки запросов. requirements.txt содержит диапазоны версий, а не полностью зафиксированный lockfile. Сохраните pip freeze после проверенной установки. Не обновляйте библиотеки кошельков без повторного теста.

Для основной функциональности достаточно cryptography; TON и Monero требуют дополнительных пакетов. Команда python wallet_generator.py list-networks показывает 14 известных проекту сетей. Это снимок реестра, а не обещание поддержки новых сетей стороннего сервиса.

Генерация и импорт адресов

Пример: python wallet_generator.py generate --networks bitcoin,ethereum,tron,solana --count 10 --label "Мой локальный пул". Пароль вводится скрыто и должен содержать не менее 14 символов. Для всех сетей: --networks all, но только после установки и проверки необязательных зависимостей. При отсутствии TON или Monero генерация all отказывается начинать неполную партию.

Секреты сохраняются в vaults/PRIVATE-...vault.json; открытые подписанные адреса — в exports/PUBLIC-...json. На сайт передаются только публичный манифест и generator_public.json. Перед импортом сверяйте отпечаток с отдельным экраном. Импорт не проверяет способность расходовать средства в реальной сети и не включает приём автоматически.

Храните минимум две проверенные резервные копии локального хранилища в защищённых местах. Пароль и резервный носитель нельзя терять одновременно. Шифрование на диске не защищает от вредоносной программы, читающей открытый ключ в памяти во время использования. Python не обеспечивает доказуемое стирание всех копий секретов из памяти.

python wallet_generator.py vault-summary ПУТЬ показывает состав без ключей. show-key раскрывает выбранный расходный ключ в локальной консоли: делайте это только при реальной необходимости, без трансляции экрана, записи терминала и отправки результата кому-либо. Пароль не следует передавать параметром командной строки или общедоступной переменной окружения.

Разрешение локальной операции

В админке /admin/owner скопируйте instance_id. В PRIVATE_KEEP_LOCAL выполните python owner_signer.py init --instance ВАШ_ID либо используйте START_OWNER_SIGNER.bat. Ключ и политика создаются в подпапке owner. Сайт получает только OWNER_PUBLIC.json.

На стороне приложения выполните php scripts/owner-key-enroll.php "ПУТЬ_К_OWNER_PUBLIC.json" ПОЛНЫЙ_SHA256_ОТПЕЧАТОК. Сверяйте отпечаток не по файлу, полученному из сомнительного источника, а с вашим локальным приложением. Повторная замена ключа этим скриптом запрещена; безопасная ротация ключей ещё не реализована.

Создайте локальную выплату в «Казначействе»: магазин, направление, сумма в минимальных единицах, лимит комиссии, получатель TEST_... и причина. Сумма и лимит резервируются атомарно. На карточке экспортируйте *.owner-request.json. Откройте его локальным owner_signer: python owner_signer.py approve "ПУТЬ_К_ЗАПРОСУ". Сверьте сеть, получателя, сумму, комиссионный лимит, тип и срок. Подтвердите полным operation_id и паролем.

Полученный *.approval.json загрузите в раздел владельца. Проверка файла не отправляет деньги. На карточке операции отдельно выполните симуляцию. Нельзя переносить разрешение на другой экземпляр, сумму или получателя. Истёкшее разрешение, отозванный ключ, новая блокировка или аварийная пауза препятствуют исполнению. Повтор файла не создаёт новый расход.

Это не подпись транзакции Bitcoin/Ethereum/TRON и не универсальный отправитель криптовалюты. В v0.4 отсутствует построение, offline-подпись и отправка реальной расходной транзакции для всех 14 сетей. Не используйте этот инструмент для фактических выплат. В таблице возможностей это явно показано.

Особенности сетей

BTC, LTC, DOGE, DASH и BCH имеют отдельные форматы адресов и WIF. EVM-сети используют отдельные записи сети, даже когда вид адреса одинаков. TRON требует своего кодирования. Solana хранит seed и соответствующую пару seed/public. TON дополнительно зависит от версии wallet-контракта; запрещена незаметная замена версии при импорте. Monero требует отдельной логики просмотра, spend/view ключи остаются локально. В этой среде реальная генерация TON/Monero не выполнялась.

Создание адреса не активирует его платные ресурсы, не пополняет gas, не создаёт SPL token-account, не проверяет токен-контракт и не обеспечивает ликвидность. Эти действия необходимо реализовать и проверить отдельно до боевого допуска.

Админка, казначейство и ручные проверки

Навигация и права

Роли администратора: owner, finance, security, support, auditor, compliance. Меню скрывает недоступные разделы, но основная защита находится на серверных маршрутах. Владелец — не открытый приватный кошелёк: права приложения не дают способности расходовать реальные монеты. Изменение APP_KEY тоже не открывает локальный vault.

«Обзор» и «Статистика» отображают локальные записи. «Магазины» управляют карточками, API и сотрудниками. «Счета» и «Попытки» показывают связь заказа, направления, адреса и поступления. «Транзакции» нельзя использовать как доказательство реального подключения сети: исходный источник и статус имеют значение. «Проводки» и «Аудит» доступны для чтения; обычные UPDATE/DELETE блокируются триггерами.

«Казначейство» объединяет балансы, резервы, операции и локальные лимиты. «Разрешения владельца» — отпечаток экземпляра, доверенный публичный ключ и импорт подтверждений. «Проверки и удержания» — дела, решения, причина удержания. «Состояние системы» — текущие зависимости, heartbeat обработчиков, очередь, сверки и снимки.

Что означает баланс

total — учётный баланс из проводок; reserved — средства под активные заявки; held — ограниченные средства; available — остаток с учётом обоих ограничений; deficit — выявленный недостаток. Значения не складываются между валютами как однородные числа. Даже одинаковый токен в разных сетях — отдельное направление.

Создание расходной заявки проверяет магазин, направление, локальный режим, сумму, лимиты, удержания и доступность. В той же транзакции создаются неизменяемое намерение и резерв суммы с комиссионным потолком. Экспорт или подпись сами по себе не списывают средства. Исполнение повторно проверяет актуальную политику и даёт ровно одно списание. Неиспользованный комиссионный резерв освобождается. Симулятор не притворяется, что понёс настоящий сетевой расход.

Отмена и истечение срока освобождают резерв. Нельзя вручную менять получателя внутри уже подписанной операции: нужна отмена и новая заявка. Политики позволяют настроить размер заявки и суточный лимит в минимальных единицах. Подсказки сбора со счетов требуют свежего снимка остатков; они являются предложением, а не фактическим автоматическим sweep.

Сверка

Проверяются балансировка проводок, учёт резервов и состояния операций, отрицательные доступные остатки, связи объектов и целостность цепочки аудита. Результат сохраняется с деталями. Успешная проверка БД не означает сверку с реальными нодами: внешняя on-chain сверка, ликвидность и gas-модель требуют отдельной реализации/испытаний.

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

Проверки магазинов и документы

Магазин заполняет юридическое название, двухбуквенный код страны, регистрационный номер и категорию. Изменение анкеты создаёт ручное дело. Одобрение одного дела не закрывает остальные открытые проверки. Внешний AML/KYC остаётся not_configured; ручное решение не выдаётся за автоматическую проверку санкций или подтверждение лицензии.

Документы принимаются только PDF/JPEG/PNG до 10 МБ по фактическому MIME и шифруются вне public. Доступ защищён правами и принадлежностью магазину, чтение проверяет целостность. Файлы считаются not_scanned: антивирус и внешняя верификация отсутствуют. Для осмотра используйте только вымышленные документы, не паспортные данные реальных людей.

Полное удержание запрещает расходы магазина. Частичное удержание уменьшает доступный остаток выбранного направления. Снятие удержания требует причины и сохраняет историю. Отдельный риск-скоринг по реальным источникам не реализован.

Журналирование

Финансовый журнал, аудит действий, события операций, записи API, очередь и попытки webhook — разные журналы с разными назначениями. Пароли, seed, приватные ключи и API-секреты исключаются из структурированных полей аудита. Не вставляйте секрет в свободный текст причины: семантически распознать все произвольные секреты система не может.

Цепочка хешей и триггеры обнаруживают/ограничивают штатное изменение истории, но не защищают от атакующего, который владеет всей БД, кодом и резервами. Внешнее неизменяемое хранилище, независимое якорение и SIEM ещё не подключены. Не заявляется запись абсолютно каждого неуспешного запроса; ключевые бизнес-действия журналируются, полный независимый access/security logging требует дальнейшей настройки.

Эксплуатация, резервные копии и восстановление

Очереди и обработчики

Operations-worker использует очереди с dedupe, арендой задания, ограничением попыток и состоянием dead. Повтор запускается явно из админки. Это не отменяет необходимости идемпотентной бизнес-логики: после потери процесса задача может повториться. Heartbeat показывает последнее появление, а не гарантию успешности каждого задания.

Аварийная пауза расходов проверяется при подготовке/исполнении. Она не отменяет уже отправленную в блокчейн транзакцию; в данной версии таких отправок вообще нет. Сетевой модуль без RPC должен показывать отсутствие настройки. Реальные поступления не зачисляются денежным ядром v0.4, поскольку наблюдатели не прошли полный сетевой цикл проверки.

Состояние очереди paused_restore после восстановления — намеренная блокировка, не ошибка. Автоматической кнопки массового возобновления всех восстановленных событий нет: сначала разберите их и повторите только безопасные операции. Повторные оплаченные заказы должны быть идемпотентны и на стороне магазина.

Три разные резервные копии

Снимок БД в админке — согласованная копия SQLite с контрольной суммой. Он не содержит APP_KEY, документов и расходных ключей. Подходит для дополнительной диагностики, но не единственная копия.

Зашифрованная runtime-копия сайта создаётся Python-программой site_backup.py: .env с APP_KEY, SQLite snapshot, VERSION и зашифрованные файлы документов. Она не включает исходный код сайта, runtime-логи всех видов и локальные ключи кошельков. Лимит формата — 64 МиБ содержимого; для больших БД нужен другой отдельно протестированный регламент.

Копия PRIVATE_KEEP_LOCAL — кошельки, ключ манифестов, ключ разрешений, политика, локальная история и версии программ. Только эта копия восстанавливает доступ к вашим приватным кошелькам. BACKUP_PRIVATE.bat архивирует соответствующие папки; сам ZIP не добавляет шифрование, внутри находятся уже зашифрованные vault-файлы. Не складывайте в него раскрытые ключи.

Создание зашифрованной runtime-копии

Остановите сайт и все окна обработчиков. Из PRIVATE_KEEP_LOCAL выполните:

python site_backup.py create "C:\CryptoGate\PUBLIC_UPLOAD\cryptogate.local" "D:\CryptoGateBackups\runtime-001.vault.json" --services-stopped

Пароль вводится скрыто дважды. Выходной файл хранится вне папки сайта, существующий файл не перезаписывается. Сохраните пароль отдельно. Подтверждение --services-stopped — ваше подтверждение, программа не умеет надёжно остановить все внешние процессы за вас.

Учебное восстановление

Используйте новую пустую папку, не работающий сайт:

python site_backup.py restore "D:\CryptoGateBackups\runtime-001.vault.json" "C:\CryptoGateRestoreData" --services-stopped

До записи проверяются пароль, целостность и безопасные пути. Далее проверяется SQLite integrity, отзываются административные и магазинные сессии, ставятся паузы расходов/production и очередей, удаляются старые аренды. Создаётся RESTORE_RECEIPT.json. В комплекте программных тестов этот процесс проверяется на временной базе, но не заменяет восстановление ваших реальных данных.

Распакуйте исходный код той же версии в отдельное место, перенесите туда восстановленные .env и storage, проверьте права и запустите только локально. Сначала выполните проверки и сверку, сравните число магазинов, счетов, адресов, проводок и документы. Не возобновляйте очереди без разбора повторов. При подозрении на компрометацию также отзовите API-ключи и замените webhook-секреты: обычное восстановление само по себе их не ротирует.

Восстановление не перезаписывает записанные ранее immutable-проводки. Служебные паузы отражены отдельной квитанцией; для внешнего аудита её необходимо хранить независимо. RPO/RTO, HA, независимое хранилище резервов и круглосуточное оповещение в этом релизе не гарантируются.

Сверка пяти модулей с реализацией v0.4

Денежная граница

Генерация реального адреса не считается готовностью сети. Все production-флаги выключены. Денежное зачисление разрешает только SIM-поступления на TEST-адреса. Настоящие watcher-наблюдения можно изучать, но они не признаются оплаченными заказами. Исходные 14 watcher-адаптеров сохранены, не объявлены проверенными заново.

Невыполненные части не маскируются кнопками. Таблица возможностей показывает chain_signer=not_implemented. Ни одна проверка симулятора не заменяет тесты на реальных/тестовых блокчейнах, обработку восстановления после реорганизации и проверку безопасности расходных ключей.

Основные зависимости

PaymentService → точная арифметика → единая DB-транзакция → проводки + аудит + webhook. TreasuryService → PaymentService/ledger → reservations → compliance/limits → owner approval → повторная проверка → локальное списание. MerchantAuth/API → идентификация магазина → ограничения полномочий → те же сервисы, без отдельной денежной логики в HTML. Queue → идемпотентные сервисы + lease → heartbeat. Backup → остановка обработчиков → согласованный snapshot + APP_KEY/documents → шифрование → проверка восстановления.

Известные ограничения и запрет боевого запуска

1. Реальные расходные транзакции не строятся/не подписываются/не отправляются. Ed25519 approval — только разрешение локальной операции. Production заблокирован; замена флага в БД не завершает реализацию.
2. Реальные приём, reorg/reconfirmation, sweep, возврат, сетевые комиссии и независимая сверка для 14 сетей не прошли end-to-end. В v0.4 реальное зачисление дополнительно отключено. Нужны проверенные контракты токенов, RPC и интеграционные тесты по каждому направлению.
3. Генерация TON/Monero в среде сборки пропущена из-за отсутствующих библиотек. 12 остальных генераторов проверены программно; независимый аудит собственных алгоритмов кодирования/Keccak не проводился. До финансирования кошельков нужен независимый тест восстановления и расходования.
4. PHP pdo_sqlite/curl отсутствовали в среде сборки. Бизнес-регрессии и HTTP выполнялись через тестовый PDO-совместимый адаптер к настоящему libsqlite3 через FFI. Он не является промышленным драйвером и не поставляется как обход отсутствия расширений. Нативный PHP+PDO SQLite запуск, Windows/OpenServer и доставка webhook остаются отдельными проверками на вашем стенде.
5. PostgreSQL миграция v0.4 не реализована; старый SQL-файл не даёт совместимости. Нет тестов масштабирования, failover и нагрузочного SLA.
6. AML/KYC провайдер и антивирус не подключены. Одобрение оператора не равно юридическому разрешению работать. Не загружайте реальные документы до завершения мер защиты и правил обработки данных.
7. Админский TOTP и replay-защита реализованы; merchant TOTP, полноценное доверие устройствам и внешняя security-аналитика ещё отсутствуют. Hash-chain в одной БД не является внешним неизменяемым аудитом.
8. Публичные ключи/манфесты защищают импорт, но компрометация сервера всё равно может подменить публичный экран. Нужны усиление развёртывания и независимый аудит. Шифрование локальных vault не защищает уже заражённый компьютер владельца.
9. Требования библиотек заданы диапазонами, полного supply-chain lock/SBOM пока нет. Не обновляйте автоматически. Новая версия требует повторного self-test.
10. Банковские карты, Apple Pay/Google Pay, обмен, Lightning, marketplace split и CMS-плагины не реализованы. Регулярные счета не являются автоматическим списанием.
11. Криптографическая ротация owner-key, аппаратный signer, независимая сверка RPC при подписании и фактическая сетьвая комиссия — незавершённые обязательные задачи перед деньгами.
12. Симулятор не выставляет настоящие network fees. Комиссионный резерв в том же активе упрощён. Пользовательские списки имеют лимиты, произвольные аналитические разрезы и все фильтры ТЗ не реализованы полностью.

Отчёты должны различать PASS, FAIL, SKIP, BLOCKED и NOT_RUN. Отсутствие ошибки lint не означает корректность криптопроцессинга. Формулировку «после пяти модулей останется только дизайн» из прежнего планирования считать неверной: остаются существенные денежные и эксплуатационные задачи.