Список проголосовавших за комментарий "whale8, <p>Мой друг, Вы абсолютно правы — вопрос нетривиальный, и статья намеренно его обходит, потому что ответ сложнее, чем базовая арбитражная логика.</p><p>Почему ASK(Up) + ASK(Down) < 1 вообще возможен<br/> Polymarket использует CLOB (Central Limit Order Book) — обычную биржевую книгу заявок, а не AMM. Это принципиально. В CLOB каждый маркетмейкер выставляет свои лимитные заявки независимо:</p><p>Маркетмейкер А выставил SELL на Up по $0.49 — 40 секунд назад<br/> Маркетмейкер Б выставил SELL на Down по $0.50 — 25 секунд назад</p><p>Эти ордера висят в книге независимо друг от друга. Платформа не проверяет в режиме реального времени, что ASK(Up) + ASK(Down) ≥ $1. Никакого on-chain ограничения нет. За это время цена BTC двинулась, оба маркетмейкера ещё не успели обновить котировки — окно открыто.</p><p>Сумма двух ask-цен < 1 — это не нарушение никакого инварианта, это просто стечение двух несинхронизированных устаревших ордеров. После того как бот их обе сбивает, окно закрывается. Но пока рынок движется, такие окна появляются снова и снова — именно поэтому бот работал на частоте 48.6 сделок/мин.</p><p>Вы правы в том, что это главная операционная проблема стратегии. У меня решение было реализовано через несколько уровней защиты, о которых я не хочу распространяться публично, так как это конкурентная информация.</p><p>Вы правы в том, что полностью безостаточная стратегия невозможна при CLOB. Это фундаментальный execution risk любой multi-leg арбитражной стратегии. Настоящий ответ не «как избежать остатка», а «как сделать так, чтобы ожидаемый убыток от остатка был меньше ожидаемой прибыли от успешных пар»:<br/> <a class="imgpreview" href="/uploads/2026/images/07/50/13/2026/04/28/99694a.png"><img src="/uploads/2026/images/07/50/13/2026/04/28/528a26.webp"/></a><br/> <br/> <br/> При $10, скорости < 100 мс и 28 000+ итерациях это неравенство выполнялось — до тех пор, пока комиссии не сделали π_pair отрицательным, и тогда весь расчёт рассыпался.</p>"