Миллионы контрактов Kalshi: сколько в них разных ставок

Число контрактов легко принять за число идей. У площадки семь миллионов тикеров - значит, кажется, семь миллионов независимых мнений, поводов для торговли и ценовых сигналов. Для комбинаторного рынка это плохая арифметика. Один и тот же набор базовых событий можно переставлять, объединять в точные наборы legs и материализовать в новые объекты по запросу. Каталог растет быстрее, чем экономическая новизна.

Свежая работа On-Demand Combinatorial Event Markets on Kalshi аккуратно разделяет эти уровни. За зарегистрированные семь суток исследователи нашли 7,611,594 уникальных REST MVE-тикера. Звучит как гигантская вселенная. Но под ней лежат три collection keys, 83,701 нормализованный primitive и concentration-weighted effective primitive count около 720.2. Самая крупная коллекция породила 94.82% объектов.

Это не разоблачение комбинаторных рынков и не оценка их ликвидности. Это урок измерения: тикер, событие, примитив, активный объект и независимая экономическая ставка - разные единицы наблюдения. Смешать их означает сначала увидеть миллионы, а затем случайно сделать из них миллионы степеней свободы.

Комбинаторная конструкция: объект возникает по запросу

MVE, или multivariate-event market, не просто заранее составленный список карточек. В описанном интерфейсе есть коллекции допустимых событий и endpoint, который создает отдельный рынок из выбранных legs; прежде чем объект можно будет торговать или запрашивать, этот endpoint должен быть вызван. Поэтому наблюдаемая популяция - не равна полной математической мощности всех возможных сочетаний и не равна решению биржи заранее залистить каждый тикер. Это реализованная on-demand инстанциация.

Формально для рынка $m$ авторы хранят raw structure: collection key плюс tuple выбранных legs. Затем строят нормализованную сигнатуру только из точных возвращенных полей. Важная дисциплина: сходство display titles не объявляет два объекта одинаковыми. Иначе исследователь незаметно заменит проверяемую структуру собственным семантическим угадыванием.

За интервал от 2026-08-15 19:51:29.025 UTC до 2026-08-22 19:51:29.025 UTC 190 независимо проверенных temporal shards дали 7,617,371 raw references. После half-open фильтрации остались 7,611,594 уникальных тикера; 5,777 наблюдений на границе были исключены, а не присоединены "для полноты". Средняя скорость - 1,087,371 объекта в день, или 12.59 в секунду.

Слово "объекта" здесь несет всю нагрузку. Темп не говорит, что каждые 0.08 секунды рождалась новая независимая неопределенность в мире. Он описывает output интерфейса при конкретной архитектуре и конкретной реализации запросов. Исследователи специально не вызывали creation endpoint во время сбора: иначе измеритель сам создавал бы рынки и подменял наблюдаемую популярность собственной активностью.

Даже почасовой ряд не похож на стабильный поток. Минимум - 4,640 объектов за час, медиана - 27,404, среднее - 45,039, максимум - 237,403 в час, начавшийся 22 августа в 17:00 UTC. Бурст может отражать поведение пользователей, автоматизацию, архитектурный процесс или их смесь. Из одного счетчика нельзя вывести причинный рассказ.

Примитивы и иерархия: много комбинаций, мало исходного алфавита

Чтобы понять сжатие, полезно пройти вниз по иерархии. Сначала market object - отдельный MVE-тикер. За ним exact event key: в выборке их 5,262,526, то есть в среднем 1.45 объекта на ключ. Затем collection key - их всего три. И наконец selected-leg primitive, то есть канонический идентификатор базового выбранного leg: их 83,701.

У одного market object в среднем 8.72 primitive occurrences. Всего таких incidence - 66,344,938. Это не 66 миллионов независимых фактов: один и тот же примитив снова и снова участвует в разных сочетаниях. По степени reuse медианный primitive появляется 19 раз, 90-й перцентиль - 780 раз, 99-й - 14,754 раза, а максимум - 1,055,068 раз.

Вот почему уникальная точная сигнатура не доказывает независимость. У всех 7,611,594 объектов нашлись разные exact signatures, без collision groups. Технически это хороший результат проверки идентичности. Экономически он означает лишь, что набор collection + selected-leg tuple не продублировался по точной формуле. Если исходный vocabulary из примитивов сильно повторяется, разные tuple все равно могут выражать почти одну и ту же ставку на общий фактор, матч, категорию или исходный шок.

