Дохідність 86% APY? Як використовувати ботів для заробітку на Polymarket

Оригінальна назва: Я створив бота для Polymarket і протестував різні налаштування параметрів, ось результати.

Оригінальний автор: @the_smart_ape, крипто-дослідник

Оригінальний переклад: Bitpush News

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

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

Логіка створення бота

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

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

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

buy up <usd> / buy down <usd>: Купівля на певну суму в USD.

buyshares up <shares> / buyshares down <shares>: Купівля точної кількості акцій з використанням зручного ордера LIMIT + GTC (Good 'Til Canceled), що виконується за поточною найкращою ціною пропозиції.

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

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

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

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

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

Параметри налаштування для автоматичного режиму такі: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: Розмір позиції для двоетапної угоди.

· sum: Порогове значення для допустимого хеджування.

· move (movePct): Поріг різкого падіння (наприклад, 0.15 = 15%).

· windowMin: Час від початку кожного раунду, протягом якого дозволено виконання Етапу 1.

Бектестинг

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

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

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

Моя друга думка — провести бектестинг з використанням історичних онлайн-даних з API Polymarket CLOB. На жаль, для ринку BTC 15-хвилинний up/down, ендпоінт історичних даних постійно повертає порожні набори даних. Без історичних тіків цін бектест не може виявити «приблизно 3-секундний різкий обвал», не може запустити Етап 1 і, незалежно від використовуваних параметрів, призводить до 0 циклів і 0% ROI.

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

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

Рекордер записуватиме знімки на диск, включаючи таке:

· Часова мітка

· Round Slug

· Залишок секунд

· ID токена UP/DOWN

· Найкраща ціна пропозиції UP/DOWN

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

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

Я почав тестувати цей набір параметрів:

· Початковий баланс: $1 000

· 20 акцій на угоду

· sumTarget = 0.95

· Поріг різкого падіння = 15%

· windowMin = 2 хвилини

Я також застосував постійну комісію 0,5% і спред 2%, щоб залишатися в консервативному сценарії.

Бектест показав 86% ROI, перетворивши $1 000 на $1 869 всього за кілька днів.

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

· Початковий баланс: $1 000

· 20 акцій на угоду

· sumTarget = 0.6

· Поріг різкого падіння = 1%

· windowMin = 15 хвилин

Результат: Через 2 дні дохідність інвестицій склала -50%.

Це наочно показує, що вибір параметрів є найкритичнішим фактором. Це може принести вам багато грошей або призвести до значних збитків.

Обмеження бектестингу

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

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

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

· Мікро-коливання менш ніж за секунду не фіксуються (дані семплюються щосекунди). Хоча бектестинг має часові мітки на рівні 1 секунди, багато чого може статися між кожною секундою.

· Проковзування в бектестингу постійне, без моделювання змінних затримок (наприклад, 200–1500 мілісекунд) або піків перевантаження мережі.

· Передбачається, що кожен сегмент угоди виконується «миттєво» (без черги ордерів, без відкладених ордерів).

· Витрати стягуються рівномірно, тоді як у реальності витрати можуть залежати від: Ринку/Токена, Мейкера-Тейкера, рівнів комісій або умов.

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

Хоча це навмисно консервативно, це не завжди відповідає реальності:

· Іноді Етап 1 може закритися раніше,

· Іноді він опиняється в грошах (ITM) і виграє,

· Іноді збиток може бути частковим, а не повним.

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

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

· Порушити книгу ордерів,

· Привабити або відштовхнути інших трейдерів,

· Викликати нелінійне проковзування.

Бектестинг передбачає, що ви є чистим видобувачем ліквідності (тейкером) без будь-якого впливу.

Нарешті, він не імітує обмеження швидкості, помилки API, відхилення ордерів, зупинки, тайм-аути, перепідключення або ситуації, коли бот зайнятий і пропускає сигнали.

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

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

Я планую запустити цього бота на Raspberry Pi, щоб не споживати ресурси на моєму основному комп'ютері і тримати його працюючим 24/7.

Тим не менш, є ще значний простір для покращень:

· Використання Rust замість JavaScript забезпечить набагато кращу продуктивність і час обробки.

· Запуск виділеного Polygon RPC вузла ще більше знизить затримку.

· Розгортання на VPS поруч із сервером Polymarket також значно знизить затримку.

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

Посилання на оригінальну статтю