BEYUL Whitepaper — Pre-Testnet Edition: Архитектура и модель раскрытия

Это перевод. Английская версия является единственной канонической (canonical), и в случае противоречия преимущественную силу имеет английская версия. Технические идентификаторы (BEYUL, BYL, privacychain, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16 и др.) остаются непереведёнными, на английском.

Проект: BEYUL　Тип: исследовательский прототип публичной цепочки с приватностью (pre-testnet). Работа над протоколом BEYUL в настоящее время ведётся в репозитории privacychain. Статус документа: whitepaper BEYUL, редакция pre-testnet (исследовательская) — описывает архитектуру протокола, модель раскрытия и текущие границы до публичного testnet. Это не спецификация продакшн-протокола, не инвестиционный документ, не заключение о соответствии, не аудит безопасности, не материал по выпуску токенов и не анонс mainnet. Заявления о возможностях следуют дисциплине доказательств из §3.1; ничто здесь не описано выше своей реальной зрелости. Статус токена: токеномика не финализирована. BYL — это лишь краткая форма / тикер проекта; это не замороженная деноминация — деноминация и параметры цепочки остаются на рассмотрении и требуют явного одобрения Owner. Данный документ не определяет распределение токенов или дизайн полезности. Тестовые токены, если используются, не имеют денежной ценности и не обещают конвертацию в mainnet. Канонический язык: английская версия является единственной канонической. Китайская версия (beyul-whitepaper-pretestnet.zh.md) — это сопроводительный рабочий текст; в случае противоречия преимущественную силу имеет английская версия.

Рамка границ заявлений (прочтите сначала)

Данный документ не делает ни одного из следующих заявлений:

• Никакого заявления об анонимности, неотслеживаемости или «абсолютной безопасности»;
• Никакого заявления о продакшн-уровне zero-knowledge безопасности (текущая реализация использует материал development-key);
• Никакого заявления о продакшн-приватности (суммы депозита и вывода в настоящее время публичны on-chain);
• Никакого заявления о регуляторном одобрении или «compliance by design»;
• Текущий дизайн не включает контролируемый проектом глобальный viewing key; это свойство должно быть проверено через открытую реализацию, тесты и внешний аудит;
• Не существует ни публичного testnet, ни mainnet; готовность testnet в процессе — многоузловой runbook и связанные gate ещё не завершены;
• Никаких обещаний о ценности токена, airdrop, доходности, возврате или листинге на биржах; данный документ не обсуждает кошельковые продукты или DeFi;
• 16-character disclosure code не является базовым криптографическим удостоверением безопасности (Раздел 7).

Именование и технические идентификаторы. BEYUL — это название проекта/продукта; работа над протоколом BEYUL ведётся в репозитории privacychain. privacychain остаётся текущим техническим идентификатором — репозиторий, пакет протокола/модуля/proto, бинарник и chain-id — и сохраняется без изменений. BYL — краткая форма / тикер; деноминация и параметры цепочки требуют явного одобрения Owner, поэтому BYL не является замороженной деноминацией. Эта дисциплина именования применяется только в будущем: исторические документы не переименовываются задним числом.

1. Аннотация

BEYUL — это проект публичной цепочки с приватностью на стадии исследовательского прототипа (pre-testnet), исследующий платёжную инфраструктуру с приватностью по умолчанию (целью проектирования) и раскрытием под контролем пользователя. В целевом дизайне детали транзакции по умолчанию не видны публично, но владелец актива может добровольно раскрыть, с ограниченной областью, выбранной стороне — Transaction Disclosure Code (TDC) объясняет одну транзакцию; Asset Disclosure Code (ADC) раскрывает выбранный снимок активов. «Приватность по умолчанию» описывает цель проектирования, а не текущий прототип (см. §5).

То, что существует сегодня, — это лишь клиентский прототип деривации disclosure-code (протестированный локально; публичный пакет доказательств ожидает консолидации) и прототип chain-application на основе Cosmos SDK. Сквозные серверные grant, проверка on-chain и ZK balance proof не реализованы; нет trusted setup, нет внешнего аудита, нет публичного testnet или mainnet; суммы депозита и вывода в настоящее время публичны on-chain. Цель данного whitepaper (редакция pre-testnet) — точно зафиксировать архитектурное направление, модель раскрытия и текущие границы до запуска публичного testnet — и быть заменённым продакшн-редакцией лишь тогда, когда появятся соответствующие доказательства и аудиты.

