Как покупать и продавать за KAS на Kaspa Marketplace

Чтобы покупать и продавать за KAS на Kaspa Marketplace, вам не нужно отправлять деньги платформе. Вы просматриваете активные листинги, начинаете зашифрованный чат с продавцом и нажимаете «Купить». За кулисами Marketplace создаёт реальную сделку эскроу в блокчейне Kaspa, используя тот же ковенант escrow.sil, который лежит в основе всех транзакций Kaspa Escrow. Вы пополняете адрес ковенанта напрямую из своего кошелька. Продавец видит пополненный эскроу, доставляет товар или услугу, и вы освобождаете средства — или открываете спор, если что-то пошло не так. Сам маркетплейс никогда не касается ваших KAS.

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

Проблема: P2P-коммерция без необходимости доверять

Традиционные одноранговые маркетплейсы сталкиваются с фундаментальным противоречием. Либо вы доверяете централизованной платформе хранить средства (и надеетесь, что её не взломают, она не злоупотребит полномочиями или не исчезнет), либо полагаетесь на «джентльменские соглашения», которые не дают никаких гарантий, если одна из сторон окажется недобросовестной.

Kaspa Marketplace решает эту проблему, превращая каждый листинг в тонкую обёртку вокруг ончейн-контракта эскроу. Контракт представляет собой ковенант Kaspa — скрипт, встроенный в UTXO, который обеспечивает правила освобождения средств, возврата и спора без какого-либо ключа платформы. Маркетплейс предоставляет *уровень обнаружения* (листинги, поиск, фотографии, чат), а *уровень платежей* — это чистая блокчейн-логика.

Как работает покупка и продажа, шаг за шагом

1. Просмотр или создание листинга

Витрина Marketplace показывает все опубликованные листинги. Вы можете фильтровать по категории (goods, digital, services), диапазону цен (в sompi — 1 KAS = 100 000 000 sompi) и выполнять полнотекстовый поиск на базе SQLite FTS5 с ранжированием BM25. Поиск работает как с латинскими, так и с кириллическими приставками слов.

Если вы продавец, вы создаёте листинг через интерфейс Desk. Форма запрашивает:

• Категорию (goods, digital или services — OTC/крипто намеренно исключены с июля 2026 года)
• Цену (минимум 50 KAS, верхнего предела нет, кроме ограничений точности sompi)
• Описание и до 3 фотографий
• Окно спора (24/48/72 часа из заранее определённого списка)
• Тип (разовый или повторяемый — повторяемые листинги остаются активными после успешной продажи)

Фотографии обрабатываются на стороне сервера: метаданные EXIF удаляются (включая GPS), изображения перекодируются в JPEG (макс. 2400 px по длинной стороне) и хранятся с адресацией по хешу SHA-256. Это предотвращает утечки метаданных и полиглотные нагрузки.

2. Очередь ИИ-модерации

После отправки листинг попадает в устойчивую фоновую очередь модерации. Система использует OpenAI-совместимый эндпоинт (модель по умолчанию: mimo-v2.5-pro) с системным промптом, определяющим категории отклонения: спам, запрещённые товары, фишинг, вредоносное ПО, пиратский контент. Для листингов с фотографиями анализ изображений выполняет модель компьютерного зрения.

Решение может быть одним из:

• approved → листинг получает статус published, становится видимым на витрине
• rejected → листинг остаётся скрытым (автоматически удаляется через 24 часа, если не прошёл ручную проверку)
• needs_review → уведомляет модератора-человека через Telegram

Если вызов ИИ не удаётся (тайм-аут, ошибка транспорта), система повторяет попытку с экспоненциальной задержкой (по умолчанию: 3 попытки, задержки 15 с/30 с). После исчерпания попыток листинг остаётся неопубликованным и передаётся на ручную проверку. Система никогда не публикует листинг, не прошедший модерацию.

3. Чат перед покупкой

Перед покупкой потенциальный покупатель может начать зашифрованный чат с продавцом прямо со страницы листинга. Для этого используется тот же протокол Kasia E2E, что и для чатов сделок: сервер передаёт только шифротекст, а сообщения привязаны к ончейн-идентификаторам транзакций для обеспечения целостности.

Ключевые отличия от чатов сделок:

• Ключи чата формируются из listing_id × hash(buyer_token), а не из идентификатора сделки
• Это значит, что вопрос не «расходует» ваш одноразовый код присоединения к эскроу
• Каждая сторона оплачивает свои сообщения из кошелька Desk (без финансирования из крана)
• Лимиты: 500 сообщений в ветке, 50 веток на листинг, 10 новых веток в час

