Розробка скальпінг-алгоритму для криптотрейдингу

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

Скальпінг-алгоритм: де втрачається результат на реальному ринку

Скальпінг-алгоритм заробляє на десятках коротких угод: утримання позиції вимірюється секундами, а прибуток з однієї угоди — частками відсотка. За такої економіки результат визначає не логіка входу, а якість виконання заявок.

Сигнал, порахований за однією ціною, виконується за іншою — і угода, яка в розрахунку була прибутковою, закривається в мінус.

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

Друга проблема — неповне виконання: обсяг закривається частково, розмір позиції виявляється меншим за розрахунковий, і алгоритм або добирає залишок за гіршою ціною, або залишається з незакритим ризиком.

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

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

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

Що змінюється після впровадження: швидкість відгуку та контроль ризику

Після запуску логіки змінюється не сама стратегія, а те, як вона виконує рішення. Алгоритм оцінює глибину ліквідності перед постановкою заявки, тому на різких рухах вхід іде за розрахунковою ціною, а не за першою доступною. Це прибирає основну статтю втрат скальпінгу — плату за вхід у момент сплеску волатильності.

Зниження прослизання на волатильних ділянках

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

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

Ліміти ризику та захист від серії збиткових угод

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

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

Стійкість стратегії тримається на повторюваності: однакові умови дають однакові рішення. Журнал угод і метрики показують, де факт розходиться із задумом, — це і є основа для наступної ітерації логіки.

Порівняння режимів виконання: лімітний, ринковий, гібридний

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

Варіант Коли підходить Обмеження
Лімітна заявка на вхід і вихід Спокійна склянка, вузький спред, висока ліквідність склянки Ризик не виконатися й пропустити рух
Ринкова заявка на вхід і вихід Імпульс, тонка склянка, важливий факт угоди Прослизання на кожній угоді
Гібрид: лімітний вхід, ринковий вихід Скальпінг на ліквідних парах як основний режим Потрібна роздільна логіка контролю входу та виходу

Лімітний режим і робота в склянці

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

Обмежувачі — час життя заявки та максимальне відхилення від розрахункової ціни: вони не дають логіці зависнути в очікуванні.

Гібридна логіка: лімітний вхід з ринковим виходом

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

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

Як будується робота: від розбору задачі до робочого запуску

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

Перевірка на історичних даних і на живому потоці

  1. Розбір задачі: на якій ринковій поведінці стратегія заробляє і які умови її вимикають.
  2. Підготовка даних: склянка та угоди за потрібними біржами — з пропусками, різними часовими поясами й періодами низької ліквідності.
  3. Перевірка на історичних даних: прогін окремо на спокійному та волатильному ринку, з комісіями й прослизанням. Частина гіпотез відсіюється тут — це очікуваний результат.
  4. Перевірка на живому потоці: алгоритм отримує реальні котирування й ухвалює рішення, але заявки не виставляються — звіряємо його реакцію з розрахунковою.

Запуск у режимі спостереження та передача управління

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

Конфігурації, журнали угод і регламенти супроводу

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

Правила управління ризиком і межі стратегії

  • Граничний розмір позиції та максимальна кількість одночасних заявок на інструмент.
  • Ліміт просадки за торгову сесію та дія при його досягненні — пауза або повна зупинка.
  • Обмеження на роботу в моменти низької ліквідності та розширеного спреду.
  • Автоматична зупинка при розриві потоку котирувань або розходженні даних між майданчиками.
  • Зниження обсягу угоди після серії збиткових спрацьовувань до перегляду налаштувань.
  • Межі допустимих значень: що можна змінювати руками, а що потребує перезбирання логіки.

Документація та порядок внесення правок

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

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

  • Порядок правок: заявка, перевірка на історичних даних, прогін на тестовому контурі, випуск.
  • Журнал угод з повним контекстом: параметри на момент входу, причина виходу, затримка виконання.
  • Регламент супроводу: що перевіряємо щоденно, що щотижня, кому повідомляємо про відхилення.

Кейс: як прибрали прослизання на тонкій склянці

Початкова ситуація та вузьке місце

Скальпінг-алгоритм працював на п'яти парах на біржі Binance, де на перших рівнях склянки трималося дві-три заявки.

Логіка виставляла лімітні ордери за ціною останньої угоди, без розрахунку доступної глибини: на спокійному ринку угоди проходили рівно, а на імпульсі прослизання з'їдало помітну частину розрахункового прибутку.