2. Позиционирование и проблема

Публичные реестры раскрывают платёжные связи, балансы и потоки средств любому наблюдателю; при этом большинство систем сильной приватности делают избирательное раскрытие операционно трудным — объяснение одной транзакции стороне часто означает передачу возможности видеть всё. Пробел, который исследует BEYUL: сделать «раскрытие» примитивом первого класса наравне с «сокрытием», при этом всякое раскрытие инициируется пользователем.

BEYUL не конкурирует за — и не нацелен на — нарратив «полностью анонимный, неотслеживаемый».

Видение. Финансовая приватность в публичных реестрах перевёрнута: по умолчанию обнажена, тогда как сокрытие само по себе выглядит подозрительно. Цель BEYUL — перевернуть этот default — приватность как состояние по умолчанию, а раскрытие как осознанный, детализированный выбор пользователя: какую транзакцию, какие поля, кому и на какой срок.

Принципы проектирования. Каждая часть протокола подчиняется им:

1. Раскрытие — гражданин первого класса — примитивы раскрытия проектируются и прототипируются на одном уровне с примитивами сокрытия.
2. Минимальные полномочия — каждый ключ и удостоверение несёт лишь минимальные полномочия, необходимые для его назначения.
3. spend authority священна — никакой поток раскрытия не может касаться spend authority; мнемоника никогда не входит ни в один шаг раскрытия.
4. Никаких глобальных привилегий — протокол спроектирован так, чтобы не предоставлять никакого глобального канала просмотра проекту или третьим лицам; отсутствие любой такой ветви — это свойство дизайна, подлежащее проверке через открытую реализацию, тесты и внешний аудит (§6), пока не гарантия.
5. Честность границ — каждая возможность заявляет, чего она не делает; модель угроз и ограничения остаются публичными.
6. Сначала доказательства — заявления о возможностях повышаются лишь после появления доказательств (код, тесты, аудиты) — на основе gate, без обещаний дат.

2.1 Как сравнивается раскрытие BEYUL

Таблица сравнивает целевой дизайн BEYUL с текущими поставленными возможностями других систем. Перечисленные ниже отличительные особенности BEYUL (истечение, отзыв, видимость, навязываемая консенсусом, область по-транзакции/по-снимку с серверной и on-chain проверкой) в основном планируются или являются клиентским прототипом (см. §3, §7), ещё не поставлены. Факты о конкурентах изложены консервативно; пункты, не перепроверенные независимо для данного whitepaper, помечены 【to verify】.

Предполагаемое отличие — не «более сильное сокрытие», а более детализированное, ограниченное во времени раскрытие, выпускаемое пользователем: там, где viewing key Zcash/Monero — это разрешение на чтение на уровне аккаунта, всё-или-ничего и бессрочное, удостоверение раскрытия BEYUL ограничено одной транзакцией (TDC) или одним снимком актива (ADC), несёт истечение и спроектировано отзываемым — при этом набор видимых полей навязывается консенсусом, а не соглашением кошелька. Эти свойства являются целями проектирования; их статус реализации честно отслеживается в §3 и §7.

Источники. Zcash/Monero: отчёт о глубоком исследовании ZEC/XMR данного проекта (первичные источники — Zcash Protocol Specification; документация Monero; по состоянию на 2026-06-12). Строки Penumbra / Aztec / Namada описывают официальную документацию каждого проекта по состоянию на 2026-06 (Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts). Оставшиеся пункты 【to verify】 — истечение/отзыв и семантика transaction-perspective у Penumbra, нативное истечение/отзыв у Aztec, точная семантика отзыва у Namada — ожидают подтверждения. Эти строки излагают то, что описывает документация каждого проекта, а не утверждения о том, чего другие системы «не могут».

3. Текущий статус

3.1 Цепочка доказательств

