Ковенант залога Kaspa — претензии, возвраты и тайм-ауты

Когда вы блокируете KAS в Kaspa Deposit — для аренды, оборудования, фриланс-залога или любого временного удержания — деньги покидают ваш кошелёк и попадают в ончейн-ковенант: небольшую программу, написанную на языке сценариев Toccata для Kaspa. Ковенант решает, кто получит средства и при каких условиях. Ни один человек не может его отменить. Ни один сервер не может его перехватить.

В этой статье описаны все исходы, которые допускает контракт: обычный возврат по соглашению сторон, автоматический возврат при отсутствии претензий, путь спора, решение арбитра и экстренный тайм-аут, который срабатывает, если сам сервис исчезает. Также рассматриваются вопросы сохранения доказательств и реальные ограничения.

Ковенант в двух словах

Kaspa Deposit работает на том же десятипутевом контракте (escrow.sil), что и Kaspa Escrow. Разница — в одной инверсии ролей при создании: вкладчик (тот, кто вносит залог) отображается на слот seller контракта; держатель (арендодатель, заказчик или контрагент) — на слот buyer. Это означает, что каждый стандартный путь — release, refund, dispute, timeout — корректно работает для сценария залога без единого изменения в контракте.

// Концептуально — состояние, хранящееся внутри ковенанта escrow.sil
let mode: u8 = 0;   // 0 = ACTIVE, 1 = DISPUTED

// Параметры конструктора, «запечённые» в адресе ковенанта:
// depositor, holder, arbiter   — публичные ключи
// disputeWindow, arbiterDeadline — в инкрементах DAA score
// timeoutTo  (0 = holder, 1 = depositor)
// feeSpk, feeResolve, feeDispute, feeBudget, initMode

Сам адрес кодирует все одиннадцать параметров. После пополнения UTXO можно потратить только через один из десяти конкретных путей — каждый представляет собой уникальную комбинацию подписей, проверок состояния и временных условий. Вы можете проверить скомпилированный контракт и его опкоды Toccata в опубликованном исходном коде на github.com/Kaspaforge/kaspaforge.

Пять исходов

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

1. Обычный возврат (по соглашению)

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

release(depositorSig) — вкладчик подписывает. Средства возвращаются вкладчику за вычетом комиссии за разрешение (0,5 %, минимум 1,2 KAS). Поскольку вкладчик отображается на слот seller контракта, стандартный release направляет средства ему. Это путь «всё прошло хорошо, верните мой залог».

refund(holderSig) — держатель подписывает. Средства переводятся держателю за вычетом той же комиссии. В контексте депозита это означает, что держатель добровольно отказывается от каких-либо претензий. Это также путь, который держатель может использовать *в ходе* спора для мирного урегулирования.

Оба пути работают в любом режиме — ACTIVE или DISPUTED — так что любая из сторон может закрыть сделку в любой момент. Никакой таймер истекать не должен.

Если обе стороны согласны на индивидуальное распределение (скажем, держатель оставляет 30 % за ущерб), они совместно подписывают транзакцию mutual. Контракт требует, чтобы первый выход был сервисной комиссией — это осознанное архитектурное решение, которое команда называет *anti-bypass K1*, предотвращающее уклонение от комиссий через «хитрые» соглашения. Остальные выходы свободны по формату, но каждый должен превышать 1 KAS (защита от пыли из KIP-9).

2. Автоматический возврат (претензия не подана)

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

Когда вкладчик создаёт Deposit, он настраивает окно, покрывающее срок обслуживания и последующее окно претензии. Держатель может подать претензию в любой момент в течение этого периода. Если окно истекает без поданной претензии, срабатывает путь autoRelease контракта:

// Концептуально — escrow.sil
// Режим ACTIVE, подпись не требуется
if mode == ACTIVE && age >= disputeWindow {
    // отправить весь баланс продавцу (= вкладчику)
    // за вычетом feeResolve
}

Подпись не нужна. Фоновый сервис-вотчер транслирует эту транзакцию автоматически. Вкладчик получает свои KAS обратно за вычетом комиссии за разрешение. Сделка закрыта.

3. Подача претензии (спор)

Если держатель считает, что у него есть обоснованная претензия — повреждённое оборудование, нарушение условий, неоплаченная аренда — он выполняет путь dispute(holderSig) в течение открытого окна. В ончейне это переводит ковенант из состояния ACTIVE в DISPUTED:

• UTXO пересоздаётся с mode = 1.
• Счётчик age сбрасывается в ноль.
• Запускается таймер arbiterDeadline.

Только держатель (= покупатель в контракте) может инициировать спор. Вкладчик не может оспорить собственный депозит — он может только выполнить release, refund или дождаться автоматического возврата.

После перехода в DISPUTED путь автоматического возврата блокируется. Оставшиеся пути требуют либо подписи арбитра, либо истечения срока арбитра.

4. Решение арбитра

В режиме DISPUTED становятся доступны три пути — все требуют подписи арбитра:

Арбитр не может отправить средства себе или какой-либо третьей стороне. Ковенант проверяет каждый выход по допустимому набору и отклоняет всё остальное. Это обеспечивается на уровне консенсуса — это математическое свойство скрипта, а не политика платформы.

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

5. Экстренный тайм-аут (арбитр бездействует)

Что если арбитр так и не ответит — сервис отключится, оператор исчезнет? В контракте есть жёсткий резервный механизм, не требующий никаких подписей:

// Концептуально — escrow.sil
// Режим DISPUTED, подпись не требуется
if mode == DISPUTED && timeoutTo == 1 && age >= arbiterDeadline {
    // отправить весь баланс продавцу (= вкладчику)
    // сервисной комиссии НЕТ — только сетевая комиссия
}

Для Kaspa Deposit параметр timeoutTo установлен в 1 (seller = вкладчик). Если срок арбитра истекает без решения, средства автоматически возвращаются вкладчику без сервисной комиссии — вычитается только сетевая комиссия. Сделка никогда не застрянет навсегда, независимо от того, что произойдёт с любым сервером или сервисом.

Тот же механизм лежит в основе Kaspa Escrow, где timeoutTo по умолчанию указывает на покупателя. Принцип идентичен: жёсткий дедлайн, после которого контракт разрешается сам, без участия человека.

Как Kaspa Forge подключает эти пути к Deposit

Продукт не вводит новый контракт. Серверный модуль deposit_api.rs принимает специфичные для Deposit маршруты создания и присоединения — устанавливая вкладчика как seller, держателя как buyer и timeoutTo = 1 — после чего передаёт запись в общую жизненную цикл сделки, обслуживающую также Escrow: deals.rs (реестр), chat_api.rs (зашифрованный тред), dispute_api.rs (претензия/раскрытие/эскалация), arbiter.rs (ИИ-медиация) и watcher.rs (цикл опроса каждые 10 секунд, запускающий автоматический возврат, тайм-аут, уведомления об истечении и эскалацию после вердикта).

Предустановки окон — те же шесть вариантов, что и в Escrow: 24 / 48 / 72 / 96 / 120 / 168 часов, каждое в паре с более длительным сроком арбитра. Минимальный размер сделки — 50 KAS; верхнего предела нет. Комиссии обеспечены контрактом и отображаются перед подтверждением.

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

Какие доказательства сохранять

Ковенант решает, кто получит деньги. *Арбитр* решает на основании доказательств. Для депозитного спора важно следующее:

• Зашифрованный чат сделки — основной канал доказательств. Всё общение ведите внутри треда сделки. Ончейн-временные метки невозможно задним числом изменить.
• Фотографии или видео предмета или имущества при передаче и возврате с видимыми метками времени.
• Чеки, номера отслеживания, договоры — любые оффчейн-документы. Загружайте через вложение медиафайлов в чате сделки (до 60 МБ на файл).
• Скриншоты условий такими, какими они выглядели на момент присоединения к сделке.

Форензический модуль ИИ-медиатора проверяет целостность файлов (SHA-256 по ончейн-привязкам, magic bytes, EXIF), прогоняет изображения через модель компьютерного зрения и извлекает метаданные из видео и PDF. Но он может анализировать только то, что было представлено. Если вы не предоставите доказательств, у арбитра не будет материала для работы.

Сводка комиссий и таймингов

Параметр конструктора feeBudget (виден до пополнения) ограничивает компонент сетевой комиссии диапазоном от 0,01 до 0,1 KAS. Сервисная комиссия обязательна для всех путей, кроме тайм-аута — это обеспечивается на уровне скрипта, а не сервера.

Честные ограничения и текущие рамки

Контракт гарантирует безопасность средств, а не справедливость результата. Ковенант предотвращает кражу — арбитр не может перенаправить средства себе. Но справедлив ли вердикт, зависит от доказательств и суждения арбитра. Это неизбежный компромисс любой системы, связывающей ончейн-расчёты с оффчейн-реальностью.

Только держатель может подать претензию. Вкладчик может выполнить release, refund или дождаться автоматического возврата — но не может инициировать спор по собственному депозиту. Если вкладчик считает, что держатель злоупотребляет окном, его инструмент — отказаться от release и дать таймеру истечь.

Окно претензии фиксируется при создании. Только шесть предустановок (от 24 до 168 часов). Пользовательские значения не поддерживаются — это не даёт недобросовестной стороне установить микроокно, лишающее другую сторону реальной возможности действовать.

Минимум 50 KAS, верхнего предела нет. Ниже 50 KAS комиссия за спор съедает слишком большую долю залога.

Известные неточности (Escrow v1, рассмотрено 2026-07-25): текущий контракт проверяет обязательные начальные выходы и сохраняет основную сумму с точностью до feeBudget, но не обеспечивает точного количества выходов. Завершающий выход может поглотить ограниченную бюджетную слабину (0,01–0,1 KAS в поддерживаемой конфигурации). Официальный CLI для восстановления dealctl формирует каноническую транзакцию и проверяет её локально. Исправление на точное количество выходов потребует новой версии контракта и не будет применено тайно — оно будет опубликовано как раскрытие с отпечатками компилятора.

Внешний аудит впереди. Контракт прошёл стресс-тестирование (52/52 сценария в виртуальной машине Kaspa, а также сквозные прогоны в simnet), четыре раунда внутренней проверки безопасности, включая анализ границ доверия с воздушным зазором, и инструменты восстановления были независимо верифицированы. Однако формальный отчёт внешнего аудита ещё не опубликован. Проверяйте опубликованный исходный код перед отправкой средств.

Инвариант одного входа. Все десять путей обеспечивают require(tx.inputs.length == 1), закрывая класс атак, которые объединяют UTXO эскроу с другими входами. Подтверждено аудитом и публичным набором тестов.

Восстановление работает офлайн. Опубликованный CLI dealctl может извлекать, проверять, собирать, подписывать и отправлять каждый путь ковенанта напрямую на любой узел Kaspa v2+ — без хостинга, без аккаунта, без зависимости от сайта Kaspa Forge. Если вы храните свой ключ сделки, вы всегда можете переместить свои средства.