Один розробник поділився, як створити торгового бота для Polymarket, який за допомогою захоплення цінових коливань на ринку BTC за 15 хвилин може перетворити 1000 доларів у 1869 доларів за кілька днів, з прибутковістю до 86%. У статті детально описано логіку побудови бота, методи бек-тестування та їх обмеження.
(Передісторія: лідер прогнозних ринків Polymarket оголосив про створення власного L2, чи зникла козирна карта Polygon?)
(Додатковий контекст: як за допомогою арбітражу на Polymarket отримати річний дохід 40%?)

Зміст статті

• Логіка побудови бота
• Бек-тестування
• Обмеження бек-тестування
• Інфраструктура

Кілька тижнів тому я вирішив створити власного бота для Polymarket. Повну версію я розробляв кілька тижнів.

Мене спонукало те, що на Polymarket дійсно існує вразливість у ефективності, хоча вже є кілька ботів, які використовують ці недоліки для отримання прибутку, але їх все ще недостатньо, і можливості цього ринку значно перевищують кількість ботів.

Логіка побудови бота

Логіка цього бота базується на моїй раніше вручну виконуваній стратегії, яку я автоматизував для підвищення ефективності. Бот працює на ринку «BTC 15 хвилин UP/DOWN».

Бот має систему моніторингу в реальному часі, яка автоматично перемикається на поточний раунд BTC за 15 хвилин, передаючи найкращі цінові пропозиції (best bid/ask) через WebSocket, відображаючи їх у фіксованому інтерфейсі терміналу та дозволяючи керувати через текстові команди.

У ручному режимі ви можете безпосередньо розміщувати ордери.

buy up / buy down : купити на певну суму в доларах.

buyshares up / buyshares down : купити точну кількість акцій, використовуючи зручний інтерфейс з ордерами LIMIT (з обмеженням ціни) + GTC (діє до скасування), за найкращою пропозицією продажу (best ask).

Автоматичний режим виконує повторюваний двоступінчастий цикл.

На першому етапі він спостерігає за ціновими коливаннями протягом windowMin хвилин після початку раунду. Якщо будь-яка сторона падає досить швидко (зниження щонайменше на movePct приблизно за 3 секунди), запускається «Перша частина (Leg 1)», і бот купує ту сторону, яка зазнала різкого падіння.

Після завершення Leg 1 бот більше не купує ту саму сторону. Він чекає на «Другу частину (Leg 2, хеджування)» і активує її лише за умови: leg1EntryPrice + oppositeAsk <= sumTarget.

Якщо ця умова виконується, він купує протилежну сторону. Після завершення Leg 2 цикл закінчується, і бот повертається до стану спостереження, очікуючи на новий сигнал про падіння з такими ж параметрами.

Якщо під час циклу раунди змінюються, бот скасовує відкритий цикл і починає новий з тими ж налаштуваннями.

Параметри автоматичного режиму: auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares: розмір позиції для двох етапів торгівлі.
• sum: поріг для хеджування.
• move (movePct): поріг падіння (наприклад, 0.15 = 15%).
• windowMin: кількість хвилин з початку раунду, протягом яких дозволено виконувати Leg 1.

Бек-тестування

Логіка бота дуже проста: чекати різкого обвалу, купити ту сторону, що щойно впала, потім чекати стабілізації ціни і хеджувати протилежною стороною, при цьому гарантувати, що: priceUP + priceDOWN < 1.

Але цю логіку потрібно протестувати. Чи вона справді працює на довгостроковій основі? І важливо, що у бота багато параметрів (кількість акцій, сума, відсоток руху, тривалість в хвилинах). Яка комбінація параметрів є найоптимальнішою для максимізації прибутку?

Моя перша ідея — запустити бота в реальному режимі на тиждень і спостерігати за результатами. Проблема в тому, що це займе багато часу і дозволить протестувати лише один набір параметрів, а мені потрібно багато.

Друга ідея — використовувати історичні дані з Polymarket CLOB API для бек-тестування. На жаль, для ринку BTC 15 хвилин UP/DOWN історичні дані не повертаються — API повертає порожній набір. Відсутні історичні цінові тики, тому неможливо визначити «падіння за 3 секунди», і відповідно, Leg 1 не буде активований незалежно від параметрів, що дає 0 циклів і 0% ROI.

