Чому система бектестингу DeFi розходиться з реальною торгівлею
Розходження прогону й ринку — не похибка округлення, а наслідок того, як зібрані дані та як виконується угода. У системі бектестингу DeFi картина повторюється: тестова крива згладжена, а в мережі стратегія втрачає частину дохідності або йде в просадку. Причини вимірювані й відтворюються на одній і тій самій історії.
Неповна історія: пул живе кілька років, і саме на цьому вікні перевіряється стратегія. Періоди аномальної дохідності в дані потрапляють, стиснення ліквідності — ні.
Перевірка DeFi-стратегій на такому відрізку переоцінює стійкість: рідкісні події, які й визначають результат, у вибірці відсутні.
Підміна цін закриття: розрахунок бере знімок стану пулу раз на інтервал, тоді як угода виконується проти кривої між цими точками. Зсув ціни всередині інтервалу не враховується, і чим волатильніше вікно, тим сильніше розходження.
Глибина ліквідності та прослизання в розрахунку: за фіксованого зсуву ціни модель ігнорує просадку, яку створює сам ордер. У тонкому пулі велика угода рухає ціну, а комісії та подорожчання виконання за конкуренції за місце в блоці зведені до константи.
Помилка того, хто вижив: відбір іде за пулами й токенами, що дожили до сьогоднішнього дня, — закриті та обнулені у вибірку не потрапляють. Набір виглядає надійніше, ніж був у реальному часі, а підгонка параметрів під ту саму історію піднімає метрику й знижує переносимість.
Далі — як це закривається: які дані потрібні, як вважається виконання і що перевіряється до виходу стратегії в мережу.
Вимірний ефект: швидкість прогонів, збіжність і розбір просадок
Перерахунок набору параметрів по всій історії займає хвилини замість діб: прогін рахується за заздалегідь зібраними й нормалізованими даними, а не за запитом до вузла на кожну ітерацію.
Сітка параметрів рахується паралельно й кешується за зрізами — змінюється один коефіцієнт, перераховується лише зачеплена частина. Інженер встигає прогнати десятки конфігурацій за зміну й побачити, де відгук стратегії ламається.
Збіжність результатів прогону з реальним виконанням — головний критерій довіри до тесту.
Угоди відновлюються з подій у мережі, комісії, прослизання та вартість газу рахуються як у фактичній угоді, тому розходження залишається в межах похибки моделі, а не відрізняється в рази й не перевертає висновок про дохідність. Саме на цій підставі вибирається конфігурація, а не на гарній кривій.
Заглядання в майбутнє виключаємо структурно: стратегія бачить лише ті дані, що були доступні на момент рішення. Відкладений період перевірки не бере участі в підборі параметрів узагалі — він залишається недоторканим до фінального прогону.
Стійкість стратегії оцінюємо на кількох режимах ринку: зростання, боковик, різке падіння ліквідності в пулах Uniswap.
Просадки пояснюються даними, а не здогадками. Видно, яка частка збитку прийшла від ціни активу, яка — від прослизання на тонкому пулі, яка — від затримки виконання.
Замість висновку «стратегія не спрацювала» з’являється розбір із внеском кожної причини — і правка йде в конкретний вузол логіки, а не в модель цілком.
Режими прогону: векторизований, подієвий і портфельний
Режим прогону визначає, які ефекти взагалі потраплять у результат. Векторизований розрахунок обробляє історію цін цілком масивами, подієва реконструкція програє стрічку блоків і відгуки контрактів, портфельна симуляція додає загальний баланс, ліміти й чергу заявок. Швидко й повно одночасно не буває — режим вибирають під питання, на яке потрібна відповідь.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Векторизований розрахунок | Масовий відбір гіпотез, груба оцінка на довгій історії | Не бачить стану всередині блоку, прослизання й ліквідації — виконання ідеалізовано |
| Подієва реконструкція | Перевірка механіки протоколу: комісії, оракули, ліквідації, порядок заявок у блоці | Повільніше на порядки, потребує архіву станів, тисячі варіантів не прогнати |
| Портфельна симуляція | Кілька стратегій на спільному балансі: конкуренція за капітал, ліміти ризику | Помилка в моделі впливу угоди на ціну спотворює результат одразу за всіма стратегіями |
Що не можна отримати дешевим способом
Стан всередині блоку, вплив великої угоди на ціну, порядок заявок за перевантаження мережі дешевим режимом не відтворюються: їх або моделюють приблизно, або отримують подієвим прогоном з архівованими станами.
Робоча схема — відбір гіпотез векторизовано, фінальні кандидати через подієвий прогін, портфель цілком на узгодженому складі стратегій.
Розходження режимів на простій стратегії вказує на помилку в моделі комісій, оракула чи порядку заявок — поки її не усунуто, результатам довіряти не можна.
Як ми збираємо стенд: від аудиту даних до передачі регламенту
Стенд збирається під конкретну стратегію, а не «загалом»: спочатку фіксуємо, які рішення вона ухвалює і на яких даних, потім будуємо контур, який ці рішення відтворює. Порядок етапів невипадковий — помилка в підготовці історії знецінює будь-яку перевірку після неї.
- Розбір стратегії. Логіка входу й виходу, набір сигналів, управління позицією і те, що вважаємо виконанням — закриття інтервалу або зміна стану контракту.
- Аудит джерел. Глибина історії, пропуски, розходження між незалежними постачальниками цін, обробка реоргів: без цієї перевірки виходять гарні, але хибні результати.
- Схема даних. Приводимо вивантаження до єдиного вигляду з прив’язкою до часу блоку, додаємо комісії пулу, прослизання та ліквідність, доступну на момент угоди.
- Складання розрахункового контуру. Відтворюваний прогін: однаковий вхід дає однаковий результат, стан фіксується за кроками, журнал угод і метрик зберігається.
- Перевірка на відкладеному періоді. Частина історії не бере участі в налаштуванні — вона показує, де стратегія підігнана під минуле.
- Стрес-сценарії. Сплеск волатильності, провал ліквідності, зростання вартості газу, затримка виконання, відмова джерела: дивимося, де контур ламається.
- Передача та регламент прогонів. Віддаємо стенд із документацією, описуємо порядок запуску, критерії зупинки й оновлення даних, навчаємо команду.
Далі прогони запускаєте самі — і бачите, як змінюється поведінка стратегії за зміни припущень.
Артефакти передачі: схеми даних, набори параметрів, звіти
Передача закінчується не репозиторієм, а набором артефактів, за якими ваша команда може повторити будь-який прогін без нас і пояснити результат зовнішньому аудиту. Нижче — що залишається в замовника і навіщо потрібен кожен елемент.
- Схема даних — таблиці угод, станів пулів і котирувань: типи полів, ключі, зв’язки, глибина історії та правила обробки пропусків у джерелі.
- Довідник джерел — звідки беруться дані, частота оновлення, затримка щодо моменту угоди та поведінка за розходження двох джерел.
- Набори параметрів — готові профілі прогону: комісії пулу, прослизання, горизонт утримання, крок перерахунку й правила виходу з позиції.
- Словник полів звіту — що означає кожна метрика, як рахується дохідність з урахуванням комісій і що саме ми називаємо просадкою.
- Шаблони звітів — зведення за стратегією, розподіл результатів за періодами, список найгірших угод із причинами спрацювання.
- Розмежування доступу — аналітик змінює параметри й запускає прогони, ризик-менеджер бачить історію, а зафіксований результат не можна переписати заднім числом.
- Документація прогонів — журнал запусків із версією набору параметрів, знімком даних і списком змін щодо попереднього прогону.
- Регламент запуску — порядок дій: підняти середовище, прогнати стратегію, порівняти результат із зафіксованим і зрозуміти, звідки розходження.
Такий комплект знімає залежність від підрядника: через місяці ви відтворюєте цифру зі звіту й бачите, які параметри її змінили.
Кейс: збіжність моделі й ринку зросла втричі
Замовник прийшов з арбітражною стратегією на кількох пулах ліквідності Uniswap: на історичних даних графік зростав рівно, у реальній торгівлі результат не відтворювався.
Розходження моделі й ринку давали два місця — комісії за обмін і момент виконання угоди щодо руху ціни всередині пулу. Ми перезібрали кейс бектестингу заново, розділивши історію на навчальний і відкладений відрізки.
Що змінювали в моделі
У розрахунок додали лаг між сигналом і потраплянням угоди в блок, прослизання на кожному кроці та фактичні ставки комісій замість усередненої константи.
Окремо описали стрес-період: коли ліквідність різко перекладається між пулами, ціна всередині одного відходить від ціни в другому. Модель тепер вважає це не аномалією, а робочим сценарієм — і перевіряє, чи встигає арбітраж закритися до вирівнювання.
Метрики до і після
Збіжність розрахункової дохідності з фактичною на відкладеному періоді зросла втричі, частка відхилень понад допустимий поріг упала з 21% до 7%. Похибка в оцінці результату окремої угоди знизилася з 0,9% до 0,3% — розрахунок перестав показувати прибуток там, де його немає.
Перевірка на історичних даних іде прогоном за кількома незалежними відрізками, включно з епізодами різких перекладань ліквідності.
Якщо стратегія не проходить хоча б один, її відхиляють або відправляють на доопрацювання з явною межею застосовності — замовник бачить, де модель ламається, до виведення коштів.
Чим відрізняється бектестинг на історії від перевірки в реальному часі?
Історичний прогін і спостереження в реальному часі відповідають на різні питання. Перший показує, як стратегія проходить десятки тисяч угод на довгому горизонті, другий — чи доживає сигнал до реального виконання. У системі бектестингу DeFi вони йдуть послідовно, бо не замінюють одне одного.
Прогін на історії дає статистику за цілими ринковими циклами: зміну трендів, затяжні просадки, поведінку за тонкої ліквідності. Він відтворюваний — ту саму конфігурацію переграють з іншими порогами ризику й порівнюють результати.
Слабке місце — ідеальні умови: угода вважається виконаною за ціною з блоку, без черги заявок, прослизання й конкуренції за ліквідність. Розрив помітний там, де дохідність залежить від ставок і глибини пулів, — наприклад, у Aave.
Тіньовий режим закриває саме цю прогалину. Стратегія підключається до живого потоку й формує сигнали, але транзакції не надсилає: видно фактичну затримку між сигналом і блоком, перебудову ланцюжка, моменти, коли ліквідність виходить із пулу.
Плата за точність — час: значущу вибірку набирають тижнями, а рідкісні сценарії потрапляють до неї одиницями.
Перевірка на малому обсязі — наступний крок, де в діло йдуть реальні кошти. Вона підтверджує фактичні ціни виконання, витрати на комісії мережі, поведінку стратегії за відмов і часткового заповнення. Ризик обмежений розміром позиції, тому такий прогін безпечний для налагодження операційних деталей.
Підсумок: історія відповідає, чи є у стратегії перевага; тіньовий режим — чи доходить сигнал до блоку; малий обсяг — чи збігається розрахунок із фактом. Ми вибудовуємо ці етапи в один перевірочний цикл, щоб стратегія виходила на повний обсяг уже зі зрозумілою статистикою.
Сумніви щодо даних, ліквідності та відтворюваності прогонів
До першого прогону замовник хоче переконатися, що цифри на виході взагалі щось означають. Тому питання зазвичай одні й ті самі: звідки історія, як ураховано виконання і чи повториться результат завтра. Нижче — відповіді без загальних слів.
Звідки береться історія угод і як перевіряється її якість?
Збираємо дані з кількох незалежних джерел і звіряємо їх між собою: розходження за обсягом і ціною на блок позначаються, а не усереднюються мовчки.
Окремо обробляємо перебудови ланцюжка й «діри» в ліквідності — інакше на пропущеному інтервалі стратегія покаже угоду, якої в реальності не було. За кожним активом зберігається прапорець якості, і прогін може бути зупинений, якщо частка сумнівних свічок вища за заданий поріг.
Чи враховуються витрати виконання та глибина пулів?
Так, і це головна різниця між гарним і правдивим результатом. Комісії пулу, ціна газу на момент угоди та прослизання рахуються за фактичною глибиною конкретного пулу, а не за середнім відсотком по ринку.
Якщо обсяг угоди перевищує доступну ліквідність на цей блок, її або розбивають на частини, або позначають як невиконувану — до звіту вона не потрапляє.
Чи можна прогнати систему на стратегії, яка вже працює?
Так. Ми відновлюємо стан позицій на потрібну дату й рахуємо далі лише за новими даними, не перераховуючи історію заднім числом. Так видно, де фактичні угоди розходяться з розрахунковими, і це розходження — найкорисніший сигнал під час доналаштування правил.
Чи повторяться цифри, якщо запустити прогін заново?
Прогін прив’язаний до знімка даних і версії правил виконання — за їх збігу результат збігається до останньої угоди. Якщо цифри розійшлися, отже, змінився один із трьох шарів: дані, правила або джерело випадковості. Ми фіксуємо всі три, тому розходження завжди пояснюване, а не списується на «ринок інший був».
Обговоримо задачу і повернемося з оцінкою та планом прогонів
Щоб оцінка проєкту спиралася на ваш контур, а не на усереднені припущення, нам потрібен мінімум вхідних даних. Нижче — що запитуємо на старті: за цими пунктами рахуємо трудомісткість і склад робіт, після чого повертаємося з планом прогонів і передачею стенду.
- Доступ до даних. Вивантаження угод, знімки стану пулів, історія котирувань — у вихідному вигляді та з описом полів: валюта розрахунку, часовий пояс, одиниці вимірювання. Формат підійде будь-який читабельний: колонкові файли, вивантаження з бази, потік із вузла.
- Обсяг історії. Який горизонт потрібен і які періоди обов’язкові — спокійний ринок, обвали, моменти низької ліквідності. Від цього залежить, скільки сценаріїв покриваємо і де з’являться пропуски в даних.
- Логіка стратегій. Правила входу й виходу, розрахунок розміру позиції, моменти ребалансування, умови зупинки. Чим формальніший опис, тим менше припущень закладаємо в модель.
- Облік витрат. Комісії пулів, прослизання, вартість транзакцій, затримка виконання. Без цього прогін показує результат, якого на реальному ринку не було.
- Інфраструктура та доступи. Де розгортаємо стенд, які права потрібні, чи є обмеження на вивантаження даних назовні.
- Критерії приймання. Які метрики вважаємо достовірними і з чим звіряємо розрахунок — з вашими ручними прогонами або з незалежним джерелом.
- Передача стенду. Що має залишитися у вас: конфігурації прогонів, схема даних, інструкція з відтворення та порядок запуску без нашої участі.
Опишіть задачу у вільній формі та додайте те, що вже є з даних. Повернемося з оцінкою проєкту та планом робіт — за етапами, строками й складом стенду.