Похожая ошибка возникает при оценке альфа-исследований. Десять тысяч формул не означают десять тысяч независимых гипотез, если все они построены из пары одних и тех же price transforms. В MVE-рынках объектный счетчик так же удобен для интерфейса и так же опасен для вывода о breadth.

Концентрация: каталог широкий, производственный слой узкий

Первое сжатие видно уже на уровне collections. Из трех наблюдавшихся ключей крупнейший отвечает за 7,217,085 market objects, или 94.82% популяции. Авторы переводят такую концентрацию в effective collection count: он равен 1.11. Не "одна коллекция буквально", а эквивалентное число равновесных источников при наблюдаемом распределении долей.

Второе сжатие - primitive reuse. HHI по степеням примитивов составляет 0.001388. Обратная величина дает effective primitive count примерно 720.2, хотя сырых уникальных primitive 83,701. Это полезнее для вопроса "сколько реально разных базовых компонентов несет вес в конструкции?", чем просто size словаря.

Ни одно из этих чисел не отвечает в одиночку на вопрос о риске. HHI чувствителен к весам, top-k share показывает хвост иначе, Lorenz curve делает неравенство видимым. Авторы поэтому заранее не назначают один индекс окончательным. Это здоровее, чем оптимизировать текст под метрику, которая лучше смотрится в заголовке.

У данных есть и тонкая историческая граница. Три collection-to-series relation были подтверждены текущими GET-запросами, но market rows не содержат non-null series key. Значит, current parent identity не доказывает, какая версия collection или rules действовала при создании, determination или settlement исторического объекта. Текущая документация помогает понять систему, но не должна тихо переписывать прошлое.

Наконец, REST и WebSocket - не взаимозаменяемые счетчики. В WebSocket-стриме было 1,487,330 tickers с created notification, а пересечение с REST-популяцией составило только 276,177. Это 18.57% набора WS-created и 3.63% REST-набора. Правильный вывод не "один канал сломан", а "у поверхностей разная логика наблюдения". Нельзя объявить одну из них золотым стандартом без независимого доказательства полноты.

Как измерять breadth: сначала назвать единицу, потом считать

Практически я бы вел минимум пять счетчиков, а не один. Первый - created objects, то есть реализованная supply. Второй - exact event keys, чтобы не перепутать несколько объектов одного события с новыми событиями. Третий - primitives и их reuse, чтобы увидеть базовый алфавит. Четвертый - concentration по collections и primitives. Пятый - activity, но только с точно указанным timestamp и определением.

В этой работе current snapshot дал 2,692,787 market objects с положительным cumulative volume или open interest: 35.38% REST-популяции. У 2,671,402 из них положительный open interest. Все 7,611,594 значений 24-hour volume были нулевыми, а четыре проверенных alias поля trade count отсутствовали. Поэтому авторы корректно называют результат current-snapshot activity-eligible, а не "долей исторически торговавшихся контрактов". Время активности, число сделок и попадание активности именно в семидневное окно эти поля не раскрывают.

Можно определить activity-equivalent breadth через веса $a_i$, например объем, число сделок или cap-weighted volume. После нормировки $\tilde a_i=a_i/\sum_j a_j$ используется

$B_A=\frac{1}{\sum_i \tilde a_i^2}, \qquad Q_A=\frac{B_A}{N_{created}}.$

$B_A$ - эффективное число активных единиц, а $Q_A$ - его доля от созданных объектов. Но и здесь нет волшебной цифры: volume может быть накопленным снимком, trade count может отсутствовать, а один источник ликвидности способен обслуживать множество близких комбинаций. Веса надо публиковать вместе с coverage и правилами censoring.

Полезная форма отчета - lifecycle funnel: created → queryable → active → traded → finalized. Каждая стрелка требует собственного определения "ever observed" и своей поверхности данных. Не заполняйте пропущенные состояния догадкой: 1,211,153 WS-created tickers вне REST были оставлены неразрешенными, а не искусственно приклеены к родителям.

Поэтому фраза "на Kalshi миллионы рынков" верна только как описание числа materialized market objects за конкретный интервал. Для аналитика, маркет-мейкера или исследователя важнее следующий вопрос: сколько здесь независимых источников неопределенности, сколько повторно использованных legs, где сосредоточено создание и сколько объектов действительно приобрели наблюдаемую активность? Число тикеров - начало измерения. Не его конец.

Источник

• Nechepurenko, "On-Demand Combinatorial Event Markets on Kalshi", arXiv:2609.17610