Розробка White-label криптобіржі

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розробка White-label криптобіржі
Складний
від 2 тижнів до 3 місяців
Часті запитання

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

Етапи блокчейн-розробки

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

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

Розробка White-label крипто-біржи

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

Що входить в white-label біржу

Обов'язкові компоненти

Trading core:

  • Matching engine — ядро біржи, виконання ордерів
  • Order management system (OMS) — управління життєвим циклом
  • Market data system — генерація та розповсюдження котировок, candles
  • Risk engine — pre-trade та post-trade checks

Кустодіальна система:

  • HD wallet generator — унікальні адреси для кожного користувача
  • Cold/hot wallet management — розділення оперативних та схованих коштів
  • Deposit detection — моніторинг вхідних трансакцій
  • Withdrawal processor — обробка виводів з multi-sig

Compliance:

  • KYC/AML інтеграція (Sumsub, Jumio, Onfido)
  • Transaction monitoring (Chainalysis, Elliptic)
  • FATF Travel Rule підтримка
  • Reporting інструменти

Користувацький інтерфейс:

  • Trading terminal (spot + опціонально derivatives)
  • Гаманець та історія трансакцій
  • Admin panel — управління користувачами, ризиками, ліквідністю

API:

  • REST + WebSocket для трейдерів
  • FIX protocol для інституціональних (опціонально)
  • Admin API для інтеграцій

Опціональні модулі

  • Margin / Futures trading
  • P2P платформа
  • Launchpad / IEO
  • Staking
  • NFT marketplace інтеграція
  • Referral та loyalty програми

Архітектура Matching Engine

Matching engine — найкритичніший компонент. Продуктивність і надійність тут визначають якість усього продукту.

Структура Order Book

Зберігання order book в пам'яті, не в базі даних. Типова реалізація на Rust або C++:

use std::collections::BTreeMap;

struct OrderBook {
    // BTreeMap — відсортований за ціною, O(log n) insert/delete
    bids: BTreeMap<Price, PriceLevel>,  // DESC: найкращий курс зверху
    asks: BTreeMap<Price, PriceLevel>,  // ASC: найкращий курс знизу
    orders: HashMap<OrderId, Order>,    // швидкий lookup по ID
}

struct PriceLevel {
    price: Price,
    total_quantity: Quantity,
    orders: VecDeque<OrderId>,  // FIFO queue на кожному ціновому рівні
}

FIFO matching (price-time priority) — стандарт для spot бірж. Pro-rata — на деяких derivatives.

Типи ордерів

Мінімальний набір для production біржи:

Тип Опис Складність реалізації
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 Середня

Throughput та Latency

Вимоги для серйозної біржи:

  • Throughput: 10,000–100,000 orders/sec
  • Latency: <1ms order-to-ack (matching), <10ms end-to-end
  • Market data: <5ms від трейду до оновлення стакану для всіх підписаних

Досягається через: lock-free очереди (LMAX Disruptor паттерн), single-threaded matching core, memory-mapped файли для persistence, kernel bypass networking (DPDK або RDMA в HFT).

Для більшості white-label проектів з обсягом <$10M/день достатньо Go або Java реалізації з throughput 5,000-10,000 ops/sec. Rust/C++ потрібен при >$100M/день.

Кустодіальна архітектура

Hot/Cold/Warm розділення

Класична архітектура зберігання коштів:

Холодний гаманець (90%+ коштів)
├── Multi-sig 3-of-5 (hardware security modules)
├── Офлайн підписання трансакцій
└── Ручне управління, тільки крупні виводи

Теплий гаманець (5-8%)
├── Multi-sig 2-of-3
├── Автоматичне поновлення з cold
└── Обробка крупних виводів

Гарячий гаманець (2-5%)
├── Single-sig або 1-of-2
├── Автоматична обробка малих виводів
└── Ліміт: максимальний обсяг за 24ч

Transition rules:

  • Якщо hot < 1% → автоматичний переказ з warm
  • Якщо hot > 10% → переказ надлишку в cold
  • Всі переводи між рівнями логуються та алертуються

HD Wallet та адресація

Кожен користувач отримує унікальну адресу депозиту, використовуючи BIP-44 деривацію:

m / purpose' / coin_type' / account' / change / address_index
m / 44'       / 0'         / 0'       / 0      / user_id

Сід-фраза зберігається в HSM або AWS CloudHSM. Ніколи в базі даних чи конфіг файлах.

Deposit Detection