Каждая строка «прототип реализован» выше привязана к записи доказательства, а не утверждается прозой. Цепочка доказательств (commit hash, запись CI, точная команда теста и вывод, воспроизводимые инструкции запуска) ведётся в Evidence Appendix, и каждая возможность оценивается по шкале исследовательской зрелости L0–L5 (дизайн → прототип → воспроизводимо → отрецензировано → сетевое доказательство → продакшн). Данный whitepaper ссылается на этот реестр, а не повторяет сырые доказательства.

Текущая самооценка: большая часть материала на уровне L1–L2, ничего на L5. Пока записи Evidence Appendix не заполнены (commit/CI), публичные материалы говорят «проверено локально; публичный пакет доказательств ожидает консолидации», а не «реализовано с публичными доказательствами». Возможность без зарегистрированной записи доказательства не может описываться выше своего уровня зрелости. Evidence Appendix находится в docs/evidence-appendix.md (внутренний; будет опубликован вместе с публичным пакетом доказательств); E1/E3/E4 воспроизведены в режиме только чтения 2026-06-19, привязка CI ещё ожидается.

4. Техническая модель

Прототип сосредоточен вокруг конечного автомата shielded-pool. Для некриптографа жизненный цикл приватного баланса проходит так:

1. Note. Расходуемый баланс — это note — запись из (владелец, сумма, случайность). Сама note никогда не появляется on-chain.
2. Commitment. Цепочка хранит лишь commitment к note (односторонний связывающий хеш), добавляемый в Merkle commitment tree только для добавления. Из одного commitment наблюдатель не узнаёт ни владельца, ни сумму.
3. Spend → nullifier. Чтобы потратить note, владелец публикует производный от неё nullifier. nullifier спроектирован так, чтобы внешние наблюдатели не могли связать его с commitment (при допущении PRF nullifier-key; yellow paper §7.1), но для этой note он детерминирован — так что одна и та же note может быть аннулирована лишь однажды.
4. Отклонение double-spend. Цепочка ведёт множество nullifier; повторный nullifier отклоняется. Это предотвращает double-spend, не раскрывая, какая note была потрачена.
5. Доказательство корректности. Каждый spend несёт zero-knowledge доказательство того, что «я владею note, чей commitment в дереве, и я корректно вывел её nullifier», не раскрывая ни одного из этих значений. Проверка проходит через путь Groth16.

Текущий верификатор использует материал development/skeleton verifying-key без trusted setup и не устанавливает продакшн-soundness или приватность. Стандартная внешняя формулировка: «Прототип включает путь проверки Groth16 на development-key. Он пока не обеспечивает продакшн-уровень zero-knowledge безопасности.» Формальные определения формата note, схемы commitment, деривации nullifier и семантики дерева см. в yellow paper §§5–7 и §10.

4.1 Почему отдельная цепочка и почему Cosmos

Модель раскрытия требует контроля над вещами, которые развёртывание смарт-контракта на общей L1 или универсальный rollup не дают чисто:

• Видимость раскрытия, навязываемая консенсусом (§6) и правила целостности предложения shielded pool должны находиться на уровне перехода состояний / консенсуса, а не внутри контракта, чьи валидаторы хост-цепочки и рынок комиссий вне контроля проекта.
• Нативное shielded состояние (commitment tree, множество nullifier, учёт value-balance) дешевле и аудируемее как первоклассное состояние цепочки, чем как хранилище контракта, и избегает того, чтобы публичный mempool и модель метаданных хост-цепочки утекали больше, чем предполагалось.
• Набор валидаторов bonded-PoS позволяет целостности предложения перепроверяться каждым full node и даёт мгновенную финальность, подходящую для платежей.

Cosmos SDK + CometBFT выбран ради зрелого BFT-PoS стека с модулями staking/slashing, суверенным управлением апгрейдами и мгновенной финальностью — а не как одобрение какой-либо токен-модели (ни одна не финализирована). Это обоснование выбора архитектуры, а не утверждение, что отдельная цепочка развёрнута; реальный статус см. в §3 и §8.

4.2 Характеристики производительности

