Чому система фіксації курсу ламається на волатильному ринку
Система фіксації курсу обіцяє одне: клієнт підтверджує фіксацію курсу обміну й отримує рівно ту ціну, яку бачив на екрані. Поки ринок спокійний, обіцянка тримається.
Щойно ціна починає рухатися в межах хвилини, ланцюжок «джерело ціни, розрахунок, підтвердження, виконання» рветься одразу в кількох місцях.
Перше — розходження котирувань між джерелами. Біржа, пул ліквідності та агрегатор дають різні значення, а вікно усереднення додає лаг: на момент розрахунку цифра вже не відповідає ринку.
Чим ширший розкид між майданчиками, тим сильніше розходження котирувань і тим частіше система закладає ціну, якої на ринку вже немає.
Друге — затримка підтвердження. Між підтвердженням угоди та її потраплянням у блок минає час, і на волатильному ринку це коштує відсотків руху.
Звідси прослизання ціни: клієнт отримує виконання гірше зафіксованого, а якщо розрив перевищує поріг захисту, спрацьовує скасування угоди.
Найболісніше б'є саме скасування угоди на піку руху. Клієнт бачить відмову рівно тоді, коли ціна пішла на його користь, і йде до того, хто виконав.
Гірше, якщо відмова надходить із затримкою: ліквідність зарезервована, курс зафіксовано, а угода не закрита — розрахунковий залишок не сходиться, і розбиратися з цим доводиться вручну.
Розбираємо, як цей ланцюжок закривається.
Що дає керована ціна угоди: ефект у строках і частках
Підписане котирування — це зобов'язання, а не картинка на екрані. Джерело курсу (Chainlink) віддає значення разом із міткою часу та строком життя, а контракт обміну приймає лише ті заявки, чий підпис сходиться і чиє вікно не минуло.
Перевірка не пройдена — обмін не створюється взагалі: користувач бачить зрозумілу помилку замість частково виконаної угоди за зміщеною ціною.
Час підтвердження угоди скорочується, бо в заявки з'являється один детермінований шлях: перевірка підпису, резерв коштів, розрахунок. Немає очікування зовнішньої звірки курсу та повторних перерахунків — передбачувана ціна угоди відома до відправлення.
Вікно від натискання до підтвердження зменшується з десятків секунд до одиниць, і це гарантія, задана строком життя котирування, а не середнє за навантаженням.
Частка скасованих заявок падає з іншої причини: клієнт більше не рве угоду через рух ринку між показом ціни й підтвердженням. Скасування залишається усвідомленою дією, а прострочене котирування не вбиває заявку, а повертає її до перерахунку за свіжим курсом. Незавершених обмінів стає в рази менше, і кожна підтверджена заявка доходить до розрахунку.
Ручні розбори звернень переходять в автоматику. У котирування є ідентифікатор, усі підписи та переходи статусів пишуться в журнал, тому спірна угода відтворюється за логом за хвилини, а не відновлюється з листування.
Звернення на кшталт «куди пішла ціна» у штатному режимі зникають, а підтримка займається реальними збоями.
Три метрики — час, частка скасувань, ручні розбори — виводяться на панель моніторингу, тож ефект від керованої ціни видно в цифрах, а не на словах.
Режими утримання ціни: жорсткий, ковзний та умовний
Режим утримання визначає, хто бере на себе ризик руху курсу між розрахунком ціни та виконанням обміну.
У системі він задається двома параметрами: вікном утримання ціни — скільки живе зафіксоване значення, і лімітом на угоду — який обсяг можна закрити за цією ціною без перерахунку. Нижче — три режими та межі, за якими кожен із них перестає працювати в плюс.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Жорстке утримання ціни | Сума до отримання відома заздалегідь: виплати, розрахунки з фіксованою квотою, операції з низькою терпимістю до відхилення | Ризик руху ринку повністю на боці майданчика, тому вікно коротке, а ліміт на угоду нижчий за інші режими |
| Ковзне утримання ціни | Великі обсяги та періоди волатильності, коли важливіше виконати угоду, ніж утримати конкретне значення | Підсумкова сума не гарантована: ціна слідує за ринком усередині захисного коридору, за його межею угода зупиняється і потребує підтвердження |
| Умовне утримання ціни | Фіксація за подією: досягнення порогу, заданий час, статус контрагента або етап розрахунків | Потрібне зовнішнє джерело даних і явна логіка скасування — у разі недоступності умови заявка спливає, а не виконується за останньою ціною |
Режими не взаємовиключні: ядро піднімає жорстке утримання ціни на типових заявках, ковзне — на великих, а умовне працює як страховка на сценаріях із відкладеним розрахунком.
Перемикання задається правилом на рівні угоди, тому та сама інтеграція закриває різні схеми обміну без переписування логіки.
Перед введенням у роботу проганяємо на стенді спливання вікна, дроблення заявки за лімітом і недоступність джерела ціни — саме ці три випадки дають розходження в обліку.
Порядок впровадження: від аудиту потоку заявок до передачі
Починаємо з аудиту потоку заявок: дивимося, як котирування проходить від джерела до клієнта, де курс фіксується фактично і в який момент він може змінитися непомітно для обох сторін.
Результат етапу — карта вузьких місць і перелік сценаріїв, у яких клієнт отримує курс гірший за заявлений.
- Аудит потоку заявок — розбираємо журнали та черги, рахуємо частку заявок із розходженням курсу, фіксуємо затримку між підтвердженням і фактичним утриманням.
- Схема розрахунку курсу — описуємо джерела котирувань, їхню вагу, спред і вікно актуальності; правило відбракування застарілих значень формалізуємо у специфікації з прикладами.
- Налаштування правил утримання — задаємо вікно фіксації, ліміти за обсягом, умови часткового виконання та анулювання, поведінку системи при розриві потоку котирувань.
- Перевірка під навантаженням — відтворюємо профіль реального трафіку зі сплесками, заміряємо час від подання заявки до фіксації та переконуємося, що правила утримання не деградують на піку.
- Регламенти — описуємо для підтримки та чергової зміни, як читати журнали розходжень, що робити при зупинці джерела і як оформлювати спірні випадки.
- Передача — віддаємо конфігурації, схему розгортання, тестові сценарії та документацію, навчаємо команду і залишаємося на зв'язку на період супроводу.
Кожен крок закривається артефактом, який ви приймаєте: карта потоку, специфікація розрахунку, набір правил, звіт за навантаженням, регламенти, комплект документації. Так результат перевіряється до виведення в промислову експлуатацію, а не після.
Комплект постачання: налаштування, схеми та регламенти розрахунку
Систему фіксації курсу не можна вважати зданою, якщо її можна лише експлуатувати, але не можна переналаштувати. Тому до комплекту входять артефакти, за якими команда замовника сама змінює параметри, а сторонній підрядник розбирається без зворотного проєктування.
- Файли налаштувань — джерела котирувань, вікно утримання курсу, допустиме відхилення, ліміти на обсяг угоди. Редагуються конфігурацією, без зміни логіки та повторного розгортання.
- Схеми потоків заявок — шлях від подання до виконання: де перевіряються умови, де резервується забезпечення, де фіксується курс і що відбувається при відмові.
- Документація з розрахунку — формули курсу виконання та комісій, порядок округлення, правила звірки джерел і ознаки невиконуваної угоди.
- Правила доступу — ролі операторів, адміністраторів і зовнішніх систем, матриця прав, порядок видачі та відкликання ключів, ліміти на підпис операцій.
- Регламент розбору спірних угод — строки звернення, склад доказової бази, звірка з журналом подій, сценарій закриття завислої заявки.
- Регламент оновлення та відкату — як випускається нова версія, хто її підтверджує і за який час система повертається до попередніх налаштувань.
Окремо передаємо інструкцію з розгортання на вашому контурі: зміни перевіряються на копії до виведення в робоче середовище, тому налаштування та регламенти залишаються робочими документами, а не додатком до звіту.
Кейс: як скоротили частку оспорених угод утричі
Що було на вході
Сервіс обміну середнього розміру: клієнт натискав «зафіксувати курс», застосунок запам'ятовував цифру, а виконання йшло окремим запитом до зовнішнього джерела котирувань.
При різкому русі ринку вікно між фіксацією та підтвердженням розтягувалося, і курс в угоді розходився з курсом на момент списання.
Спірних угод накопичувалося 4,8% від обсягу, кожне звернення розбирали 2-3 дні — підтримка вручну звіряла біржові вивантаження, внутрішній кеш і дані CoinGecko. До 11% заявок клієнти скасовували самі, не дочекавшись підтвердження.
Що змінили
Фіксацію курсу перевели в серверний розрахунок: у момент запиту формується підписаний зріз курсу з міткою часу, і підтвердження угоди рахується за цим самим зрізом, а не за новим запитом до джерела.
Заявка стала ідемпотентною — унікальний ідентифікатор захищає від подвійного списання при повторі на поганому зв'язку. Додали поріг допустимого відхилення: якщо курс пішов далі, угода не підтверджується автоматично, а йде в чергу розбору разом із готовим контекстом.
Що стало
Частка оспорених угод — 4,8% → 1,6%. Розбір звернення — з двох днів до 40 хвилин: інженеру достатньо відкрити журнал, де зберігаються зріз, мітка часу та джерело розрахунку. Кількість скасованих заявок упала з 11% до 3%.
Розходження між фіксацією та підтвердженням трапляється в 0,1% угод і завжди пояснюється за журналом — стабільність розрахунку перестала залежати від того, хто і в яку секунду натиснув кнопку.
Як перераховується курс при частковому виконанні заявки
Утримана ціна прив'язана не до заявки загалом, а до обсягу, під який зарезервовано забезпечення. Коли надходить часткове виконання заявки, контракт фіксує ціну та обсяг цього виконання окремим записом, а резерв звільняє пропорційно: на 40% закритого обсягу йде 40% блокування. Залишок заявки продовжує жити як самостійна сутність зі своїм обсягом і своїм строком утримання.
Далі вступає правило перерахунку курсу. Модель «одне котирування на заявку» тримає початкову ціну до кінця строку утримання — залишок виконується за тією самою ціною, що й перша частина.
Модель «котирування на виконання» переоцінює залишок після кожного часткового виконання, беручи ціну з актуального стану джерела: ним слугує перевірений оракул на кшталт Chainlink, а не власний розрахунковий модуль.
Вибір моделі — це компроміс. Жорстко зафіксована ціна передбачувана для клієнта, але при різкому русі ринку залишок стає зручною ціллю для арбітражу: заявку навмисно добивають частинами, поки старе котирування ще живе.
Переоцінка знімає цей ризик, але додає заявці невизначеність — заздалегідь невідомо, за яким курсом закриється хвіст.
Тому залишок отримує повторне утримання ціни з явними межами. Якщо відхилення від початкового курсу виходить за заданий поріг, залишок не виконується: система скасовує його і повертає зарезервоване забезпечення, а не закриває за застарілою ціною.
Кожен виклик прив'язаний до ідентифікатора заявки та номера виконання, тому повторна обробка тієї самої події не подвоює резерв.
Назовні це виходить послідовним журналом: скільки виконано і за якою ціною, скільки залишилося, за якою ціною утримується залишок і до якого моменту.
Такий журнал дає однозначну звірку — розходження між звітом майданчика та станом заявки видно на конкретному кроці, а не розчиняється в агрегаті.
Часті технічні питання щодо розрахунку та захисту від розходжень
П'ять питань задають до старту робіт: від того, як улаштована відповідь, залежить архітектура розрахунку та набір перевірок. Нижче — короткі відповіді в тому вигляді, у якому ми їх даємо: без формулювання «зробимо надійно», а з конкретною механікою.
Звідки береться курс — одне джерело чи кілька?
Беремо вибірку незалежних постачальників і рахуємо медіану, а не середнє: одиничний викид не рухає результат. Якщо розходження котирувань між джерелами перевищує заданий допуск, значення відбраковується, а не усереднюється.
Що саме потрапляє в журнал розрахунків?
Кожна фіксація пише незмінний запис: вхідні котирування з мітками часу, застосований допуск, підсумковий курс, ідентифікатор запиту. Журнал лише доповнюється, а правка оформлюється окремим записом-коригуванням із посиланням на вихідний.
Як улаштований захист від маніпуляцій на тонкому ринку?
Курс рахується за часовим вікном, а не за однією точкою: короткочасний викуп обсягу не зсуне результат. Для пар із низькою ліквідністю поріг відхилення розширюється, а велика заявка йде на підтвердження.
Наскільки свіжими мають бути дані на момент фіксації?
У розрахунок іде значення не старше заданого інтервалу — застаріле котирування позначається й відбраковується. При обриві потоку система перемикається на резервне джерело і фіксує факт перемикання в журналі.
Чи можна перевірити розрахунок постфактум?
Так. За записом журналу розрахунок відтворюється: ті самі вхідні дані дають той самий курс. Це дозволяє розібрати спірний випадок без доступу до внутрішньої логіки сервісу.
Обговоримо задачу: що потрібно для старту робіт
Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібні вихідні дані за вашим сценарієм фіксації. Нижче — те, що знімає основну частину невизначеності; частину пунктів закриваємо прямо на дзвінку.
- Джерела курсу: свої чи зовнішні, скільки незалежних потоків, як вирішується розходження між ними.
- Логіка фіксації: хто ініціює, на який строк, що відбувається після закінчення і чи можна продовжити.
- Поведінка при відхиленні ринку: допустимий коридор, автоскасування, ручне підтвердження оператором.
- Ролі та доступи: хто ставить, підтверджує і скасовує фіксацію, які ліміти діють на оператора.
- Де рахується результат: ізольований контур, кастодіальний облік або гібридна схема.
- Облік і звітність: вивантаження для звірки, журнал усіх дій, вимоги до зберігання історії.
- Навантаження: скільки фіксацій на добу і скільки одночасно в піку.
- Що вже є: контракти, інтеграції, тестові стенди, обмеження вашої інфраструктури.
За цими даними збираємо оцінку та план робіт: розбиваємо на етапи, фіксуємо точки контролю та строки впровадження. Окремо рахуємо контур фіксації, інтеграції та відмовостійкість — так запуск можна робити частинами, без очікування всього обсягу. Опишіть задачу у вільній формі, решту уточнимо питаннями.
