Криптовалютный залоговый депозит на Kaspa: ковенант-залог на практике

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

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

Проблема: кастодиальные депозиты — это долговые расписки

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

Даже сервисы «эскроу» в экосистеме Telegram следуют той же схеме. Человек-гарант получает KAS на собственный кошелёк и вручную пересылает их. У вкладчика нет никакой криптографической гарантии, что средства не будут потрачены до окончания срока.

Ковенант: тот же скрипт, инвертированные роли

Kaspa Deposit не использует новый контракт. Он переиспользует тот же escrow.sil — тот же скомпилированный байт-код, те же десять путей расходования, тот же WASM v5 runtime — но с одним ключевым отличием: отображение ролей перевёрнуто.

В обычной сделке Kaspa Escrow:

В Kaspa Deposit:

Вкладчик финансирует ковенант — точно так же, как покупатель финансирует эскроу. Но поскольку вкладчик занимает слот seller, стандартный путь release возвращает средства ему. Путь refund отправляет средства держателю. Безключевой таймаут — аварийный путь, срабатывающий, если сам сервис исчезает — тоже возвращает средства вкладчику.

Это не хак. Контракт escrow.sil был спроектирован с десятью фиксированными путями расходования, направляющими средства на buyer, seller и feeAddr. Выбирая, какой открытый ключ отображается в какой слот, один и тот же байт-код обеспечивает противоположное поведение по умолчанию. Один контракт — два продукта.

Deposit flow (simplified):

  Depositor ──funds──▶ [covenant UTXO]
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
       release          refund         timeout
     → depositor      → holder       → depositor
     (auto after       (holder's      (service
      term+claim       claim wins)     death)
      window)

Пошагово: как работает сделка с депозитом

1. Создание. Вкладчик открывает страницу Deposit, указывает сумму (минимум 50 KAS), срок и окно претензий. Сервер (deposit_api.rs) вычисляет адрес ковенанта на основе открытого ключа вкладчика, открытого ключа держателя (введённого или приглашённого) и сервисных параметров. Генерируется ссылка-приглашение. Создание депозита бесплатно.

2. Присоединение. Держатель открывает ссылку-приглашение, проверяет условия и присоединяется. Браузер каждой стороны генерирует собственный приватный ключ — он хранится только в зашифрованном профиле Desk и никогда не передаётся. У держателя есть 72 часа на присоединение, после чего черновик истекает.

3. Финансирование. Вкладчик отправляет KAS на адрес финансирования (собственный адрес, ключ в его списке восстановления), затем нажимает «Заблокировать в депозит». Браузер собирает ончейн-транзакцию ковенанта. Обычный перевод на адрес ковенанта без этапа сборки не создаёт контракт — двухэтапный процесс существует потому, что ковенант требует специфической структуры выхода.

4. Течение срока. В период аренды средства находятся в UTXO ковенанта. Ни одна сторона не может переместить их в одностороннем порядке. Обе стороны имеют доступ к сквозному зашифрованному чату сделки (протокол Kasia — каждое сообщение является ончейн-транзакцией, поэтому разговор защищён от подделки и имеет временную метку в BlockDAG).

5. Срок истекает, открывается окно претензий. Это ключевой элемент дизайна. Срок делится на две фазы:

• Свободный срок: сам период аренды. Претензии не могут быть поданы.
• Окно претензий: установленный период после срока (выбирается при создании). Держатель должен подать претензию до закрытия этого окна.

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

6b. Держатель подаёт претензию. Если держатель считает, что у него есть основания удержать часть или весь депозит (повреждения, неоплаченная аренда, незавершённая работа), он открывает претензию до закрытия окна. Сделка переходит в состояние спора — средства замораживаются в ковенанте.

7. Разрешение спора. Процедура спора идентична Kaspa Escrow:

• Обе стороны предоставляют доказательства через чат сделки (фотографии, документы, сообщения).
• AI-медиатор восстанавливает ветку чата из раскрытого ключа, собирает доказательства и выносит несвязывающий вердикт.
• Человек-арбитр принимает окончательное решение: всё вкладчику, всё держателю или разделение N%.
• Если арбитр пропускает свой дедлайн, срабатывает автоэскалация.