Два типа цифр держатся раздельно. Присущие (на уровне схемы, цитируемые): Groth16 над кривой BN254 имеет доказательства постоянного размера (три элемента группы: 2×G1 + 1×G2, ~128 Б сжато / ~256 Б несжато на BN254) и проверку за постоянное время (фиксированное, малое число pairing-проверок, не зависящее от размера схемы). Это следует из самой системы доказательств, а не из реализации BEYUL. На уровне системы (ещё не измерено): время доказательства, пропускная способность транзакций (TPS) и размер схемы (число ограничений) зависят от продакшн-схемы, которая не построена — текущий путь использует dev/skeleton verifying key (§4). Поэтому любая такая цифра — это target / 【to be supplied】, подлежащая бенчмаркингу, когда появятся продакшн-схема и путь trusted-setup-или-прозрачного-доказательства (Roadmap §10, Phase 6). Выше этой линии никакая цифра производительности уровня системы не заявляется.

5. Модель приватности и текущие ограничения

Текущий прототип не является продакшн-приватностью.

При pre-testnet / низком использовании anonymity-set мал или пуст; без реальных пользователей приватность внутри пула не устанавливается значимо — сильная приватность зависит от большого, активного anonymity-set и НЕ заявляется, пока не появится реальное использование. Упорядочивание/MEV на уровне валидаторов и сетевые метаданные остаются несмягчёнными.

Формальная рамка anonymity-set (как определяется и ограничивается anonymity-set shielded pool) ведётся в yellow paper (§15); данный раздел излагает цели приватности и текущие ограничения, а не ту формальную модель.

6. Модель ключей и раскрытия

От высших к низшим полномочиям: Spend Key (единственное полномочие траты; никогда не покидает устройство пользователя; никогда не участвует в потоках раскрытия) → Full View Key (только чтение; планируется разделение входящего/исходящего) → Audit Key (планируется: добровольно выпускается пользователем; ограничен по времени, по области, отзываемый; не навязанный протоколом канал) → Disclosure Credential (минимальная единица раскрытия, привязанная к одной транзакции или одному снимку актива) → 16-character disclosure code (входной короткий код; не ключ).

Граница полномочий просмотра проекта: текущий дизайн не включает контролируемый проектом master viewing key. Это свойство должно быть проверено через открытую реализацию, тесты и внешний аудит, а не основываться на доверии команде — пути деривации ключей поставляются как open source, и любая третья сторона может аудировать граф деривации на отсутствие любой ветви, ведущей к проекту. До завершения внешнего аудита это «свойство дизайна, подлежащее проверке», а не «гарантия».

Политика мнемоники (планирование архитектуры, а не поставленный продукт): корневой ключ кошелька по умолчанию использует мнемонику из 24 слов (BIP39), а нижестоящие ключи выводятся через разделение доменов (HKDF + domain tags). Мнемоника никогда не должна появляться ни в одном потоке раскрытия; ни disclosure code, ни link_secret не могут быть выведены из одной мнемоники — grant TDC/ADC генерируются в момент добровольного раскрытия с помощью CSPRNG и локальной авторизации.

Граница видимости раскрытия (требование дизайна): видимая область удостоверения раскрытия — включая видимость исходящего направления — планируется гарантироваться правилами уровня консенсуса, а не соглашением реализации кошелька (отраслевой урок из Zcash, где исходящая видимость зависит от соглашения кошелька); это требование появляется со стеком on-chain проверки (roadmap Phase 5) и сегодня не реализовано.

Слой Disclosure Grant (в ожидании независимой проверки): слой Disclosure Grant — область, истечение, отзыв, журнал аудита и права viewer — ожидает независимой продуктовой и проверки безопасности. Пока эта проверка не завершена, ни на одно из этих граничных свойств нельзя полагаться, и никакой документ не может подразумевать, что они установлены.

7. Прототип раскрытия TDC / ADC

7.1 Терминология и кодирование

Официальный термин — «16-character Crockford Base32 disclosure code» (алфавит исключает легко путаемые символы I/L/O/U; энтропия короткого кода ~80 бит), сокращённо «16-character disclosure code». Формулировки вроде «16-digit code» или «16-digit security code» не используются — чисто числовая схема (~53 бита) отклонена из-за недостаточного бюджета энтропии.

«16-character disclosure code не является базовым криптографическим удостоверением безопасности. Это удобная для пользователя точка входа доступа; реальная авторизация должна совместно защищаться высокоэнтропийным disclosure credential, подписями, ограничениями области, истечением и логикой проверки.»

7.2 Реальное текущее состояние (обязательно к прочтению)