class DepositDetector:
    async def monitor_evm_deposits(self, network: str):
        """Моніторинг EVM deposit адрес через WebSocket"""
        async with websockets.connect(self.rpc_ws_url) as ws:
            # Subscribe на нові блоки
            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)

    async def process_block(self, block_hash: str, network: str):
        block = await self.get_block_with_txs(block_hash)
        deposit_addresses = await self.db.get_all_deposit_addresses(network)

        for tx in block["transactions"]:
            if tx["to"] in deposit_addresses:
                await self.process_deposit(tx, network)

            # ERC-20 трансфери через logs
            if tx.get("to") in self.supported_token_contracts:
                logs = await self.get_tx_logs(tx["hash"])
                await self.process_erc20_deposits(logs, deposit_addresses)

Мінімум підтверджень перед зарахуванням:

  • Bitcoin: 2-3
  • Ethereum: 12-20 (залежить від суми)
  • Polygon, Arbitrum: 20-64 (залежить від finality)

Ліквідність та Market Making

Проблема ліквідності на старті

Нова біржа без ліквідності — пустий order book. Трейдери не приходять без ліквідності, а ліквідність не з'являється без трейдерів. Класична задача про яйце та курку.

Рішення:

Агрегація зовнішної ліквідності—підключення до API Binance, OKX, Kraken через market making бота. Бот виставляє ордери у ваш book, хеджує позиції на зовнішній біржі. Спред = ваш дохід, ризик = execution risk при швидких рухах.

B-Book модель — біржа сама виступає контрагентом. Вищий ризик, повний контроль ліквідності.

Liquidity aggregator інтеграції — B2Broker, Cumberland, Wintermute надають інституціональну ліквідність white-label проектам за fee або spread sharing.

Market Making Bot Архітектура

class MarketMaker:
    def __init__(self, symbol, external_exchange, internal_exchange):
        self.symbol = symbol
        self.hedge_exchange = external_exchange  # Binance, OKX
        self.target_exchange = internal_exchange

        self.spread_bps = 5  # 0.05% спред
        self.order_size_usd = 10_000
        self.layers = 5  # рівнів глибини

    async def update_quotes(self):
        mid_price = await self.get_reference_price()

        for i in range(1, self.layers + 1):
            spread_multiplier = i * self.spread_bps / 10000
            bid_price = mid_price * (1 - spread_multiplier)
            ask_price = mid_price * (1 + spread_multiplier)
            size = self.order_size_usd / mid_price / i  # зменшуємо далі

            await self.target_exchange.place_order('buy', bid_price, size)
            await self.target_exchange.place_order('sell', ask_price, size)

KYC/AML та Compliance

Рівні KYC

Рівень Верифікація Ліміти
KYC 0 Email only Депозит заборонений
KYC 1 Email + телефон $500/день
KYC 2 ID документ + selfie $10,000/день
KYC 3 Enhanced due diligence $100,000/день
Institutional Корпоративна верифікація Без ліміту

Travel Rule

FATF Travel Rule вимагає передавати інформацію про відправника/одержувача при переводах >$1000 між VASPs. Інтегруйте з Notabene, Sygna, TRP або OpenVASP.

Ігнорування Travel Rule створює юридичні ризики в ЄС (MiCA), США (FinCEN), Великобританії.

Deployment та Інфраструктура

Рекомендована інфраструктура:

Matching Engine ────── bare metal або dedicated VPS
                        (без VM для latency-critical)

Market Data Service ── Kubernetes + Redis Cluster

API Gateway ─────────── Kubernetes + NGINX (rate limiting, auth)

Database ────────────── PostgreSQL primary + 2 read replicas
                        (TimescaleDB для time-series)

Cache ───────────────── Redis Cluster

Queue ───────────────── Kafka (audit log, event sourcing)

Monitoring ──────────── Prometheus + Grafana + PagerDuty

Регуляторні вимоги

Вибір юрисдикції — критичне рішення. Популярні варіанти:

Юрисдикція Ліцензія Час Вартість
Естонія VASP 3-6 місяців €10,000-30,000
Литва VASP 2-4 місяці €5,000-15,000
BVI VASP 6-12 місяців $20,000+
Сейшели VASP 3-6 місяців $15,000+
Dubai (VARA) VASP 6-18 місяців $50,000+
EU (MiCA) CASP 12-24 місяці $100,000+

Розробка повної white-label біржи: 9-18 місяців для команди з 8-15 інженерів, $500,000–$2,000,000. Існуючі white-label вендори (Openware, B2Broker, Merkeleon) пропонують базові рішення від $30,000/рік — розумна точка старту для більшості.