Більшість статей «як створити криптобіржу» написані людьми, які ніколи її не експлуатували. Вони перелічують функції, називають ціну і зупиняються. Цей гайд побудований інакше — навколо рішень, які насправді визначають, чи запуститься біржа вчасно, чи переживе перший інцидент і чи пройде due diligence банківських та комплаєнс-партнерів. Приклади взяті з нашої роботи над BitXChange — біржею crypto-to-crypto з великим каталогом пар та окремими бек-офісами для адмінів, власників і партнерів.
Визначте, яку саме біржу ви будуєте
«Криптобіржа» — це щонайменше чотири різні продукти з різним профілем ризику:
| Модель | Що це | Найскладніше |
|---|---|---|
| Централізована спотова (CEX) | Ви тримаєте кошти користувачів і ведете книгу ордерів | Кастоді, матчинг, комплаєнс |
| Лише crypto-to-crypto | CEX без фіатних шлюзів | Ліквідність, операції з лістингом |
| Брокер / миттєвий обмін | Котирування від провайдера ліквідності, без книги ордерів | Ціноутворення, хеджування, прослизання |
| Фронтенд DEX | Інтерфейс поверх ончейн-протоколів, некастодіальний | UX гаманців, MEV, надійність RPC |
Цей вибір визначає все далі. Крипто-біржа без фіату, як BitXChange, уникає банківських інтеграцій і карткових процесингів, що прибирає місяці з комплаєнс-дорожньої карти, але їй усе одно потрібні кастоді, матчинг-рушій і операції з лістингом. Брокерська модель дозволяє запуститися з одним провайдером ліквідності за кілька тижнів, але обмежує маржу. Фронтенд DEX має найлегший комплаєнс, але найменший контроль над торговим досвідом.
Якщо ви ще не ухвалили це рішення явно — зробіть це раніше за все інше. Далі йдеться про централізовану біржу, бо саме її мають на увазі більшість засновників, коли просять у нас оцінку.
Ключові компоненти
Production CEX має сім підсистем. Частину можна купити, частину збудувати, частину відкласти, але кожна з них існує з першого дня, плануєте ви її чи ні.
1. Акаунти, KYC і права доступу
Реєстрація, двофакторна автентифікація, керування сесіями, відстеження пристроїв і API-ключі. KYC зазвичай делегують провайдеру (Sumsub, Onfido, Veriff та інші) через вебхук-потік: користувач проходить верифікацію у віджеті провайдера, провайдер викликає ваш бекенд, бекенд змінює рівень акаунта та пов'язані ліміти. Моделюйте рівні й ліміти як дані з самого початку — змінювати їх доведеться частіше, ніж здається.
2. Книга обліку (ledger)
Ledger — серце біржі й та частина, яку більшість команд недооцінює. Кожна зміна балансу — депозит, угода, комісія, виведення, коригування — має бути транзакцією подвійного запису з посиланням на джерело. Ledger має бути append-only, ідемпотентним і звірюваним з ончейн-балансами та станом матчинг-рушія.
Два правила, які ми ніколи не порушуємо:
- Баланси виводяться із записів ledger і ніколи не оновлюються на місці без відповідного запису.
- Кожна зовнішня подія (підтверджений депозит, виконаний ордер) має ключ ідемпотентності, щоб повторний вебхук або відтворене повідомлення не зарахували кошти двічі.
3. Матчинг-рушій
Матчинг-рушій приймає ордери й породжує угоди. Для запуску з відібраним набором пар однопроцесна in-memory книга ордерів на кожен ринок із персистентним журналом подій достатньо швидка і значно простіша для розуміння, ніж розподілений дизайн. Пріоритет ціна-час, лімітні та ринкові ордери, скасування і порядковий номер на кожній події — усе, що потрібно для старту. Часткові виконання, post-only, стоп-ордери та захист від самоторгівлі додаються, коли з'являється реальний обсяг.
Проєктуйте рушій як чисту функцію над потоком подій: за однакових вхідних даних він дає однакову книгу та угоди. Це робить його тестованим, відтворюваним після збою та аудитованим, коли користувач оскаржує виконання.
4. Ринкові дані
Знімки та дельти книги ордерів, тики угод, свічки й тікери, що доставляються в браузер через WebSocket. Патерн, який спрацював у нас: рушій публікує події в шину повідомлень, сервіс ринкових даних тримає стан по кожному ринку й розсилає клієнтам, а фронтенд веде локальне нормалізоване сховище, щоб кожен віджет — книга, графік, останні угоди, відкриті ордери — рендерився з одного джерела правди. Фронтенд-частину ми детально описали у кейсі TradeBot.
5. Гаманці та кастоді
Депозити вимагають генерації адрес на користувача і на актив, відстеження підтверджень із правилами фінальності для кожної мережі та обробки реоргів. Виведення вимагають підпису з гарячого гаманця з лімітами, холодного зберігання більшості коштів, перевірок швидкості та черги ручного погодження вище порога.
Варіанти — від власної інфраструктури нод до кастоді-провайдера (Fireblocks, BitGo, Copper). Для першого запуску кастоді-провайдер майже завжди правильний вибір: він скорочує дорожню карту на місяці й дає комплаєнс-партнерам щось упізнаване. Будуйте власне лише тоді, коли комісії або контроль виправдовують операційний тягар.
6. Бек-офіси
Операторам потрібні інструменти з першого дня: лістинг і конфігурація пар, тарифи комісій, керування користувачами та лімітами, погодження виведень, засоби реагування на інциденти (зупинити ринок, заморозити акаунт) і звітність. На BitXChange ми побудували три окремі бек-офіси з різними наборами прав — адміни, власники та партнери, — бо люди, які керують лістингом, не ті, хто має бачити персональні дані користувачів чи погоджувати виведення. Рольовий доступ і журнали аудиту на кожну дію — не обговорюються.
7. Торговий фронтенд
Торговий інтерфейс — те, за чим вас судять користувачі, і водночас складна інженерна задача: безперервні оновлення ринку, щільна інформація, введення ордерів із клавіатури та нульова толерантність до застарілих даних. Ми будуємо цей шар на Next.js і TypeScript із сховищем реального часу, що живить незалежні віджети. Серверний рендеринг тримає маркетингові та акаунтні сторінки швидкими й індексованими; сам торговий екран — клієнтський застосунок.
Комплаєнс: що насправді потрібно
Саме на комплаєнсі біржові проєкти буксують — зазвичай тому, що засновники або ігнорують його, або намагаються вирішити все до запуску. Практичний мінімум для централізованої біржі:
- Ліцензія або реєстрація у юрисдикції діяльності. Вимоги дуже різняться (MiCA в ЄС, реєстрація VASP у Литві та Польщі, VARA в Дубаї, ліцензії money transmitter у штатах США). Визначте юрисдикцію до архітектури, бо з неї випливають вимоги до розташування даних і звітності.
- Програма KYC/AML: рівні верифікації, скринінг санкцій і PEP, моніторинг транзакцій з оцінкою ризику, звітування про підозрілу активність і зберігання записів. Більшість цього постачають провайдери; ваша система має зберігати докази та діяти за результатами.
- Travel Rule для переказів вище порогів — через провайдера або протокол (Notabene, Sumsub Travel Rule, TRP).
- Журнал аудиту кожної зміни балансу та кожної адміністративної дії зі зберіганням, що вимірюється роками.
- Умови, конфіденційність і розкриття ризиків, написані юристом, який знається на цифрових активах.
Ми інженери, а не юристи. Наша робота — перекласти комплаєнс-програму на технічні контролі: моделі даних для рівнів і лімітів, вебхук-потоки для KYC, хуки моніторингу для скринінгу транзакцій, незмінні журнали та експортовані звіти. Закладайте бюджет на комплаєнс-консультанта з самого початку — це дешевше, ніж переробляти.
Безпека: без компромісів
Біржі атакують безперервно з дня, коли вони з'являються в блок-експлорері. Базовий рівень:
- Розділення гарячих і холодних гаманців зі строгими лімітами на гарячий і мультисигом або MPC для холодного зберігання.
- Контроль виведень: білий список адрес, підтвердження 2FA, часові блокування після змін безпеки, ліміти швидкості та ручна перевірка вище порогів.
- Інфраструктура з мінімальними привілеями, секрети у сховищі, жодних спільних облікових даних і ключі підпису, які ніколи не торкаються серверів застосунку.
- Rate limiting і захист від автоматизації на ендпоїнтах автентифікації та торгівлі.
- Сканування залежностей, обов'язкове код-рев'ю та відрепетируваний runbook інцидентів.
- Зовнішній пентест перед запуском і після великих змін.
Нічого екзотичного. Важливо, щоб це було закладено в дизайн, а не додано після першого інциденту.
Команда, терміни та бюджет
Для MVP crypto-to-crypto CEX — спотова торгівля відібраними парами, кастоді через провайдера, KYC через провайдера, адмін-бек-офіс і веб-інтерфейс торгівлі — реалістичний план такий:
- Команда: техлід, два бекенд-інженери, один-два фронтенд-інженери, QA-інженер, дизайнер і проджект-лід на часткову зайнятість. П'ять-сім людей.
- Терміни: чотири-шість місяців до контрольованого публічного запуску, з внутрішньою торгівлею в тестнетах до третього місяця.
- Бюджет: перший етап у діапазоні 40–80 тис. USD для сфокусованого обсягу з провайдерами кастоді та KYC; 150–300 тис. USD для платформи з кількома бек-офісами, маржинальними продуктами чи власним кастоді. Постійні витрати — комісії провайдерів, інфраструктура, перевірки безпеки та чергування підтримки.
Брокерський продукт або миттєвий обмін можна запустити за шість-десять тижнів і за частку бюджету; фронтенд DEX — у схожому діапазоні. CEX коштує дорожче не через інтерфейс, а через ledger, кастоді та операції.
Уроки BitXChange
Три речі, які ми сказали б кожному, хто сьогодні починає біржу:
Відокремте лістинг від релізів. Оператори мають додавати пару, задавати їй комісії та ліміти й відкривати для торгівлі без інженерного деплою. Ми зробили конфігурацію пар даними з поетапним викочуванням (прихована, лише читання, активна), і це прибрало найбільше джерело тертя між бізнесом та інженерною командою.
Будуйте бек-офіси рано. Спокусливо спочатку випустити торговий UI, а операції вести запитами до бази. Кожна біржа, яка так робить, шкодує про це, коли хтось о третій ночі погоджує не те виведення. Рольові бек-офіси з журналами аудиту — частина MVP.
Ставтеся до ринкових даних як до продукту. Користувачі пробачать повільну сторінку налаштувань; вони не пробачать застарілу книгу ордерів. Окремий шлях ринкових даних — рушій → шина → сервіс розсилки → нормалізоване клієнтське сховище — ось що тримає інтерфейс надійним під навантаженням.