Подпись заявки разрешает торговлю на заданных условиях, но не означает, что сделка состоялась. API может принять заявку, стакан — сопоставить её часть, а расчётная транзакция всё равно может завершиться ошибкой.
Пятая статья серии «Как работают Polymarket и Kuest» рассматривает разрешение, лежащее за связанными стаканами YES и NO. Мы пройдём по отдельным слоям системы: что подписывает участник, что проверяет сервис сопоставления и что действительно записывает блокчейн.
Начните с инструкции, затем проследите активы
Сохраним условный вопрос: «Опубликует ли обсерватория A температуру города B не ниже 30,0 °C в 12:00 UTC в дату C?» Покупка YES означает получение указанного актива исхода; подпись BUY лишь разрешает его приобрести.
Мы используем стандартный бинарный рынок Conditional Tokens Framework (CTF) и условные единицы обеспечения. Примеры сумм предполагают шесть десятичных знаков, достаточные средства и разрешения, исключают газ и финансирование. Комиссии показаны отдельно там, где указаны.
Объяснения опираются на публичные стандарты подписи, публичные примеры CTF Exchange и условные движения активов. Поддерживаемые кошельки, типы заявок и комиссии конкретной платформы нужно брать из её текущей публичной документации по интеграции.
Три разрешения выполняют разные задачи
Подпись заявки разрешает определённую торговую инструкцию. Аутентификация API представляет сервису уполномоченного отправителя запроса. Подпись пакета кошелька разрешает отдельную группу вызовов кошелька, например установку разрешённой суммы списания.
Учётные данные API идентифицируют уполномоченного отправителя запросов. Они не являются приватным ключом участника и не заменяют подпись заявки. Один документированный пример продукта приведён в публичном руководстве Polymarket по кошелькам и аутентификации.
Разные объекты требуют разных проверок. У пакета кошелька собственные nonce и срок действия; они не становятся частью торговой заявки.
EIP-712 определяет хеширование и подписание структурированных сообщений. Его домен может связать инструкцию с сетью, названием приложения, версией и проверяющим контрактом, не позволяя подписи для одного домена пройти проверку в другом.
Публичный код подписи CTF Exchange V2 показывает домен EIP-712 конкретного приложения. Имя или версия домена входят в подписанный контекст, но не доказывают, что другая торговая система принимает то же сообщение. Защита от повтора зависит также от состояния реального контракта и его правил проверки.
Суммы содержат цену
В публичном определении заявки CTF Exchange V2 подписанная инструкция содержит токен, сторону, суммы maker и taker, идентификаторы аккаунтов и другие поля. Подпись разрешает именно это сообщение, а не любую цену, которую интерфейс случайно покажет позже.
Здесь maker обозначает аккаунт, предоставляющий активы, даже если его заявка немедленно забирает ликвидность. Это отличается от торговой роли мейкера: заявки, которая остаётся в стакане до исполнения против другой заявки.
Для BUY поле makerAmount означает предлагаемое обеспечение, takerAmount — требуемые доли. Предложение 60 за 100 YES задаёт лимит 60 ÷ 100 = 0,60. Для SELL, предлагающего 100 YES за 60, цена равна takerAmount ÷ makerAmount.
Отдельного подписанного поля цены, способного переопределить отношение, нет. Изменение цены на экране без пересоздания и подписи соответствующих сумм не меняет разрешённые условия.
Временная метка может описывать создание заявки, не будучи принудительно исполняемым сроком истечения. Интеграция должна отличать подписанные поля от инструкций сервису и проверять их смысл в текущей публичной спецификации.
Проверки определяют, может ли заявка войти в стакан
Перед подачей проверьте актив, ценовой лимит, размер, аккаунт и поддерживаемый тип заявки. Проверки клиента и подтверждение API не заменяют успешные расчёты контракта.
Шаг цены — допустимое изменение между котировками. Перед подписью проверьте текущие опубликованные параметры рынка. Клиентская проверка, ответ сервиса и правило контракта устанавливают разное: показанный минимум сам по себе не доказывает ограничение в блокчейне.
Средства и разрешения проверяются отдельно: BUY требует доступного обеспечения и достаточного разрешения на списание для расчётного контракта; SELL — токенов исхода и разрешения их передавать. Подпись не предоставляет ни того ни другого, а проверка баланса при приёме не замораживает все дальнейшие изменения аккаунта.
Post-only означает намерение добавить заявку в стакан, а не немедленно забрать ликвидность. Проверьте документированные сочетания и условия отказа площадки: одного названия недостаточно для определения всех реализаций.
Срок действия указывает сервису сопоставления, что делать с неисполненным количеством:
- GTC — до отмены: оставить допустимый остаток в стакане.
- GTD — до заданного времени: позволить заявке оставаться до указанного истечения.
- FAK — исполнить доступное и отменить остаток: немедленно исполнить доступное количество и удалить остальное.
- FOK — исполнить всё или ничего: требовать исполнимости всего запрошенного количества либо не исполнять ничего.
Истекающая заявка сервиса и подписанный срок контракта — разные обязательства. Проверьте, где текущая спецификация обеспечивает истечение и что происходит с уже отправленными транзакциями. Наличие поля в запросе само по себе не устанавливает гарантию контракта.
Сопоставлению всё ещё нужны успешные расчёты
Рассмотрим учебные этапы: подписана → принята и размещена → сопоставлена → отправлена → подтверждена. Заявку могут отклонить до приёма; одна принятая заявка может породить несколько частичных совпадений и расчётных транзакций. Эти названия объясняют обязанности, а не задают универсальное перечисление API.
Частичное сопоставление оставляет количество для следующих исполнений, если срок действия допускает это. При неудачных расчётах нужна сверка перед повторной попыткой.
Публичный контракт CTF Exchange V2 показывает уполномоченное сопоставление и проверки перед движением активов. Примеры прямой сделки, выпуска и объединения в статье 4 объясняют возможные движения и необходимое финансирование.
Транзакция атомарна: если необходимый перевод или проверка вызывает откат, изменения её состояния отменяются. Это не отменяет другую уже успешную транзакцию, а неудачная транзакция всё равно может израсходовать газ.
Хеш обозначает отправленную транзакцию, а не успешную покупку. Проверьте её квитанцию и требуемый выбранной сетью уровень подтверждения. Пока результат неизвестен, интерфейс должен сохранять неопределённость, а не сообщать о полученных активах.
В интерфейсе оператора храните отдельно идентификатор заявки, сопоставленное количество и ссылку на транзакцию. При ошибке или неизвестном результате сверяйте фактический исход перед повтором: изменение локального статуса не перемещает активы.
Частичное исполнение расходует предложенный актив
Пусть размещённая BUY предлагает 60 обеспечения за 100 YES, а первое исполнение получает 40 YES ровно по 0,60. Без комиссий оно расходует 24 обеспечения, оставляя 36 обеспечения подписанного объёма, то есть 60 YES по той же цене.
Размещённая SELL с предложением 100 YES за 60 обеспечения расходует в том исполнении 40 YES и получает 24 обеспечения. Её остаток maker составляет 60 долей, а не 36 обеспечения. Обеим заявкам осталось торговать 60 YES, но счётчики остатка в блокчейне используют разные активы.
Одинаковое исполнение 40 долей, разные единицы счётчика. Сделка точно по лимиту, без комиссий.
Публичная арифметика CTF Exchange V2 работает в целых базовых единицах. В используемой ниже модели пропорционального деления с округлением вниз получаемая сумма равна предоставляемой сумме × подписанная сумма taker ÷ подписанная сумма maker, с округлением вниз. Для точной сверки нужны правила реального маршрута.
Например, продажа 1,000001 доли из подписанной заявки на 3 доли за 1,8 обеспечения вычисляет 1 000 001 × 1 800 000 ÷ 3 000 000, округляя вниз до 600 000 базовых единиц обеспечения. Поэтому малые исполнения и комиссии требуют правил округления реализации; умножения округлённых экранных цен недостаточно для точной сверки.
Комиссиям нужен отдельный учёт
Предположим прямую покупку 100 YES за 60 обеспечения и условную комиссию 0,60 с каждого участника. Покупателю нужно 60,60 обеспечения, продавец получает 59,40. Оставшиеся 1,20 — все комиссии, так что деньги покупателя полностью учтены.
Условные комиссии, не текущий тариф. Расход покупателя 60,60 = поступление продавца 59,40 + комиссии 1,20; существующие 100 YES переходят покупателю.
В этом конкретном примере комиссия BUY добавляется к нужным средствам покупателя, комиссия SELL вычитается из выручки. Реальные сборы, получателей и округление нужно проверить для выбранной площадки и маршрута; пример не является тарифом.
У отмены есть граница
Удаление открытой заявки относится к оставшемуся неисполненному количеству. Оно не обращает завершённые исполнения. Учитывайте подтверждение отмены и незавершённую расчётную транзакцию отдельно, проверяя оба перед повторным использованием денег.
Если расчёты уже отправлены, последующая отмена в стакане не обещает их остановить. Проверьте результат транзакции, прежде чем считать активы доступными, особенно при частично исполненной исходной заявке.
Отмена остатка и расчёты по предыдущему совпадению могут произойти одновременно. Ни одна отложенная защита не обращает успешную транзакцию.
Более широкое ограничение аккаунта — не отмена одной заявки. У средств восстановления разные области действия, задержки и полномочия. Используйте опубликованные контракты и документацию реального аккаунта, не предполагая, что любой контроль действует мгновенно.
У Deposit Wallet есть отдельный период паузы и экстренного ожидания перед экстренным выводом или отзывом разрешений. Одна пауза кошелька не отключает пакетное исполнение или проверку подписи в этом коде: это не мгновенный выключатель торговли.
Имена версий не определяют интеграцию
Старая заявка CTF в Polymarket подписывала taker, expiration, nonce и feeRateBps. Отдельная заявка CTF Exchange V2 убирает эти поля и добавляет timestamp, metadata и builder; цена остаётся отношением сумм.
Репозиторий V2 также удаляет fillOrder/fillOrders, сохраняя сопоставление оператором через matchOrders. Этот CTF Exchange V2 отличается от архитектуры позиций Protocol V2 в polymarket-v2-external. Kuest не наследует обновления обоих репозиториев автоматически.
Отсутствие срока истечения в структуре контракта не означает отсутствия истекающих заявок в продукте. Текущая документация Polymarket по жизненному циклу описывает GTD на уровне продукта, а руководство по позициям отличает реестры CTF и Protocol V2. Перед интеграцией проверьте реальный маршрут рынка.
Что должен раскрывать оператор Kuest
Публичное руководство Kuest для операторов отделяет приложение оператора от общих сервисов. Раскрывайте участникам поддерживаемый путь аккаунта, полную оценку комиссии и отдельные состояния принятия, сопоставления и подтверждения. Это наблюдаемые требования продукта, а не детали внутренней реализации.
Публичная документация Kuest по комиссиям описывает участие оператора в торговых комиссиях и настраиваемую долю партнёров. Распределение комиссии отличается от дополнительного сбора с номинала сделки. Объясняя платежи участника, опирайтесь на текущие публичные настройки и расчётные записи.
Для брендированного оператора это конкретное решение интеграции: сохранять правильную идентичность builder, показывать реальную общую комиссию и сверять её распределение с расчётами. Код идентификатора или брендированный интерфейс сами по себе не гарантируют приём заявки, право на комиссию или доход.
Запустите собственный рынок прогнозов с Kuest с понятной участникам политикой исполнения: юрисдикции аудитории, точные правила и маршрут определения исхода, нужные размеры сделок, поддерживаемый путь кошелька, раскрытие комиссий и отдельные состояния принятия, сопоставления и подтверждения.