Кросс-чейн верификация платежей в Kaspa Escrow

В P2P OTC-сделке на Kaspa Escrow одна сторона проста: покупатель отправляет KAS в ончейн-ковенант, где правила соблюдаются кодом. Но что насчёт второго плеча? Если продавец соглашается отправить USDT в сети Tron, или BTC, или TON в обмен — как покупатель узнает, что платёж контрагента действительно был совершён?

Ещё недавно ответ был таким: проверь эксплорер сам, поверь сообщениям в чате и надейся на лучшее. Именно этот разрыв — между криптографически защищённой стороной KAS и стороной контрагента на уровне «просто поверьте мне» — и был закрыт пайплайном кросс-чейн верификации.

Проблема: один контракт, две сети

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

Но OTC-сделки устроены иначе. Обе стороны перемещают стоимость: покупатель отправляет KAS в эскроу, а продавец отправляет другую криптовалюту напрямую в её нативной сети. Контракт не видит, что происходит в Tron или Ethereum — виртуальная машина Kaspa не имеет кросс-чейн интроспекции. Поэтому сторона контрагента всегда находилась в серой зоне: объявлена в чате, проверена на глаз.

Это важно, потому что споры — тяжёлая артиллерия. Если продавец утверждает, что отправил USDT, но не сделал этого, покупателю приходится открывать спор, раскрывать ключ чата и ждать AI-анализа, а возможно, и решения арбитра-человека. Процесс работает — наша система споров и арбитража для этого и создана — но это накладные расходы для того, что может быть простым фактическим вопросом: *транзакция прошла или нет?*

Как работает верификация: пошагово

Пайплайн верификации работает как модуль внутри общего бэкенда Kaspa Forge — того же процесса, который обслуживает Kaspa Safe, Escrow, Deposit и Marketplace. Вот как это устроено:

1. Создание сделки фиксирует условия

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

Семнадцать поддерживаемых методов охватывают семь сетей:

USDC-TRC20 был намеренно исключён — Circle прекратил его поддержку. Список составлен так, чтобы покрывать сети, в которых реально проходят OTC-объёмы, а не все возможные блокчейны.

2. Продавец указывает идентификатор транзакции

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

Не каждый криптоплатёж запускает автоматическую верификацию. Если метод есть в поддерживаемой матрице выше, идентификатор транзакции передаётся в проверку в реальном времени. Если это «другая крипта» — скажем, Solana или Monero — заявка всё равно фиксируется в записи сделки, но верификация остаётся ручной (чат плюс эксплорер). Для фиатных платежей серверные поля вообще не предусмотрены — они полностью зашифрованы сквозным способом.

3. Пайплайн проверяет сеть

Модуль верификации берёт объявленный идентификатор транзакции и запрашивает соответствующий блокчейн-API. Что именно проверяется, зависит от сети:

• Для токен-трансферов (USDT, USDC): модуль подтверждает, что конкретный контракт токена сгенерировал событие перевода на объявленную сумму — или больше — на адрес покупателя. Адреса контрактов и десятичные разряды заданы как канонические константы внутри модуля, а не поставляются пользователем, что исключает подделку через фейковые токен-контракты.
• Для нативных переводов (ETH, BNB, TRX, TON, BTC, LTC): проверяется выход транзакции или квитанция на корректность получателя и суммы.
• Пороги подтверждений различаются в зависимости от сети. Как объясняет вики Kaspa, Kaspa использует DAA score в качестве глобальных часов для измерения зрелости блоков; пайплайн верификации применяет аналогичные требования к подтверждениям для каждой сети, балансируя скорость и гарантии финальности.

Доступ к API различается по сетям. EVM-цепочки (Ethereum, Polygon, Arbitrum) требуют ключ Etherscan v2 API; без него эти конкретные методы недоступны — за исключением Base, который использует эндпоинт Blockscout REST v2 без ключа, и BSC, который обращается к публичному JSON-RPC узлу. Tron, Bitcoin, Litecoin и TON используют собственные публичные или самохостируемые API и работают всегда. Аварийный переключатель позволяет отключить весь модуль, если зависимость от API становится ненадёжной.

4. Статус-бейдж отображается для обеих сторон

Результат передаётся в конечный автомат с семью состояниями:

awaiting → declared → pending_conf → verified
                                  → mismatch
                                  → failed
                                  → not_found
                  → error

