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

Разработка 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 для institutional клиентов (опционально)
• 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 matching используется на некоторых derivatives площадках.

Типы ордеров

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

Throughput и latency

Требования для серьёзной биржи:

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

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

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

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

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 и адресация

Каждый пользователь получает уникальный deposit адрес, используя BIP-44 деривацию:

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

Для EVM-совместимых сетей часто используют один адрес per user (дешевле в деривации). Для UTXO-based (Bitcoin) — один адрес per транзакция (лучше privacy).

Сид-фраза HD wallet хранится в HSM (Hardware Security Module) или 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 transfers через 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)

Минимум confirmations перед зачислением:

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

Ликвидность и market making

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

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

Решения:

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

B-Book модель — биржа сама выступает контрагентом (т.н. market making desk). Высокий риск для биржи, но полный контроль над ликвидностью. Используется некоторыми форекс-брокерами.

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

Market making bot архитектура

Если строим собственный market making:

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% spread
        self.order_size_usd = 10_000
        self.layers = 5  # уровней глубины

    async def update_quotes(self):
        mid_price = await self.get_reference_price()  # с hedge exchange

        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

Travel Rule

FATF Travel Rule требует передавать информацию об отправителе/получателе при переводах >$1000 между VASPs (Virtual Asset Service Providers). На практике это означает интеграцию с Notabene, Sygna, TRP или OpenVASP протоколом.

{
  "transfer": {
    "originator": {
      "name": "John Doe",
      "accountNumber": "IBAN or blockchain address",
      "address": "..."
    },
    "beneficiary": {
      "name": "Jane Smith",
      "accountNumber": "..."
    },
    "amount": 1500,
    "currency": "USDC",
    "chainId": 1
  }
}

Игнорирование Travel Rule создаёт юридические риски в ЕС (MiCA), США (FinCEN) и Великобритании.

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

Рекомендованная инфраструктура

Matching Engine ────── bare metal или dedicated VPS
                        (никаких виртуалок для latency-critical)

Market Data Service ── Kubernetes + Redis Cluster
                        (горизонтальное масштабирование подписок)

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

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

Cache ───────────────── Redis Cluster (order book state, sessions)

Queue ───────────────── Kafka (аудит лог, event sourcing)

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

Регуляторные требования для запуска

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

White-label решение без регуляторной обёртки — просто технология. Коммерческий продукт требует полного compliance стека.

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