То, что есть у BEYUL, — это протестированный локально клиентский прототип деривации TDC/ADC. Сквозные серверные grant, проверка состояния цепочки и ZK balance proof планируются и не реализованы. Поэтому НЕЛЬЗЯ утверждать, что: проверяемое раскрытие реализовано; средства уже можно доказать; ADC может доказать точные балансы; или disclosure code можно проверить on-chain.

Клиентский прототип покрывает (протестировано локально): двухфакторный KEK (link_secret + 16-символьный код, оба обязательны); каноническое кодирование; привязку ролей отправителя/получателя TDC; разделение доменов TDC/ADC (ни один не может открыть другой); AEAD envelope с защитой от подмены AAD (клиентский TDC/ADC envelope; AAD on-chain envelope MsgDiscloseNote по-прежнему target — yellow paper §2.3); верификатор кода slow-hash (целевой набор Argon2id; продакшн-адаптер ещё не подключён); crypto-shredding erasure-key.

7.3 Семантика TDC и ADC

Трилемма раскрытия: система со скрытым владением не может одновременно обещать полноту баланса, отсутствие утечки истории и отсутствие viewing key — пользователь может доказать владение выбранными notes, но без дополнительного источника полноты не может доказать, что ничего не упущено. Поэтому ADC многоуровневый, и ADC раскрывает именно баланс выбранного множества активов на выбранной высоте — его нельзя описывать как «не раскрывает баланс».

Риски ADC (сохраняются публичными): повторные снимки одной и той же стороне раскрывают изменения баланса со временем; раскрытие чистой стоимости — риск физической безопасности и принуждения (ADC по умолчанию выключен и требует явного подтверждения); ротация не может отозвать то, что наблюдатель уже увидел.

7.4 FAQ по disclosure code

8. План testnet (текущий фокус)

8.1 Модель валидатора

Testnet использует модель валидатора BFT в стиле PoS: Cosmos SDK + CometBFT, начальный набор валидаторов и тестовые потоки модуля staking. Это не PoW, и это не экономическая безопасность PoS уровня mainnet — экономическая модель mainnet является долгосрочным исследованием вне области данного whitepaper.

8.2 Готовность testnet (прямо)

Готовность testnet в процессе: многоузловой runbook и связанные gate ещё не завершены (соответствующие pull request не все смержены, и проверки не проходят). Пока эти gate не закрыты и доказательства не зарегистрированы, данный проект не использует формулировку «testnet-ready».

Чек-лист перед запуском: пакет доказательств закрыт; chain-id и genesis testnet; руководство по онбордингу валидаторов; многоузловой runbook на 3+ узла; политика faucet и rate-limiting; политика публичного RPC/API; дашборд мониторинга; процесс реагирования на инциденты; список известных ограничений; поток команд участника; уведомление об отсутствии ценности тестового токена.

8.3 Что testnet может проверить / не может доказать

Может проверить: работу узлов и производство блоков, потоки модуля staking, faucet, RPC, мониторинг и реагирование на инциденты, демонстрационный поток disclosure-code, прототипный поток shielded module. Не может доказать: продакшн-приватность, экономическую безопасность PoS уровня mainnet, ценность токена, регуляторное принятие, продакшн ZK soundness. Запуск testnet нельзя продвигать как «продакшн-валидацию».

8.4 Уведомление участнику

Тестовые токены не имеют денежной ценности и не обещают конвертацию в mainnet; официального кошелька нет — участвуйте только с официально опубликованным инструментарием командной строки и документацией; ни один поток никогда не требует, чтобы ваша мнемоника входила в шаг раскрытия — любой «официальный», запрашивающий вашу мнемонику, — мошенник; в настоящее время нет никакой продажи токенов, частного раунда, whitelist или регистрации airdrop.

8.5 Управление, апгрейды и экономическая граница

На этой стадии pre-testnet у BEYUL нет децентрализованного управления. Апгрейды протокола и критичные для безопасности pin — параметры genesis и закреплённый (pinned) verifying key — контролируются начальным набором валидаторов вместе с Owner. Это прямо заявляемая централизованная модель доверия; она будет постепенно децентрализоваться лишь по мере взросления сети и её управления (нет DAO, нет обещанного графика децентрализации). Запуск валидатора сам по себе не даёт полномочий на апгрейд; pinned VK и genesis меняются только через путь апгрейда «набор валидаторов + Owner».