• awaiting: сделка профинансирована, продавец ещё не указал идентификатор транзакции.
• declared: идентификатор введён, но ещё не проверен.
• pending_conf: транзакция найдена, ожидается достаточное количество подтверждений.
• verified: подтверждения получены, сумма и получатель соответствуют условиям сделки.
• mismatch: транзакция найдена, но сумма или получатель не совпадают.
• failed: транзакция существует в блокчейне, но была отменена или завершилась неудачно.
• not_found: транзакция с таким хешем в объявленной сети не найдена.
• error: API недоступен или вернул непредвиденный ответ.

Оба участника — покупатель и продавец — видят этот статус при опросе состояния сделки. Это сигнал в реальном времени: пайплайн повторно запрашивает данные по мере накопления подтверждений, поэтому pending_conf в конечном итоге перейдёт в verified.

Чего верификация НЕ делает

Это ключевое различие. Верификация носит исключительно консультативный характер.

Она не изменяет контракт escrow.sil. Контракт не имеет понятия о кросс-чейн состоянии. Его десять путей расходования остаются точно такими же, а инвариант единственного входа не затронут.

Она не освобождает средства автоматически. Даже если верификация показывает verified, покупатель по-прежнему должен вручную подписать транзакцию release. Контракт это обеспечивает — никакое действие сервера не может обойти это ограничение.

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

Представьте это как вторую пару автоматизированных глаз. Контракт — это судья; верификация — камера наблюдения для доказательств.

Как это встраивается в жизненный цикл сделки

На практике OTC-сделка выглядит так:

1. Создание — инициатор настраивает сделку, выбирая OTC-шаблон и объявляя условия контрагента (например, «Я отправлю 500 USDT в сети Tron на адрес T...»). 2. Присоединение — контрагент присоединяется по одноразовому коду. Адрес эскроу вычисляется из публичных ключей обеих сторон. 3. Пополнение — сторона KAS отправляет средства на адрес эскроу. Наблюдатель обнаруживает UTXO и помечает сделку как funded. 4. Платёж контрагента — продавец отправляет криптовалюту в другой сети и передаёт идентификатор транзакции через структурированное платёжное сообщение. 5. Запуск верификации — пайплайн проверяет сеть и обновляет статус. Оба участника видят бейдж в панели сделки. 6. Освобождение — если покупатель удовлетворён (будь то статус verified, ручная проверка в эксплорере или доверие), он подписывает release. KAS поступает продавцу.

Если верификация показывает mismatch, у покупателя есть веский основание не торопиться с освобождением средств. Далее в дело вступает механизм споров, а статус верификации фиксируется как часть доказательной базы.

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

Ни один дизайн не обходится без компромиссов.

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

Зависимость от API. Верификация опирается на сторонние API — Etherscan, TronGrid, Blockscout, публичные узлы. Если API ограничен по частоте запросов, недоступен или возвращает устаревшие данные, статус корректно деградирует до error или not_found. Сделка не блокируется, но сигнал отсутствует. Аварийный переключатель позволяет операторам полностью отключить функцию, если зависимость становится ненадёжной.

Фиат не затронут. Банковские переводы, наличные при встрече и другие фиатные методы не имеют ончейн-отпечатка для проверки. Они остаются полностью P2P через зашифрованный чат. Автоматическая верификация фиата потребовала бы интеграций с банковскими API, которые привнесли бы кастодиальные риски и регуляторную сложность — полную противоположность тому, для чего создан Kaspa Forge.

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

Требование ключа Etherscan. Для четырёх EVM-цепочек, использующих Etherscan v2 API, функция требует оплаченный API-ключ на уровне оператора. Без него эти конкретные методы недоступны (за исключением Base через Blockscout и BSC через публичный RPC). Это операционная зависимость, а не ограничение протокола.

Почему это важно для самостоятельного хранения

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

Пайплайн кросс-чейн верификации не решает проблему кросс-чейн отсутствия доверия. Для этого потребовались бы атомарные свопы или мосты, каждый со своей сложностью и поверхностью рисков. То, что он делает — снижает нагрузку по верификации для каждого трейдера с уровня «найди нужный эксплорер, найди нужный контракт токена, разбери квитанцию, надейся, что ничего не пропустил» до уровня «посмотри на статус-бейдж». Контракт остаётся источником истины для стороны KAS. Бейдж — это инструмент, а не замена здравому смыcлу.

Для экосистемы Kaspa это ещё один шаг к тому, чтобы P2P-торговля стала практичной без кастодианов — построенная на той же инфраструктуре ончейн-ковенантов, которая лежит в основе Kaspa Safe и остальных компонентов платформы.