8. Аварийный таймаут. Если сам сервис отключается — сервер исчезает, домен истекает — безключевой таймаут-путь в ковенанте возвращает средства вкладчику. Ни одна сторона не должна ничего подписывать. Средства не могут застрять.

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

Kaspa Deposit работает в основной сети. Поверхности продукта:

• Лендинг: /deposit-index.html — объяснение механизма и ссылка на приложение.
• Приложение: Desk → вкладка Deposits — создание, присоединение, финансирование, подача претензий и управление активными депозитами.
• Восстановление: публичный CLI dealctl (опубликован в репозитории Kaspa Forge) поддерживает сделки депозитов с теми же командами extract/verify/fund/release/refund/dispute, что и Escrow. Если сайт недоступен, dealctl на любом узле Kaspa v2+ обрабатывает всё.

Серверная граница — deposit_api.rs, который обрабатывает создание и присоединение. Далее сделка депозита проходит через тот же реестр deals.rs, тот же зашифрованный чат, тот же конвейер споров и арбитров, и тот же цикл наблюдателя, который мониторит сделки Escrow. Наблюдатель обрабатывает истечение черновика, автоматический release после окна претензий, таймаут после дедлайна арбитра и предупреждения на 50% и 90% каждого окна.

Где ковенант-залог полезен — а где нет

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

Хорошо подходит:

• Аренда квартиры: арендодатель и арендатор договариваются в письменном договоре, что депозит возвращается, если квартира проходит осмотр. Ковенант удерживает средства; окно претензий даёт арендодателю время на осмотр; процедура спора решает разногласия по поводу повреждений.
• Гарантийный взнос подрядчика: клиент блокирует депозит, который подрядчик предоставляет в залог за своевременное завершение. Если подрядчик укладывается в срок и клиент не подаёт претензию, депозит автоматически возвращается.
• Аренда оборудования: владелец удерживает залог на случай повреждений. Срок совпадает с периодом аренды; окно претензий совпадает с окном возврата и осмотра.

Что по-прежнему требует письменного соглашения:

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

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

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

Что гарантирует ковенант: средства не могут быть украдены оператором, арбитром или любой из сторон, действующей в одиночку. Десять путей расходования в escrow.sil математически ограничены — ни один путь не отправляет средства на адрес, отличный от адреса вкладчика, держателя или сервисного сбора. Это свойство скомпилированного скрипта, проверенное в виртуальной машине Kaspa (25 самотестов), а не декларативное заявление.

Что ковенант НЕ гарантирует:

• Справедливость вердикта. Вердикт AI-медиатора не является связывающим. Вердикт человека-арбитра является окончательным, но человеческим — он зависит от качества предоставленных доказательств. Всё общение ведите в чате сделки (ончейн, E2E-шифрование, защита от подделки), а не через сторонние каналы.
• Внесудебную истину. Контракт не видит физический мир. Залог KAS за квартиру, которая действительно была повреждена, всё равно потребует от держателя доказать это, а от арбитра — оценить доказательства.
• Внешний аудит. Контракт прошёл внутреннее adversarial-тестирование (52/52 проверки VM плюс запуски в тестовой сети) и четыре раунда независимого ревью комплекта восстановления. Внешний аудит безопасности ещё впереди. Проверяйте, прежде чем блокировать значительные суммы.
• Минимальную сумму. Депозиты менее 50 KAS не поддерживаются — структура комиссий (минимум 1,2 KAS при release, минимум 5 KAS при споре) делает мелкие депозиты непрактичными.
• Взаимное закрытие с комиссией. Если обе стороны соглашаются закрыть депозит по взаимному согласию (взаимная подпись), комиссия за release (0,5%, минимум 1,2 KAS) всё равно взимается — это обеспечивается самим контрактом для предотвращения обхода комиссий.

Гарантия восстановления: если сервис исчезает, безключевой таймаут возвращает средства вкладчику. Публичный CLI dealctl может выполнить это восстановление на любом узле Kaspa, полностью независимо от инфраструктуры Kaspa Forge. Это не обещание — это опубликованный, протестированный инструмент с открытым исходным кодом.