4. Оформление: создание сделки эскроу

Когда вы готовы к покупке, нажатие «Купить через эскроу» вызывает POST /api/safe/listings/:id/checkout со случайным request_id. Сервер:

1. Создаёт новую сделку эскроу через Deals::create_deal — тот же контракт, что используется в автономном Escrow 2. Привязывает её к листингу в таблице listing_orders (идемпотентно: один и тот же request_id возвращает один и тот же код присоединения) 3. Возвращает 12-символьный join_code

Код присоединения позволяет перейти в панель сделки по адресу /deal.html?join=<code>. Там вы видите адрес эскроу, окно спора и можете пополнить его из своего кошелька.

Для цифровых товаров настройки по умолчанию: repeatable=true с 48-часовым окном спора.

5. Пополнение эскроу

Вы отправляете KAS на адрес ковенанта, отображаемый в панели сделки. Минимум — 50 KAS (соответствует MIN_DEAL_SOMPI). Верхнего предела нет — только ограничения точности от номинала sompi.

Как только вотчер обнаруживает транзакцию пополнения (10-секундный цикл опроса), сделка переходит в статус funded. В этот момент:

• Для товаров: статус листинга меняется на reserved (разовый) или остаётся published (повторяемый), а вотчер создаёт новый код присоединения для следующего покупателя
• Для цифровых товаров: листинг остаётся published, если он повторяемый
• Запускается таймер на 1 час: если покупатель присоединился, но не пополнил эскроу в течение 60 минут, сделка истекает, и листинг публикуется заново

Функция watcher::run_escrow обрабатывает всю эту логику жизненного цикла в едином 10-секундном цикле, обслуживая как сделки эскроу, так и листинги маркетплейса.

6. Доставка и освобождение средств

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

Когда покупатель удовлетворён, он подписывает транзакцию освобождения средств. Средства переходят из ковенанта на адрес продавца за вычетом комиссий эскроу (мин. 0,5% или 1,2 KAS). Сделка закрывается, а для разовых листингов маркетплейс помечает листинг как closed и удаляет фотографии.

7. Споры: страховочная сеть

Если что-то пошло не так, любая из сторон может открыть спор в установленный срок. Процесс:

1. Заявление: покупатель или продавец излагает свою позицию (возврат/освобождение/раздел) 2. Раскрытие: обе стороны должны раскрыть свой закрытый ключ чата (не ключ эскроу — это разные ключи). Это позволяет системе расшифровать переписку для рассмотрения доказательств 3. ИИ-медиация: арбитражный ИИ (mimo-v2.5-pro, temp 0) анализирует расшифрованную переписку, прикреплённые медиафайлы (фотографии проверяются по ончейн-якорям SHA-256, видео обрабатывается покадрово) и выносит необязательное решение 4. Окно принятия: у сторон есть 24 часа на принятие решения 5. Эскалация: если решение отклонено, человеческий арбитр может вмешаться через панель администратора

Путь спора использует тот же конечный автомат ковенанта escrow.sil: ACTIVE → DISPUTED → арбитр разрешает.

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

Ни одна система не совершенна. Вот что стоит знать о текущем состоянии:

ИИ-модерация — это фильтр, а не гарантия. Она улавливает очевидные нарушения правил, но может пропустить новые схемы мошенничества. Путь needs_review существует для спорных случаев, но объём модерации может вызывать задержки. Продавцам стоит быть готовыми к времени ожидания.

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

Фотографии ограничены 3 на листинг, макс. 8 МБ каждая, общий лимит хранилища — 25 ГБ. Адресация по содержимому означает, что идентичные изображения в разных листингах разделяют хранилище, но очистка «сирот» запускается каждые 30 минут.

Доставка цифровых товаров — ручная. Системы автоматической доставки лицензионных ключей нет. Продавцы должны доставлять через чат сделки, и платформа не проверяет, соответствует ли доставленное описанию — это вопрос между покупателем и продавцом (и системой споров, если что-то пошло не так).

Окно спора заранее задано (24/48/72 часа) — вы не можете выбрать произвольную продолжительность. Для цифровых товаров по умолчанию — 48 часов.

OTC/крипто-торговля намеренно исключена из маркетплейса с июля 2026 года. Маркетплейс предназначен для товаров и услуг, оплачиваемых в KAS, а не для обмена KAS на другие криптовалюты. Этим занимается автономный сервис Escrow.