За вибіркою з 1200 угод фактична ціна входу відходила від цільової в середньому на 0,18%, а кожна двадцять п'ята угода — більш ніж на 0,5%.

Другим вузьким місцем було відновлення. Стан позицій жив лише в пам'яті процесу, тому обрив потоку угод або перезапуск вузла означав ручну звірку з біржею, виведення пари з торгівлі на 40–90 хвилин і пропущені входи, які алгоритм уже не наздоганяв.

Що змінилося після впровадження

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

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

Відновлення винесли в окремий контур: стан позицій і відкритих заявок пишеться на диск і звіряється з біржею при старті, конфлікти розв'язуються за даними біржі. Підйом після обриву зв'язку вкладається в 3–4 хвилини замість 40–90.

Метрики заміряли на тому самому наборі пар і тій самій логіці сигналів. Середнє прослизання впало з 0,18% до 0,04%, частка угод із прослизанням вище 0,5% — з 4% до 0,3%, кількість ручних втручань за місяць скоротилася з десятків до поодиноких.

Чим скальпінг-алгоритм відрізняється від арбітражного робота?

Арбітражний робот заробляє на розходженні ціни одного інструмента між майданчиками: сигнал видно у склянках, а угода закривається, коли розходження зникає. Скальпінг-алгоритм заробляє на мікроструктурі — читає потік заявок і мікрорухи ціни всередині одного майданчика. Звідси й різні горизонти, вимоги до швидкості та чутливість до витрат.

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

У скальпінгу сотні угод на день із прибутком у частки відсотка, і алгоритм зобов'язаний встигати відкриватися й закриватися до того, як потік заявок розвернеться.

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

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

Чутливість до комісії у скальпінгу вища на порядок.

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

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

Тому інфраструктура збирається під різну задачу: арбітражу — конектори до кількох майданчиків і контроль ризику однієї ноги, скальпінгу — швидкий потік ринкових даних, акуратна модель виконання та чесний облік витрат у тестах.

Технічні сумніви: затримки, ліквідність і відмови майданчика

Алгоритм скальпінгу живе на межі між швидкістю майданчика та якістю вхідних даних. Тому чесні обмеження підходу важливіші за обіцянки: нижче — сумніви, які найчастіше спливають при проєктуванні, і те, як ми закриваємо їх в архітектурі.

Сигнал приходить із затримкою — як зрозуміти, що ми не торгуємо проти ринку?

Затримка сигналу складається з отримання даних, розрахунку рішення та відправлення ордера. Ми вимірюємо кожну ділянку окремо й задаємо поріг свіжості: застарілі дані не дають виставити заявку.

Потік склянки беремо з кількох джерел і звіряємо їх між собою — розходження зупиняє торгівлю до з'ясування причини.

Що робити з обмеженнями майданчика — лімітами на запити та обсяг заявок?

У кожного майданчика свої правила щодо частоти звернень і розміру ордерів. Алгоритм тримає власний лічильник квоти й працює із запасом, а не на межі.

Частина заявок іде відкладеними, частина знімається до виставлення — так логіка не впирається в стелю й не отримує відмов на рівному місці.

Відмови з'єднання: що відбувається з уже відкритою позицією?

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

Ринок тонкий — як алгоритм поводиться на низькій ліквідності?

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

Обговоримо задачу: що потрібно від вас для оцінки та плану робіт

Щоб повернутися з оцінкою задачі та планом робіт, а не із загальними формулюваннями, потрібні вхідні дані для розрахунку.

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

Що достатньо надіслати або описати в першому повідомленні:

  • Майданчики та інструменти: на яких біржах торгуємо, які пари чи контракти в пріоритеті, де зосереджена ліквідність.
  • Режим доступу: торговий рахунок із правами на програмну торгівлю, тестовий контур біржі, обмеження на частоту запитів.
  • Логіка стратегії, якщо вона вже сформульована вручну: умови входу, усереднення та виходу, робота з частковим виконанням заявки.
  • Ризик-профіль: допустима просадка, розмір позиції, кількість одночасних угод, правило зупинки при збитковому дні.
  • Інфраструктура: де розміщуємо виконання, який канал до біржі, вимоги до стійкості при обриві зв'язку.
  • Дані для перевірки: історія котирувань і угод за період, на якому будемо підтверджувати гіпотезу.
  • Критерії успіху у ваших метриках: частка прибуткових угод, середній час утримання позиції, поведінка алгоритму на волатильних ділянках.

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

Напрямки блокчейн-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1393
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1368
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    815
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1139