Розробка крипто-обмінника: де ламається обмін і ліквідність
Біль входу в крипто-обмінник майже завжди однаковий. Внутрішні баланси кабінету розходяться з публічним реєстром: поповнення пройшло, а зарахування не відобразилося; виведення пішло, а резерв списався двічі.
На різкому русі ринку заявки зависають у проміжному стані — клієнт повторює угоду і отримує її двічі.
Причина не в окремому збої, а в архітектурі. Приймання коштів, котирування та виконання живуть у різних контурах зі своїми джерелами істини: поки немає єдиного журналу операцій і наскрізної звірки, будь-який розрив між ними перетворюється на ручний розбір і односторонню угоду.
Ціна вимірювана. Галузеві огляди, які ми розбирали разом із Chainalysis, сходяться: значна частка інцидентів на обмінних сервісах — не злами, а розсинхронізація балансів і завислі заявки.
Кожна година простою обмінного сервісу на живому ринку — втрачені обороти й клієнти, які повертаються вже до конкурента.
Вузькі місця обмінника розкриваються в момент навантаження, коли виправляти їх найдорожче. Тому розробку крипто-обмінника ми починаємо не з інтерфейсу, а з обліку: регулярна звірка з реєстром, карантин спірних операцій замість ручних правок, окремий контур для односторонніх угод. Розбираємо, як це закривається.
Що змінюється після впровадження: швидкість, маржа, стійкість
Керована архітектура змінює три вимірювані величини: частку заявок, закритих без оператора, час від відкриття до розрахунку та розмір маржі, яка залишається після роботи зовнішніх постачальників ліквідності. Нижче — за рахунок чого саме.
Час обробки заявки та черга операцій
Автоматизація обмінних операцій починається з того, що заявка зберігає стан на кожному кроці: перевірка адреси, резерв під пару, підтвердження в мережі, зарахування.
Кроки ідемпотентні, тому обробник після перезапуску продовжує з останнього стану, а не з нуля, — черга операцій не зростає під час сплеску навантаження.
Оператор втручається лише там, де авто-перевірки виставили прапорець ручного розбору; частка таких заявок і є метрикою швидкості обробки.
Усунений клас відмов і розрахунок маржі
Стійкість до відмов тут означає керовану поведінку під час збою зовнішнього постачальника: поки він відповідає довше заданого порогу, маршрутизація переводить потік на резервне джерело, а спред перераховується від фактичної ціни виконання. Зникає цілий клас відмов — заявки, закриті за застарілим курсом.
Маржа обмінника рахується за кожною угодою: комісія, вартість залучення ліквідності, прослизання. Розходження видно в реальному часі, тому ліміти правляться за фактом, а не за місячним звітом. Розмежування доступів і перевірки зводимо до вимог ISO/IEC 27001.
Гібридна модель обмінника проти прямих угод: що вибрати
Режим роботи обмінника визначає, звідки береться друга сторона угоди: із власного резерву майданчика, від зовнішніх постачальників ліквідності або від інших користувачів. Від цього залежать спред, швидкість виконання та поведінка сервісу під час різкого руху ринку. Нижче — реальні варіанти, між якими обирають на етапі проєктування.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний резерв | Вузький список пар, передбачуваний потік заявок | Капітал заморожений; під час тренду одна сторона резерву вичерпується |
| Гібридна модель обмінника | Багато пар, потрібні великі заявки без прослизання | Складніша звірка позицій, залежність від контрагентів |
| Прямі угоди між користувачами | Рідкісні пари, нестандартні активи | Довге очікування контрагента, потрібні ескроу та арбітраж |
| Книжковий обмін з ордербуком | Ліквідні пари з щільним потоком | Без маркет-мейкерів книга заявок залишається порожньою |
Гібрид: свій резерв плюс зовнішня ліквідність
Ядро рахує ціну за власним резервом, а обсяг, якого не вистачає, добирає у зовнішніх постачальників через маршрутизацію заявок. Резерв закриває дрібні угоди без затримки, зовнішній канал — великі та рідкісні пари.
Потрібні ліміти на контрагента й регулярна звірка позицій: розходження балансів інакше спливе на клієнтських виплатах.
Прямі угоди між користувачами та книжковий обмін
Майданчик тут не тримає капітал: він зводить заявки, блокує актив в ескроу до підтвердження оплати й вирішує спір через арбітраж. Обмеження моделі — час очікування контрагента й ризик недобросовісної поведінки, тому потрібні рейтинг, ліміти та зрозумілі правила розблокування. Ордербук дає миттєве виконання на ліквідних парах, але потребує постійної підтримки книги заявок.
Порядок впровадження: від аудиту до передачі в експлуатацію
Розробка крипто-обмінника йде хвилями, і порядок тут важливіший за швидкість: спочатку фіксуємо те, як кошти рухаються зараз, і лише потім змінюємо. Інакше нова логіка розрахунку лягає поверх неврахованих ручних операцій, і розходження спливають уже на живих клієнтах.
- Аудит інфраструктури обмінника. Знімаємо карту вузлів, зовнішніх джерел курсу й ліквідності, місць зберігання ключів і списку тих, хто має доступ. Окремо виписуємо все, що досі робиться руками.
- Схема руху коштів. Описуємо маршрут від надходження на адресу до зарахування на баланс користувача: резерви, підтвердження мережі, ліміти, комісії, завислі операції та порядок їх розбору.
- Налаштування середовищ. Розводимо контури розробки, тестовий і робочий, тримаємо однакові конфігурації, секрети — поза репозиторієм, ключі в кожного контуру свої. Перевірки та експерименти перестають торкатися бойових коштів.
- Правила розрахунку. Задаємо спред і маржу, порядок застосування курсу, округлення, ліміти на операцію й на пару — з журналюванням кожного рішення, щоб розрахунок можна було пояснити й перерахувати.
- Приймальні перевірки на історичних даних. Проганяємо нові правила на записах минулих угод і звіряємо результат до останнього знака. Розходження — привід повернутися до схеми, а не списувати на похибку.
- Передача в експлуатацію. Передаємо регламенти, дашборди, оповіщення про відхилення та порядок відкату до попереднього стану, навчаємо чергову зміну.
Хто і що робить на кожному кроці
Аудит і схему потоків ведуть наші інженери разом із вашим фінансистом і службою підтримки — вони знають реальні винятки. Середовища, розрахунковий модуль і приймальні прогони закриваємо ми, а рішення про запуск ухвалюєте ви після демонстрації звірки. Далі залишаємося на зв’язку за регламентом супроводу.
Комплект передачі: конфігурації, схеми, політики доступу
Комплект передачі збирається паралельно з розробкою, а не в кінці: кожен контур описується в момент, коли до нього вноситься зміна.
Тому документація на систему не розходиться з фактичною конфігурацією, а приймання перетворюється на звірку, а не на відновлення історії з листування.
Документація та схеми
- Схеми інтеграцій: потоки ордерів між ядром обмінника, контуром ліквідності, гаманцями, антифродом і джерелами курсу — з точками відмови та таймаутами.
- Конфігурації середовищ: параметри тестового, передпродуктивного й продуктивного контурів — ліміти, спреди, список активів, налаштування повторів запитів.
- Опис моделі даних: угоди, проводки внутрішнього обліку, баланси й історія статусів; порядок звірки з блокчейном.
- Інструкції для операторів: обробка завислої заявки, ручна виплата, переведення пари в режим лише читання.
Регламенти та матриця відповідальності
- Матриця ролей і політики доступу: хто змінює ліміти, ініціює виведення й ротує ключі — розподіл обов’язків і другий фактор.
- Регламенти обслуговування: планові роботи, оновлення вузлів і курсових джерел, резервне копіювання та перевірка відновлення.
- Регламент реагування: дії під час стрибка курсу, сплеску виведень або відмови провайдера — пороги оповіщень і відповідальні.
- Порядок відкату: версія конфігурації, автор зміни, спосіб повернути попередній стан без простою.
Кейс: як скоротили ручні операції та прибрали клас відмов
Обмінник працював на гібридній моделі: частину обсягу закривала внутрішня книга заявок, частина йшла на зовнішню ліквідність.
Вузьким місцем стала не пропускна здатність, а ручні операції — оператор підтверджував кожне виведення, звіряв залишки на гарячому й холодному гаманцях і розбирав розходження за журналом.
Клас відмов виявився дорогим: під час повторного надсилання запиту на виведення через мережевий таймаут операція могла пройти двічі, і розходження спливало лише на наступній звірці.
Реакція на такий збій займала години, а спірні угоди закривалися вручну — за виписками й листуванням.
Що змінили: ідемпотентність за ідентифікатором операції, автоматичну звірку балансів з оповіщенням при розходженні, порогові правила маржі та чергу модерації, куди потрапляють лише аномалії вище ліміту. Ручне підтвердження залишилося там, де сума або поведінка акаунта виходять за задані межі.
Що було до і що стало після
| Показник | До | Після |
|---|---|---|
| Частка операцій з ручним підтвердженням | більшість виведень | одиниці відсотків, лише аномалії |
| Реакція на розходження балансів | години, за фактом виявлення | хвилини, за оповіщенням |
| Спірні угоди за квартал | десятки | поодинокі |
| Пошук причини збою | вручну за журналом | за ідентифікатором операції, хвилини |
Клас відмов із подвійним проведенням виведення більше не відтворювався: повторний запит відсікається за ідентифікатором операції, а звірка знаходить розходження раніше, ніж його помітить клієнт.
За галузевими даними Chainalysis, помітна частина інцидентів в обмінниках пов’язана не з пробитим периметром, а з операційними процесами й ручними підтвердженнями — цей шар ми й прибрали.
Що робити, якщо платформа вже розгорнута на готовому рішенні?
Міграція обмінного сервісу майже ніколи не робиться одним перемиканням.
Готове рішення проти свого — це не вибір «або-або»: стара платформа продовжує обслуговувати клієнтів, поки поруч піднімається власне ядро з тим самим набором операцій — приймання заявки, розрахунок курсу, списання й зарахування, виведення. Обидва контури живуть одночасно, і це знімає головний ризик — простій обміну.
Перенесення даних операцій починається з історії: заявки, угоди, рухи за балансами й комісії переносяться пакетами з контрольними сумами та повторюваним записом, тому повторний прогін не створює дублів.
На час переходу обидві системи пишуть у спільний облік або синхронізуються зустрічним обміном, а звірка за кожним клієнтом іде до повного збігу залишків.
Поступовий перехід трафіку — за напрямами й валютними парами. Спочатку на нове ядро йде невелика частка заявок з обмеженням суми, потім ліміти піднімаються, а старий контур залишається резервним маршрутом.
Курсовий і ризик-контур при цьому спільний: розходження котирувань між платформами неприпустиме, інакше з’являється арбітраж усередині власного сервісу.
Окремо закриваємо технічні сумніви: заявки, завислі в проміжному статусі, подвійне списання під час збою, повернення на готове рішення в один бік.
Для цього ведемо журнал операцій, регулярно звіряємо підсумки й тримаємо механізм швидкого відкату, який повертає весь трафік на попередню платформу без втрати історії.
Технічні сумніви: зберігання коштів, маржа, перевірки
Найпоширеніше технічне питання замовника — де фізично лежать кошти клієнтів і в кого на руках ключі. Ми будуємо кастодіальну модель із розділенням на гарячий, теплий і холодний контури: у гарячому лише операційний запас під виведення, решта — у холодному зберіганні.
Приватні ключі не потрапляють на сервер застосунку: підпис транзакції проходить через окремий сервіс із пороговою схемою, де компрометація одного майданчика не відкриває доступ до балансу.
Другий шар — розрахунок маржі та перевірка операцій. Нарахування обчислює не біржа й не інтерфейс, а власний модуль із журналом подвійного запису: кожна угода, комісія й ручне коригування — окрема проводка з незмінним ідентифікатором.
Регулярна автоматична звірка зіставляє внутрішні баланси з фактичними залишками на адресах, і розходження вище порогу зупиняє виведення до розбору.
Хто володіє приватними ключами після здачі проєкту?
Ключами керуєте ви. Ми описуємо процедуру генерації, резервного копіювання й ротації часток доступу, але не зберігаємо за собою можливість виведення коштів. Передача доступів іде за протоколом із фіксацією відповідальних.
Як перевіряється коректність нарахувань?
Кожна операція проходить через журнал подвійного запису, тому баланс завжди сходиться за проводками, а не за поточним значенням у базі. Спірну угоду можна підняти цілком: заявка, курс на момент виконання, комісії, статуси.
Що відбувається при спірній операції?
Виведення за рахунком можна призупинити точково, без зупинки всієї платформи. Історія угод незмінна, тому розбір спирається на фактичні записи, а не на відновлені логи.
Обговоримо задачу: що потрібно для оцінки та плану робіт
Щоб повернутися з оцінкою задачі та планом робіт, а не загальними формулюваннями, нам потрібен мінімум вхідних даних. Нижче — про вашу поточну схему, а не про наші шаблони: чим точніше опишете обмін і навантаження, тим менше припущень залишиться в кошторисі й календарі.
- Поточна схема обміну: звідки беруться котирування, куди йдуть заявки, як зараз зводяться залишки і в якому місці рахується маржа.
- Ролі та доступи: хто змінює курси, хто підтверджує виведення коштів, які права потрібні оператору, ризик-менеджеру й підтримці.
- Вимоги до перевірок: обов’язкові кроки перед зарахуванням і виведенням, пороги для ручного розбору, що робити при розходженні балансу.
- Очікуване навантаження: скільки операцій на добу, пікові години, скільки напрямів обміну й пар плануєте тримати на старті.
- Контури та інтеграції: платіжні канали, рішення для зберігання активів, внутрішні системи, з якими обмінник має обмінюватися даними.
- Терміни впровадження: дата, до якої обмінник має працювати, етапи запуску, чи є готова інфраструктура й вимоги майданчика.
- Хто з боку замовника приймає результат і за якими критеріями домовимось вважати роботу прийнятою.
Отримавши це, ми називаємо склад команди під ваш обсяг: скільки інженерів потрібно, хто відповідає за зведення заявок, хто за безпеку й перевірки, кого підключаємо на інтеграції. Далі розкладаємо роботи за етапами з датами й точками приймання. Опишіть задачу — повернемося з оцінкою та планом робіт.