Комиссии неизбежны. Комиссия за разрешение эскроу — от max(0,5%, 1,2 KAS); комиссия за спор — от max(2%, 5 KAS). Они поступают на тот же адрес комиссий, что и все транзакции эскроу.

Управление ключами — на вас. Ваш профиль Desk шифрует ключи локально. Если вы потеряете доступ и не сделали резервную копию файла ключей .age, средства в эскроу могут быть безвозвратно потеряны (хотя для этого сценария существует публичный CLI dealctl).

Сам контракт эскроу имеет известное ограничение: пути проверяют первые выходы и сохраняют основную сумму в пределах точности feeBudget, но не обеспечивают точное количество выходов. Это задокументировано в публичных errata и будет исправлено в будущей версии ковенанта — а не тихо пропатчено в текущем рабочем контракте.

Как Kaspa Forge связывает всё воедино

Под капотом Marketplace — это модуль, наложенный поверх бэкенда эскроу (kaspa-safe-server). Модуль listings.rs (~112 КБ, самый большой на сервере) обрабатывает CRUD, модерацию и SSR. Он разделяет базу данных SQLite с эскроу, с таблицами listings, listing_orders (идемпотентное отслеживание оформлений), listing_photo_uploads/refs (промежуточное и постоянное хранение фотографий), listing_chats/listing_chat_msgs (зашифрованные ветки перед покупкой) и listings_fts (индекс полнотекстового поиска).

HTTP API располагается по пути /api/safe/ с маршрутами, объединёнными из listings::routes() и listing_chat::routes(). Ключевые эндпоинты:

POST   /api/safe/listings          # create listing (pending moderation)
GET    /api/safe/listings          # browse (category, q, sort, price range, limit≤100)
POST   /api/safe/listings/:id/checkout  # create escrow deal for this listing
POST   /api/safe/listings/chat/start    # begin pre-purchase encrypted thread

Жизненный цикл листинга управляется той же функцией watcher::run_escrow, которая обрабатывает все сделки эскроу. Когда покупатель пополняет эскроу, вотчер:

• Резервирует разовые листинги (статус → reserved)
• Публикует повторяемые листинги заново с новой сделкой и кодом присоединения
• Закрывает листинги после завершения сделки (для разовых товаров фотографии удаляются)

Хранение фотографий использует адресацию по содержимому: photo_id = sha256(normalized_jpeg). Загрузки ограничены по частоте (30 за 10 минут, 10 созданий в час). Сервер перекодирует каждую загрузку для удаления метаданных, предотвращая утечки EXIF.

Модерация работает как устойчивый фоновый процесс с экспоненциальной задержкой. Неудачные вызовы ИИ не блокируют листинг — они молча повторяются и передаются людям после исчерпания попыток. Панель администратора (market-admin.html и Telegram Mini App) разделяет аутентификацию с панелью арбитра эскроу через тот же гейт admin_ok.

В контексте Kaspa: Marketplace использует быстрое создание блоков для оперативного подтверждения пополнения эскроу, а модель UTXO гарантирует, что каждый эскроу является дискретным, проверяемым ончейн-объектом. Протокол GHOSTDAG обеспечивает консенсусную основу — ваша транзакция эскроу упорядочивается и подтверждается внутри структуры DAG, а показатель DAA контролирует тайминг корректировок сложности.

Практические советы для покупателей и продавцов

Для покупателей:

• Используйте чат перед покупкой для уточнения деталей до принятия решения
• Проверьте, есть ли у продавца значок репутации (добровольный, но полезный при наличии)
• Для цифровых товаров проверьте доставленное в чате сделки перед освобождением средств
• Открывайте спор в установленный срок, если что-то не так — после его истечения остаётся только путь через арбитра

Для продавцов:

• Пишите понятные описания — ИИ-модератор читает их и ваши фотографии
• Для цифровых товаров доставляйте своевременно после пополнения, чтобы избежать споров
• Рассмотрите включение значка репутации, если планируете несколько продаж — он помогает покупателям вам доверять
• Используйте флаг repeatable для товаров, которые можно продавать многократно (ПО, услуги)

Для обеих сторон:

• Делайте резервную копию профиля Desk (файл ключей .age)
• Помните, что ковенант эскроу — это источник истины, а не платформа
• Помните: Marketplace — это уровень обнаружения, а не кастодиан. Ваши KAS живут ончейн.

Полная документация Kaspa Escrow подробно описывает механику ковенанта, процесс споров и варианты восстановления. Код контракта с открытым исходным кодом и инструменты восстановления доступны в репозитории Kaspa Forge.