Экономическая граница. Деноминация, предложение и экономические параметры — это решения Owner — за gate, и не определяются в данном whitepaper (см. Статус токена выше). Ничто здесь не фиксирует деноминацию, предложение или токен-экономическую модель.

9. Модель угроз (публична до смягчения)

Организована по классам противника, согласована с моделью противника yellow paper (A1–A4). Это сводка; yellow paper является авторитетным эталоном модели угроз, и два документа не должны расходиться — при расхождении преимущественную силу имеет yellow paper.

• A1 — Пассивный наблюдатель цепочки (читает только публичные данные цепочки): корреляция сумм при публичных депозитах/выводах, корреляция тайминга, побочные каналы комиссий/gas — не смягчено. Commitments, nullifiers, anchors и счёт чистого потока пула публичны по дизайну.
• A2 — Сетевой/инфраструктурный противник (mempool, RPC, упорядочивание валидаторов, IP): наблюдение mempool, упорядочивание и цензура валидаторов, метаданные сетевого уровня — не смягчено (упорядочивание/цензура частично вне области протокола); внепротокольные метаданные бирж/мостов — вне области.
• A3 — Противник со стороны раскрытия (получатель раскрытия или держатель кода): пересылка раскрытия получателем криптографически неконтролируема; отзыв не реализован; раскрытие временных рядов и чистой стоимости ADC при повторных снимках; принуждённый выпуск — прямо заявлено, не смягчено.
• A4 — Противник на стороне устройства/социальной инженерии (устройство пользователя, фишинг): фишинг и социальная инженерия ради мнемоник или кодов, поддельные кошельки и поддельные официальные каналы — не смягчено; решается через обучение пользователей и список официальных каналов.

Сквозное, нерешённое: баги схемы, trusted setup, внешний аудит — не проверено / не решено / не завершено. Целостность предложения пула (gate G-S) открыта; сохранение и double-spend не заявляются как продакшн-свойства, в ожидании in-circuit и keeper value-balance с согласованностью ширины 128↔64 бит (зеркало yellow paper §12.3). Путаница относительно ценности тестовых токенов и вознаграждений не допускается — тестовые токены не имеют ценности, и любой учёт вознаграждений симулирован.

10. Roadmap (на основе gate, без обещаний дат)

Каждая возможность должна находиться ровно в одном состоянии: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. Ни одно заявление не может быть написано как «реализовано» без commit, записи CI, команды теста и вывода.

Порядок необратим: testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet.

11. Граница соответствия

BEYUL не является решением для соответствия: он не реализует рабочие процессы AML, KYC, travel-rule, заморозки, скрининга санкций или отчётности и не заявляет о «compliant by design». Всякое раскрытие инициируется пользователем; в протоколе нет канала принудительного раскрытия; текущий дизайн не включает контролируемый проектом глобальный viewing key (подлежит проверке через открытую реализацию и аудит). Учреждения и частные лица должны независимо оценивать регуляторную позицию своей юрисдикции в отношении приватных активов.

12. Заявление о рисках и оговорка

Данный документ предназначен только для информационных целей и не представляет собой и не должен толковаться как: предложение или продажа ценной бумаги, товара или финансового инструмента; инвестиционный, юридический, налоговый или финансовый совет; или заявление о соответствии в какой-либо юрисдикции. Он содержит прогнозные заявления (цели проектирования, планы testnet, roadmap), подверженные существенной неопределённости; фактические результаты могут существенно отличаться.

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

13. Заключение

Направление BEYUL — приватность по умолчанию с раскрытием под контролем пользователя. Его заслуживающие доверия активы сегодня: прототип chain-application, протестированный локально клиентский прототип деривации TDC/ADC, а также таблица статуса и модель угроз, строго согласованные с реализацией. Единственный текущий фокус — предпосылки запуска публичного testnet: закрытие доказательств, многоузловой runbook, faucet и мониторинг, документация участника. Пока не появятся соответствующие доказательства, данный проект не делает заявлений о mainnet, токене, продакшн-приватности или соответствии.