Пермиссионный эмитент токенов с фиксированным предложением для Kaspa

Kaspa Toccata принесла ковенанты в основную сеть — программируемые ограничения на то, как можно потратить UTXO. Это открывает дверь для пользовательских токенов. Но «открыть дверь» и «безопасно войти» — это разные задачи. Эталонная реализация KCC20 в SilverScript до сих пор суммирует знаковые значения токенов без защиты от переполнения в положительную сторону; локальный тест на свежем снимке показал, что VM приняла отрицательную аллокацию и «раздула» баланс с 1000 до 1400. Пермиссионному эмитенту нужно решать этот класс ошибок на уровне контракта, а не надеяться, что каждый интегратор напишет безупречный клиентский код.

В этой статье описывается планируемая архитектура Kaspa Forge Tokens — а именно профиль KF20-FIXED-v1: эмитент взаимозаменяемых токенов с фиксированным предложением и однократным генезисом, построенный на ковенантах Kaspa. Tokens ещё не запущен. Спецификация P0 заморожена, работа над контрактом и генератором P1 ведётся в изолированном репозитории, но независимый пакет доказательств консенсуса, промышленное развёртывание и публичная инфраструктура пока не созданы. Всё, описанное здесь, — это проект и его обоснование, а не приглашение воспользоваться развёрнутым сервисом.

Какую задачу решает эмитент токенов

Создание взаимозаменяемого токена на UTXO-цепочке означает ответить на четыре вопроса:

1. Откуда берётся запас? Кто-то должен зафиксировать начальные аллокации в ончейн-выходах, и сделать это один раз. 2. Как работают переводы? Каждая трата UTXO с токенами должна проверять, что отправитель действительно владеет токенами, и что общий запас сохраняется. 3. Что останавливает инфляцию? Если арифметическая ошибка или небрежный скрипт позволят выходу перевода заявить больше токенов, чем было на входах, запас незаметно раздуется. 4. Кто хранит ключи? Если центральный минтер или платформенный ключ может чеканить произвольные суммы, вы получили кастодиальный токен с блокчейн-обёрткой.

На Kaspa ковенанты (активированные Toccata в основной сети) позволяют скрипту проверять структуру собственных последующих выходов. Это значит, что токен-UTXO может обеспечить сохранность — *выходы моей транзакции потрачивания должны нести ровно мою сумму токенов* — на уровне консенсуса, не доверяя ни одному оффчейн-актору.

Проблема в том, что необходимая инфраструктура находится на стадии черновика. KCC-0001, KCC-0002 и KCC-0020 находятся в основной ветке репозитория KCC, но сохраняют статус *Draft*. KCC-0021 (метаданные) — открытый PR. Официальный пример KCC20 в SilverScript оказался способен принимать отрицательные суммы без ошибки. Эмитент, скопировавший этот паттерн, унаследовал бы ту же арифметическую дыру. KF20-FIXED-v1 был спроектирован с нуля, чтобы её закрыть.

Как работает механизм

Раскладка состояния

Каждый токен-UTXO KF20-FIXED-v1 кодирует 77-байтовое строго положительное состояние. Точная байтовая раскладка заморожена в спецификации P0 — ширины, порядок полей и правила кодирования нативны для компилятора, то есть компилятор SilverScript генерирует код валидации напрямую из определений типов, а не полагается на вручную написанные ABI-проверки.

Состояние содержит необработанную сумму токенов, 32-байтовый ключ владельца (x-only P2PK Schnorr) и внутренние классификационные байты. Все суммы проверяются на положительность: контракт отвергает любую транзакцию-наследника, чьи токен-выходы в сумме дают отрицательное или нулевое значение. Это прямое исправление ошибки со знаковыми суммами в upstream KCC20 — не клиентская проверка, а ончейн-арифметический инвариант, обеспечиваемый самим скриптом ковенанта.

Прямой генезис — без фабрики

Типичный паттерн для ончейн-токен-систем — это фабричный контракт: единая авторитетная программа, порождающая новые семейства токенов. KF20-FIXED-v1 не использует фабрику. Вместо этого замороженный генератор создаёт уникальное семейство напрямую:

1. Пользователь предоставляет метаданные, запас, десятичные знаки, аллокации.
2. Генератор собирает точную транзакцию генезиса.
3. Первый outpoint финансирования + все чистые токен-выходы → Covenant ID.
4. Covenant ID детерминирован: любой может пересчитать его из тех же
   входов и убедиться, что он совпадает с отправленным.
