White-label криптобіржа: matching engine, безпека та ліцензування

Вступ: чому white-label криптобіржа — не завжди просто клон Багато компаній обирають готове white-label рішення для криптобіржі, але стикаються з проблемами: низька продуктивність matching engine, вразливості в кастодіальній системі, невідповідність регуляторним вимогам. White-label від досвідчен

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

Часті запитання

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

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1451
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1270
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1011

Вступ: чому white-label криптобіржа — не завжди просто клон

Багато компаній обирають готове white-label рішення для криптобіржі, але стикаються з проблемами: низька продуктивність matching engine, вразливості в кастодіальній системі, невідповідність регуляторним вимогам. White-label від досвідченого вендора — компроміс, але тільки якщо архітектура продумана. Ми ділимося досвідом: які компоненти критичні, як влаштований matching engine на Rust, чому безпека коштів — не опція, а необхідність, і які юрисдикції підходять для ліцензування. Якісне white-label рішення дозволяє скоротити капітальні витрати в 2–3 рази порівняно з розробкою з нуля, при цьому даючи готовий production-ready код. Типова помилка — обирати вендора, який пропонує тільки фронтенд і базовий API, а складні компоненти на кшталт matching engine та кастодіальної системи віддає на аутсорс.

Ключові компоненти white-label криптобіржі

White-label криптобіржа — не просто клон з перефарбованим логотипом. Це повноцінний продукт: matching engine, кастодіальна система, KYC/AML, ліквідність та compliance. Розберемо архітектуру, реальні складнощі та як відрізнити якісне рішення від дешевої підробки.

Як влаштований matching engine?

Matching engine — критичний компонент, що визначає продуктивність. Order book зберігається в пам'яті, не в БД. Типова реалізація на Rust:

Код matching engine на Rust
use std::collections::BTreeMap; struct OrderBook { bids: BTreeMap<Price, PriceLevel>, asks: BTreeMap<Price, PriceLevel>, orders: HashMap<OrderId, Order>, } struct PriceLevel { price: Price, total_quantity: Quantity, orders: VecDeque<OrderId>, } 

FIFO matching (price-time priority) — стандарт для spot. Pro-rata — для derivatives.

Вимоги для production: 10,000–100,000 orders/sec, latency <1ms matching, <10ms end-to-end. Для обсягів до $10M/day достатньо Go/Java; Rust/C++ потрібен при >$100M/day. Matching engine на C++ обробляє до 500,000 orders/sec, що в 10 разів швидше за Python-реалізацію.

Тип ордера Опис Складність
Market Виконання за найкращою ціною Низька
Limit Виконання за вказаною ціною Низька
Stop-limit Тригер → limit Середня
Stop-market Тригер → market Середня
OCO One-cancels-other Середня
Trailing stop Слідує за ціною Висока
Iceberg Прихований обсяг Висока
Post-only Тільки maker Низька
IOC / FOK Immediate-or-cancel / Fill-or-kill Середня

Як організовано зберігання коштів?

Класична схема: більше 90% в холодному гаманці (multi-sig, HSM), 5–8% у теплому (автоматичне поповнення з cold), 2–5% у гарячому (дрібні виведення). Логіка переходів: якщо hot < 1% → переказ з warm, якщо hot > 10% → надлишок у cold.

Адресація: кожен користувач отримує унікальний deposit адресу через BIP-44 деривацію. Сид-фраза HD wallet — тільки в HSM або AWS CloudHSM.

Deposit detection (Python)
class DepositDetector: async def monitor_evm_deposits(self, network: str): async with websockets.connect(self.rpc_ws_url) as ws: await ws.send(json.dumps({ "id": 1, "method": "eth_subscribe", "params": ["newHeads"] })) async for message in ws: block_data = json.loads(message) if "params" in block_data: block_hash = block_data["params"]["result"]["hash"] await self.process_block(block_hash, network) 

Confirmations: Bitcoin 2–3, Ethereum 12–20, Polygon/Arbitrum 20–64.

Вирішення проблеми ліквідності

Нова біржа без ліквідності — порожній order book. Варіанти:

  1. Агрегація зовнішньої ліквідності: market-making бот підключається до Binance/OKX, виставляє orders у ваш book, хеджує позиції зовні. Spread — ваш дохід.
  2. B-Book модель: біржа сама контрагент (високий ризик, повний контроль).
  3. Institutional ліквідність: провайдери на кшталт B2Broker, Cumberland, Wintermute за fee або spread sharing.

White-label рішення обходиться в 2-3 рази дешевше, ніж розробка з нуля, при цьому забезпечує той самий рівень функціональності.

Ліквідність та compliance: що потрібно передбачити

Рівні KYC: від email-only (без депозиту) до institutional (без ліміту). FATF Travel Rule вимагає передачі даних відправника/отримувача при переказах >$1000 між VASPs. Інтеграція з Notabene, Sygna або OpenVASP обов'язкова для юрисдикцій ЄС (MiCA), США (FinCEN), UK. За даними нещодавнього звіту, 70% криптобірж стикаються з вразливостями в кастодіальних системах — тому аудит коду critical.

Параметр White-label Розробка з нуля
Терміни 3–6 міс. 9–18 міс.
Вартість В 2-3 рази нижча (від $150 000) Висока (від $500 000)
Кастомізація Обмежена Повна
Безпека Перевірений код Вимагає аудиту

Юрисдикції для ліцензування

Популярні варіанти: Естонія (VASP), Литва (VASP), BVI (VASP), Сейшели, Dubai VARA, EU MiCA. Вибір залежить від цільового ринку та бюджету. Детальніше про Virtual Asset Service Provider — що це та як регулюється.

Процес розробки та терміни

Етапи: аналітика → проектування архітектури → реалізація matching engine, кастодіальної системи, frontend → інтеграція KYC/AML, ліквідності → тестування (unit, integration, pen test) → деплой на bare metal для matching engine, Kubernetes для market data, API Gateway, БД.

Рекомендована інфраструктура: PostgreSQL + TimescaleDB, Redis Cluster, Kafka, Prometheus + Grafana. Вибір юрисдикції — критичне рішення.

Від 9 до 18 місяців для команди з 8–15 інженерів, залежно від scope. Ліцензування white-label вендора (Openware, B2Broker, Merkeleon) — альтернатива для швидкого старту.

Що входить у роботу?

Доставка рішення під ключ включає:

  • Повну документацію (API, архітектура, інструкції для адмін)
  • Доступи до репозиторію з вихідним кодом
  • Навчання технічної команди клієнта (до 2 тижнів)
  • Технічну підтримку на період запуску
  • Інтеграцію з KYC/AML провайдерами та ліквідністю
  • Базову кастомізацію інтерфейсу

Як обрати white-label провайдера

  1. Запитайте технічне портфоліо: які blockchain інтегрують, скільки замовлень в секунду витримує matching engine.
  2. Перевірте, чи надається вихідний код та можливість аудиту.
  3. Уточніть compliance-модулі: які юрисдикції підтримуються, чи є Travel Rule.
  4. Оцініть кастомізацію: чи можна змінювати інтерфейс, додавати пари, налаштовувати ліміти.
  5. Запитайте документацію по API та інтеграції з зовнішніми провайдерами ліквідності.

Ми розробляємо white-label біржі більше 9 років: 20+ запущених проєктів, навантаження до $200M/день. Гарантія безпеки — перевірений код та сертифіковані рішення. Зв'яжіться для обговорення вашого проєкту — підберемо архітектуру та терміни. Замовте консультацію під ключ за 3 дні — ми оцінимо вартість та терміни для вашого кейсу.