Після додаткового дослідження я з’ясував, що інші користувачі також стикалися з проблемою отримання історичних даних для деяких ринків. Я протестував інші ринки, які повертають історичні дані, і зробив висновок: для цього конкретного ринку історичні дані взагалі не зберігаються.

Через це єдиний надійний спосіб бек-тестування цієї стратегії — під час роботи бота, записуючи у файл найкращі цінові пропозиції (best-ask) у реальному часі, створюючи власний набір історичних даних.

Записувач робить знімки у файл, що містять:

• таймстамп
• ідентифікатор раунду (round slug)
• залишилися секунди
• ID токену UP/DOWN
• найкращу ціну пропозиції (best ask)

Після цього «записаний бек-тест (recorded backtest)» відтворює ці знімки і застосовує ту ж автоматичну логіку з високою точністю. Це гарантує отримання високочастотних даних для виявлення падінь і хеджування.

За 4 дні я зібрав 6 ГБ даних. Могло бути й більше, але я вважаю, що цього достатньо для тестування різних наборів параметрів.

Я почав тестувати цю конфігурацію:

• Початковий баланс: $1,000
• Кількість акцій на кожну операцію: 20
• sumTarget = 0.95
• Падіння: 15%
• windowMin = 2 хвилини

Також я застосував фіксовану комісію 0.5% і спред 2%, щоб зберегти консервативний сценарій.

Результати бек-тесту — ROI 86%, за кілька днів $1,000 перетворилися на $1,869.

Далі я протестував більш агресивні параметри:

• Початковий баланс: $1,000
• Кількість акцій: 20
• sumTarget = 0.6
• Падіння: 1%
• windowMin = 15 хвилин

Результат: через 2 дні ROI становив -50%.

Це ясно показує, що вибір параметрів — найважливіший фактор. Вони можуть принести великі прибутки або суттєві збитки.

Обмеження бек-тестування

Навіть з урахуванням комісій і спредів, бек-тест має свої обмеження:

• По-перше, він базується лише на кількох днях даних, що може бути недостатньо для повного аналізу ринку.
• Він залежить від записаних знімків найкращих цін пропозицій; у реальності ордери можуть частково виконуватися або за іншими цінами. Глибина книги і доступний об’єм не моделюються.
• Не враховуються мікроволатильності менше секунди (дані зберігаються з частотою 1 секунда). Хоча таймстамп є, між секундами може статися багато.
• У бек-тесті спред фіксований, не моделюється змінна затримка (200–1500 мс) або пікові навантаження мережі.
• Кожна операція вважається миттєвою (без черги ордерів, без виставлення ордерів у очікуванні).
• Витрати враховуються однаковими для всіх операцій, тоді як у реальності вони залежать від ринку/токена, учасників, рівня комісій тощо.

Щоб бути обережним, я застосував правило: якщо Leg 2 не виконується перед закриттям ринку, Leg 1 вважається повністю програшним (total loss).

Це дуже консервативний підхід, але він не завжди відповідає реальності:

• іноді Leg 1 можна закрити раніше,
• іноді він закінчується в прибутку (ITM),
• іноді збитки будуть частковими, а не повними.

Хоча збитки можуть бути переоцінені, це дає уявлення про найгірший сценарій.

Найголовніше — бек-тест не може врахувати вплив великих ордерів на книгу або привернення інших трейдерів. У реальності ваші ордери можуть:

• порушити баланс книги,
• привернути або відлякати інших трейдерів,
• спричинити нелінійний спред.

Бек-тест уявляє, що ви — чистий «price taker», без впливу на ринок.

Крім того, він не моделює обмеження частоти запитів (rate limits), помилки API, відмови ордерів, паузи, тайм-аути, повторне підключення або пропуски сигналів через зайнятість бота.

Бек-тест дуже корисний для визначення діапазонів хороших параметрів, але не гарантує 100% результату, оскільки деякі ефекти реального світу не можна змоделювати.

Інфраструктура

Я планую запускати цього бота на Raspberry Pi, щоб не навантажувати основний комп’ютер і працювати цілодобово.

Але тут є ще багато можливостей для покращення:

• Переписати на Rust замість JavaScript — для значно кращої продуктивності та швидкості обробки.
• Запустити спеціальний вузол Polygon RPC — для зменшення затримки.
• Розмістити на VPS, розташованому ближче до серверів Polymarket — для ще меншої затримки.

Звісно, є й інші оптимізації, які я ще не відкрив. Зараз я вивчаю Rust, оскільки він стає незамінним у Web3-розробці.

#####