5. KIP-20 (ончейн) проверяет, что формула нового Covenant ID и
   авторизованный набор выходов корректны для объявленного шаблона.

Covenant ID *является* идентификатором токена. Нет центрального реестра, нет админ-ключа и нет минтинг-полномочий, встроенных в выходы генезиса. После генезиса единственный способ потратить токен-ячейку — предоставить корректного наследника, проходящего проверки ковенанта на сохранность и авторизацию.

Почему прямой генезис работает без выполнения токен-скрипта при создании — это тонкий момент: KIP-20 проверяет *происхождение* нового ковенанта — формулу, порождающую его ID, и набор авторизованных выходов, — но не запускает программу создаваемого выхода. Доказательства положительного запаса и непротиворечивости метаданных выполняются во внутреннем верификаторе допуска Kaspa Forge на точных байтах цепочки, а не в движке консенсуса. Любой может развернуть некорректный подделку вне платформы — он получит другой Covenant ID и не пройдёт классификацию history_verified в Kaspa Forge.

Сохранность при переводах

Как только токен-ячейка существует, каждая транзакция потрачивания должна удовлетворять ковенанту:

• Авторизация: отправитель предоставляет корректную подпись Schnorr для ключа владельца из состояния.
• Сохранность: сумма необработанных токенов на всех токен-выходах равна сумме на всех токен-входах. Никакого частичного сжигания, никакой скрытой инфляции.
• Контроль формы: выходы должны использовать тот же профиль, хеш шаблона и режим владельца. Входы из разных семейств и неизвестные типы владельцев отклоняются.
• Финансовая обёртка: транзакция должна содержать сдачу в KAS (при необходимости) и сетевую комиссию в пределах лимита. Резерв KAS на каждую токен-ячейку вычисляется при генезисе и проверяется при каждой трате.

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

Граница подписи

Модуль token-wallet-wasm — это не универсальный кошелёк-подписьщик. Его интерфейс предоставляет небольшой набор типизированных операций:

template_manifest()
preview_fixed_genesis(intent, utxos, fee_quote)
verify_and_sign_fixed_genesis(intent, observed_package, wallet_key)
preview_transfer(intent, token_cells, kas_utxos, fee_quote)
verify_and_sign_transfer(intent, observed_package, wallet_key)

Ключевое свойство: подписьщик реконструирует транзакцию с нуля на основе входов, наблюдаемых нодой, а затем сравнивает реконструкцию с намерением пользователя. Он не подписывает вслепую всё, что передаёт интерфейс. Он проверяет сеть, версию профиля, ID токена, каждую сумму, каждого владельца, значения KAS, форму выходов, массу и комиссию — ещё до того, как ключ коснётся подписи.

Ключ существует только внутри разблокированной сессии Desk. Временные буферы обнуляются после подписи. Сервер никогда не видит сид, никогда не собирает транзакцию и никогда не владеет полномочием подписи.

Как Kaspa Forge планирует это использовать

Планируемый процесс внутри Desk:

1. Пользователь открывает вкладку Tokens и разблокирует свой профиль. 2. Выбирает «Фиксированный запас», заполняет метаданные, десятичные знаки, необработанный запас и аллокации на конкретные P2PK-адреса. 3. Интерфейс проверяет поля, дедуплицирует тикер/название и вычисляет канонический дайджест метаданных. 4. token-wallet-wasm получает текущие UTXO кошелька и котировку комиссии ноды, собирает транзакцию генезиса и вычисляет будущий Covenant ID. 5. Экран подтверждения показывает: ID токена, необработанный/читаемый запас, каждого получателя, резерв KAS на ячейку, сетевую комиссию. В KF20-FIXED-v1 сервисная комиссия равна нулю — комиссионного выхода нет. 6. Пользователь подтверждает паролем; WASM-подписьщик пересобирает, проверяет и подписывает точную транзакцию. 7. Типизированный серверный эндпоинт выполняет собственные проверки допуска и отправляет подписанную транзакцию в подключённую ноду Kaspa. 8. Интерфейс отслеживает состояние: submitted → accepted → indexed. Только после indexed токен получает значок подтверждённой истории и появляется в публичном каталоге.

Отдельный индексер — не разделяемый с инфраструктурой Safe, Escrow или Arena — реконструирует всё токен-состояние из принятой виртуальной цепочки. Ключевые сущности:

Балансы и списки держателей — производные представления, пересчитываемые из канонических живых ячеек. Отдельный журнал отмен обрабатывает реорганизации цепочки атомарно.

Публичный API для чтения планируется следующим образом:

GET  /api/safe/tokens/templates
GET  /api/safe/tokens/{covenant_id}
GET  /api/safe/tokens/{covenant_id}/holders
POST /api/safe/tokens/submit

Эндпоинты чтения не требуют полномочий для публичных данных цепочки. Эндпоинт submit принимает только полностью подписанную транзакцию KF20 и перезапускает допуск. Загрузка метаданных имеет отдельный лимит частоты и никогда не влияет на возможность потратить токен.

Компромиссы и честные границы

Чем жертвует первая версия

• Нет минтинга. Запас фиксируется при генезисе. Если вам нужен механизм продолжающегося выпуска, вам нужен будущий профиль (KF20-CAPPED-v1), а не флаг в первой версии. Вариант с лимитом разделяет ячейки-активы и ячейку-контроллер, хранящую max_supply, minted_supply и полномочие минтинга — но это пункт дорожной карты, работа над которым начнётся только после стабилизации фиксированного запаса в основной сети.

• Режим единственного владельца. Токены первой версии принадлежат ровно одному 32-байтовому P2PK-ключу Schnorr. Никакого мультисига, таймлока или DAO-управления на уровне токена. Это отдельные профили или расширения, а не скрытые флаги.

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

• Нулевая сервисная комиссия. Kaspa Forge не взимает ничего за создание или перевод токенов. Единственные расходы — сетевая комиссия Kaspa, которую подписьщик вычисляет и ограничивает сверху.

Проблема с арифметикой в upstream

Эталонный пример KCC20 в SilverScript (kaspanet/silverscript) суммирует токен-суммы в знаковом целом без защиты от положительного переполнения и без проверки на переполнение. Исторический тест на снимке d57e5dff показал, что VM приняла отрицательную аллокацию и раздула симулированный баланс. По состоянию на master@140bf184 (на 25 коммитов впереди пина для Tokens) эта ошибка сохраняется — обновление компилятора не исправляет арифметику на уровне протокола.

KF20-FIXED-v1 решает это следующим образом:

1. Обеспечение строго положительного кодирования в 77-байтовом состоянии. 2. Проверяемые суммы на всех токен-выходах-наследниках. 3. Отклонение любой транзакции, в которой поле суммы или совокупная сумма могут быть отрицательными или нулевыми.

Это ончейн-проверки консенсуса, а не клиентские валидации.

Текущий статус разработки

Никакая архитектурная элегантность не заменяет прохождения этих этапов. Байты контракта существуют и компилируются воспроизводимо, но «компилируется» — не значит «развёрнут», а «развёрнут» — не значит «аудирован».

Дорожная карта KCC20

Будущий профиль KF20-KCC20-v1 будет использовать нативный формат состояния KCC-0020 (структура KCC20State из шести полей в каноническом порядке, четырёхбайтовый BLAKE3-диспетч, точки входа transfer/transfer_delegator). Он получит собственное семейство Covenant ID, пространство артефактов, версию классификатора и независимый аудит. Работа начнётся только после стабилизации KF20-FIXED-v1 в основной сети — и только если черновик KCC-0020 будет финализирован, а арифметические проблемы в эталонном примере upstream устранены. Argent (компилятор для actor/spawn) — опциональная исследовательская зависимость для этого профиля, а не производственное требование.

Модель безопасности

Ключевое свойство безопасности: Kaspa Forge никогда не владеет вашими токенами и никогда не хранит ваши ключи. Токен-UTXO — это стандартный выход P2SH в DAG Kaspa. Если сервис Kaspa Forge исчезнет, токены по-прежнему можно потратить — при условии, что у вас есть ваш ключ и вы можете собрать корректную транзакцию ковенанта на любой ноде Kaspa версии 2+. Открытые контракты и инструменты (github.com/Kaspaforge/kaspaforge) позволяют сделать именно это из терминала, используя vaultctl или любой совместимый подписьщик.

Что *обеспечивает* Kaspa Forge — это слой безопасности: интерфейс, который не позволяет отправить некорректную транзакцию, проверки допуска, ловящие арифметические ошибки и ошибки формы до попадания в мемпул, и индексер, дающий верифицированное представление о состоянии токенов. Ничто из этого не является консенсусом — это инженерия, делающая пермиссионный контракт пригодным для использования без необходимости стать протокольным экспертом.

---

*Эта статья отражает архитектуру по состоянию на август 2026 года. Kaspa Forge Tokens — планируемый продукт, а не запущенный. Актуальную информацию о продуктах на ковенантах, работающих в основной сети Kaspa, смотрите в разделах Kaspa Safe, Escrow и Arena Blackjack.*