«Достигнет ли температура 30 градусов?» допускает несколько разных сделок. Округлённый прогноз приложения, измерение станции и официальный отчёт, вышедший позже, могут расходиться. До покупки YES или NO рынок должен объяснить, что именно определяет выплату.
Шестая статья серии «Как работают Polymarket и Kuest» превращает вопрос в проверяемое правило и прослеживает доказательства через отдельные слои системы. Читаемая страница, зафиксированные байты вопроса и доступный документ метаданных доказывают разное.
Переписывайте вопрос, пока два читателя не получат один ответ
Сохраним вымышленные обсерваторию A, город B и дату C. «В 12:00» должно означать время наблюдения или срок публикации: это разные события. Уточните заголовок: «Будет ли температура, измеренная обсерваторией A в городе B в 12:00 UTC в дату C, не ниже 30,0 °C?» Затем укажите доказательства:
Используйте официальный CSV ежедневных наблюдений обсерватории A, станцию B-01, за дату C. Читайте поле температуры воздуха в градусах Цельсия для записи с временной меткой 12:00:00 UTC. Используйте последнюю официальную редакцию, доступную к 13:00:00 UTC в дату C, включая опубликованную ровно в этот момент. Сравнивайте опубликованное число непосредственно с 30,0 без повторного округления. Допустимое значение 30,0 или выше означает YES, ниже — NO. Игнорируйте прогнозы, другие станции и более поздние исправления. Если к сроку запись отозвана, у конфликтующих записей нет авторитетного порядка исправлений или допустимой записи нет, используйте предусмотренный исход недоступности данных.
В реальном рынке замените каждое вымышленное название и дату точным URL источника, идентификатором станции, календарной датой и определением поля. Одно «официальный сайт» оставляет читателю выбор между страницами, зеркалами и редакциями. Резервному источнику тоже нужен приоритет, иначе он добавляет ещё один выбор после того, как результат известен.
Здесь 29,96 означает NO, даже если приложение показывает 30,0. Исправление с 29,9 на 30,1 до срока означает YES; то же исправление после него не меняет выбранное наблюдение. Равенство явно означает YES, поэтому на пороге нет неразрешённой ничьей.
Время наблюдения выбирает запись, срок — её редакцию, политика выплат обрабатывает отсутствие доказательств.
Исход недоступности данных должен соответствовать выбранному контрактному маршруту. В учебном примере предполагаем стандартный бинарный адаптер с UNKNOWN: при YES токен YES платит единицу обеспечения, NO — ноль; при NO наоборот, при UNKNOWN каждый платит половину. Это явное допущение модели, а не универсальное правило отмены или политика выплат NegRisk.
Половина единицы на токен — не возврат цены покупки. Участник, заплативший 0,80 за YES, при таком условном результате получает 0,50. Механика разделения и погашения определяет платёж, а правила — какой поддерживаемый результат следует сообщить.
Срок источника, остановка торговли и время определения результата решают разные задачи. Первый выбирает доказательства, второй управляет приёмом заявок, третье записывает исход. Например, приём может завершиться в 11:55 UTC, а допустимые исправления — в 13:00; определение результата происходит позже. Торговлю оператор настраивает отдельно, и задержка транзакции не продлевает срок доказательств.
Проследите два вида доказательств
Рынку нужны и определённый вопрос для установления исхода, и читаемая сопроводительная информация. Ancillary data — дополнительные байты вопроса, используемые конкретной интеграцией оракула. Описательные метаданные могут включать изображения, подписи и ссылки. Их задачи различны, поэтому нельзя считать их взаимозаменяемыми обязательствами.
Публичный адаптер Polymarket CTF — пример записи данных вопроса в заданной кодировке. Пересчёт зафиксированного значения требует именно этой кодировки, а не визуально похожего абзаца. Проверьте опубликованный интерфейс выбранного развёртывания вместо обобщения примера на все семейства адаптеров.
Зафиксированный вопрос и внешний документ поддерживают разные проверки. Одна ссылка не доказывает целостность или доступность.
Публичный верифицированный контракт Conditional Tokens Kuest записывает создателя и ссылку на внешние метаданные. Ссылка указывает местоположение информации, но не доказывает доступность, неизменность документа или его совпадение с исходными данными определения результата. Получите документы и сравните с записанными доказательствами вопроса.
Публичная документация Kuest по созданию рынков описывает поддерживаемый интерфейс продукта. Загруженный документ, подготовленное условие и доступный для торговли рынок — отдельные наблюдения. Подтвердите соответствующие записи вместо вывода обо всех трёх из одного успешного экрана.
У похожих идентификаторов разные задачи
Slug находит страницу. Идентификатор вопроса обозначает вопрос по схеме адаптера. Идентификатор условия объединяет оракул, идентификатор вопроса и число исходов в публичной конструкции CTF. Точные входные данные важны: похожий текст не доказывает идентичность условий.
Идентификатор позиции обозначает актив, которым владеют и торгуют. В CTF он зависит также от обеспечения и коллекции, представляющей набор исходов. Одинаковые заголовки или slug не устанавливают одинаковые активы. Адрес создателя фиксирует авторство и некоторые разрешения, внешний идентификатор метаданных — местоположение описания. Ни один не заменяет идентификатор условия или позиции.
Даже «идентификатор вопроса» не имеет универсальной кодировки. В конкретной NegRiskIdLib Polymarket первые 31 байт вопроса совпадают с идентификатором рынка, последний байт содержит индекс вопроса. Применяйте это правило только к данному семейству адаптеров, а не ко всем вопросам оракулов.
Поле metadata в подписанной торговой заявке — другой объект. Например, публичное определение CTF Exchange V2 содержит bytes32 metadata на уровне заявки. Наличие поля не доказывает, что подпись фиксирует показанный документ рынка.
Отслеживаемое обновление остаётся обновлением
Расширение Conditional Tokens Kuest записывает создателя условия и текущую внешнюю ссылку на метаданные. Создатель или администратор CTF может её заменить. Каждый успешный вызов увеличивает счётчик и публикует идентификатор условия, старую и новую ссылки и адрес обновившего.
Исследованная функция не замораживает изменения при определении исхода и не проверяет, что новая строка ведёт к доступному непустому содержимому. Поэтому неизменный идентификатор условия не означает неизменность текущего описания. Обновление может добавить источник или исправить изображение: сравните документы, прежде чем решать, изменилось ли утверждение.
Обновление ссылки может дополнить документ или изменить описание. Событие показывает, кто изменил указатель; сравнивайте содержимое.
Смена указателя не переписывает исходные байты вопроса и не даёт нового права сообщать выплаты. Функция отчёта CTF выводит условие с адресом вызывающего как оракула. Адаптер и его настроенный маршрут определяют, как результат доходит до функции. Редактирование метаданных — отдельное полномочие.
Пусть версия A говорит 30,0 °C, версия B — 31,0 °C. Событие истории делает замену видимой, но не доказывает, что 31,0 стало законным порогом. Перед толкованием изменения сравните обе версии с исходными ancillary bytes и применимой политикой уточнений.
Уточнениям нужны автор и политика
Polymarket уже фиксирует вопросы в блокчейне. Закреплённая версия адаптера UMA CTF хеширует и хранит расширенные ancillary data, а доска объявлений записывает обновления с авторством. Это конкретные механизмы CTF-адаптера, а не утверждение об ABI каждого текущего маршрута Polymarket.
Уточнению также нужны известный автор и применимая политика. В публичном примере Polymarket сообщение с авторством не переписывает исходные ancillary data. Нельзя считать любое высказывание, упоминающее вопрос, официальной поправкой.
Текущая документация Polymarket по определению исхода говорит, что контекст уточнений должен сохранять основное намерение. Указание переименованного столбца CSV может уточнить доказательства; замена порога 30,0 на 31,0 меняет утверждение. Временная метка доказывает, когда сообщение записали, но не наличие законных полномочий.
Проверьте путь от ссылки до экрана
Практическая проверка последовательно прослеживает доказательства:
- Установите развёртывание. Запишите сеть, адреса контрактов, семейство адаптера и ссылку на блок. Получите квитанцию создания, исходные байты вопроса, идентичность оракула, создателя и идентификатор условия.
- Пересчитайте нужные идентификаторы. Используйте кодировку этой реализации, обработку инициализации и число исходов. Проверьте позиции по фактическому обеспечению и сопоставлению исходов.
- Проследите историю метаданных. Прочитайте ссылку при подготовке, текущую ссылку, счётчик и события обновления. Получите первоначальный и заменяющий документы, сравните изменения и адреса авторов.
- Раздельно проверьте целостность и доступность. Проверяйте содержимое по реальной схеме транзакций или фиксации системы хранения. Сохраняйте точные полученные байты и происхождение: записанная ссылка не отдаст документ, который никто не может получить.
- Сравните то, что видят участники. Сверьте источник, даты, правила и названия исходов на экране с исходными данными и уполномоченным контекстом. Читаемый интерфейс не является независимой проверкой целостности.
Доступность документа, достоверное происхождение и совпадение отображения — разные проверки. Ни одна сама не устанавливает правильное определение исхода.
Для брендированного оператора конкретное дополнение Kuest — ссылки метаданных с привязкой к создателю и видимая история обновлений рядом с исходными данными определения результата. Это помогает проверять каталог и устанавливать авторство публикаций. Но не помещает всю информацию в блокчейн, не гарантирует доступность документа и не разрешает спор о смысле.
Запустите собственный рынок прогнозов с Kuest, подготовив аудиторию и юрисдикции, проверенный лист правил, политику источников и исправлений, поддерживаемый маршрут определения результата и план хранения доступных доказательств. До приёма сделок испытайте эти данные на неоднозначных примерах.