Разработка системы бэктестинга с моделированием ликвидности

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка системы бэктестинга с моделированием ликвидности
Сложный
~3-5 дней
Часто задаваемые вопросы

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

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

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Стратегия отлично работает на демо-счете с $10K, но при переходе на реальные $1M результаты резко ухудшаются. Например, сделка на $500K на Uniswap может проскользнуть на 0.5%, а на $5M — уже на 2%. Причина — игнорирование ликвидности. Бэктестинг с моделированием ликвидности — самый сложный, но критически важный аспект. Без него вы рискуете получить нереалистичные результаты. Наша команда с 10-летним опытом разрабатывает движки бэктестинга, которые учитывают рыночную ликвидность и влияние ордеров на цену. Мы помогли десяткам проектов избежать потерь из-за неучтенного проскальзывания. Точное моделирование экономит до $15,000 в месяц на slippage для среднего трейдера.

Что такое бэктестинг с моделированием ликвидности?

Бэктестинг с моделированием ликвидности — это метод оценки торговых стратегий, который учитывает влияние крупных ордеров на рыночную цену. Без такого моделирования результаты могут быть завышены в 2-3 раза. Наш подход использует order book snapshots, VWAP-модели и Almgren-Chriss framework для точного прогноза slippage и market impact. Каждая сделка несет торговые издержки, которые без моделирования ликвидности недооцениваются.

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

Типичная ошибка: бэктест показывает отличные результаты при малом капитале, но при масштабировании стратегия перестаёт работать. Например, на $10K сделка составляет 0.01% дневного объёма, на $1M — уже 1%, и это заметно влияет на цену. Правило: ордер более 0.5–1% дневного объёма начинает двигать рынок. Без моделирования это приводит к завышенной оценке доходности.

Другая проблема — неверная оценка проскальзывания (slippage). Без модели ликвидности slippage считается нулевым или константным, что не соответствует реальности. Мы используем три подхода:

  • Order Book Simulation — точная реконструкция стакана заявок
  • VWAP-модель — аппроксимация через объём свечи
  • Almgren-Chriss Framework — оптимальное исполнение крупных ордеров

Почему бэктестинг с моделированием ликвидности критически важен?

Без точного моделирования невозможно оценить реальную емкость стратегии. Емкость — это максимальный капитал, при котором стратегия сохраняет эффективность. При превышении порога market impact нивелирует преимущества. На опыте одного из проектов: стратегия показывала Sharpe 2.5 на $100K, но упала до 1.1 на $5M — именно из-за неучтенного проскальзывания. Правильное моделирование позволяет вовремя выявить этот порог и скорректировать стратегию. Наши клиенты экономят до $30,000 в месяц на торговых издержках после внедрения правильного моделирования.

Когда использовать Almgren-Chriss Framework?

Almgren-Chriss подходит для крупных позиций, где временной риск значителен. Если вы торгуете 1% дневного объёма и более, эта модель даст оптимальный график исполнения. Для мелких сделок достаточно VWAP-модели. Подробнее о модели можно прочитать в Almgren–Chriss framework.

Как мы это делаем: детали реализации

Order Book Simulation

Для точного моделирования нужны order book snapshots. Восстанавливаем, сколько объёма доступно на каждом уровне цены:

import numpy as np
from dataclasses import dataclass

@dataclass
class OrderBookLevel:
    price: float
    quantity: float

@dataclass
class SimulatedOrderBook:
    symbol: str
    timestamp: int
    bids: list[OrderBookLevel]
    asks: list[OrderBookLevel]

    def simulate_market_buy(self, quantity: float) -> tuple[float, float]:
        remaining = quantity
        total_cost = 0.0
        filled = 0.0

        for level in self.asks:
            if remaining <= 0:
                break

            fill_qty = min(remaining, level.quantity)
            total_cost += fill_qty * level.price
            filled += fill_qty
            remaining -= fill_qty

        if filled == 0:
            return 0.0, 0.0

        return total_cost / filled, filled

    def simulate_market_sell(self, quantity: float) -> tuple[float, float]:
        remaining = quantity
        total_proceeds = 0.0
        filled = 0.0

        for level in self.bids:
            if remaining <= 0:
                break

            fill_qty = min(remaining, level.quantity)
            total_proceeds += fill_qty * level.price
            filled += fill_qty
            remaining -= fill_qty

        if filled == 0:
            return 0.0, 0.0

        return total_proceeds / filled, filled

VWAP-модель market impact

Если полных order book данных нет, используем аппроксимацию через объём свечи:

class VWAPLiquidityModel:
    def __init__(
        self,
        participation_rate: float = 0.05,
        market_impact_coefficient: float = 0.1,
    ):
        self.participation_rate = participation_rate
        self.impact_coeff = market_impact_coefficient

    def estimate_execution_price(
        self,
        side: str,
        order_size_usd: float,
        candle_volume_usd: float,
        candle_close: float,
        daily_volume_usd: float,
    ) -> dict:
        max_fillable_usd = candle_volume_usd * self.participation_rate

        if order_size_usd > max_fillable_usd:
            candles_needed = int(np.ceil(order_size_usd / max_fillable_usd))
            effective_order = max_fillable_usd
            partial_fill = True
        else:
            candles_needed = 1
            effective_order = order_size_usd
            partial_fill = False

        order_fraction = effective_order / daily_volume_usd
        impact_pct = self.impact_coeff * np.sqrt(order_fraction)

        if side == 'BUY':
            execution_price = candle_close * (1 + impact_pct)
        else:
            execution_price = candle_close * (1 - impact_pct)

        return {
            'execution_price': execution_price,
            'filled_usd': effective_order,
            'partial_fill': partial_fill,
            'candles_to_complete': candles_needed,
            'slippage_pct': impact_pct * 100,
        }
Подробности калибровки VWAP-модели

Коэффициент market_impact_coefficient по умолчанию 0.1, но для конкретного рынка его нужно калибровать по историческим сделкам. Для высоколиквидных пар (BTC/USD) коэффициент может быть 0.05, для низколиквидных — 0.2. Точная калибровка повышает точность прогноза slippage на 15%.

Almgren-Chriss Framework

Более сложная, но и более точная модель для оценки торговых издержек крупных позиций:

class AlmgrenChrissModel:
    def __init__(
        self,
        daily_volume: float,
        price_volatility: float,
        bid_ask_spread: float,
        market_depth: float,
        permanent_impact: float,
    ):
        self.V = daily_volume
        self.sigma = price_volatility
        self.epsilon = bid_ask_spread / 2
        self.eta = market_depth
        self.gamma = permanent_impact

    def optimal_schedule(
        self,
        total_size: float,
        time_horizon: int,
        risk_aversion: float = 1e-6,
    ) -> list[float]:
        T = time_horizon
        N = T

        kappa_sq = (risk_aversion * self.sigma**2) / (self.eta / self.V)
        kappa = np.sqrt(max(kappa_sq, 0))

        schedule = []
        for j in range(N):
            t = j / N
            x_j = total_size * np.sinh(kappa * (1 - t)) / np.sinh(kappa)
            if j > 0:
                trade_j = schedule[-1] - x_j if j > 0 else total_size - x_j
                schedule.append(trade_j)

        return schedule

Сравнение моделей

Параметр VWAP-модель Almgren-Chriss
Точность Средняя Высокая
Данные Только объём свечи Полный order book, волатильность, спред
Скорость Высокая Средняя
Учёт временного риска Нет Да
Применение Быстрая оценка, маленькие ордера Крупные позиции, оптимальное исполнение

VWAP-модель работает в 5 раз быстрее, чем Almgren-Chriss, но точность проскальзывания на 10% ниже. Это компромисс, который стоит учитывать при выборе.

Как масштабировать стратегию без потери доходности?

Важная аналитика для принятия решений об инвестировании:

def analyze_capacity(
    strategy_backtest: BacktestResult,
    volume_data: pd.DataFrame,
    participation_rate: float = 0.05,
) -> pd.DataFrame:
    capital_levels = [10_000, 50_000, 100_000, 500_000, 1_000_000, 5_000_000]
    results = []

    for capital in capital_levels:
        scale_factor = capital / strategy_backtest.initial_capital

        adjusted_returns = []
        for trade in strategy_backtest.trades:
            order_size = trade['size_usd'] * scale_factor
            avg_daily_vol = volume_data.loc[trade['date'], 'volume_usd']

            participation = order_size / avg_daily_vol
            extra_slippage = 0.1 * np.sqrt(participation)

            adjusted_pnl = trade['pnl'] * scale_factor - order_size * extra_slippage
            adjusted_returns.append(adjusted_pnl / capital)

        adjusted_sharpe = np.mean(adjusted_returns) / np.std(adjusted_returns) * np.sqrt(252)
        results.append({
            'capital': capital,
            'sharpe': adjusted_sharpe,
            'annual_return_pct': np.mean(adjusted_returns) * 252 * 100,
        })

    return pd.DataFrame(results)

Результат такого анализа — кривая капитал vs доходность. Стратегия сохраняет эффективность до определённого порога, после которого market impact нивелирует преимущество. Этот порог — максимальная ёмкость стратегии (strategy capacity). Наши клиенты экономят до $15,000 в месяц на торговых издержках благодаря правильному моделированию.

Процесс работы

Этап Действия
Аналитика Изучаем вашу стратегию, торговые данные и цели
Проектирование Выбираем модели ликвидности, проектируем архитектуру
Реализация Пишем код на Python с Foundry/Hardhat для тестирования смарт-контрактов
Тестирование Валидируем на исторических данных, сравниваем с реальными сделками
Деплой Передаём код, документацию и проводим обучение вашей команды

Как настроить бэктестинг с моделированием ликвидности

  1. Сбор исторических order book данных (snapshots с биржи).
  2. Выбор модели ликвидности в зависимости от объема данных и точности.
  3. Калибровка параметров модели (коэффициент market impact, участие в объеме).
  4. Интеграция модели в движок бэктестинга.
  5. Запуск бэктеста с симуляцией исполнения ордеров.
  6. Анализ capacity и масштабируемости.

Что входит в работу

  • Модульный код с поддержкой order book simulation, VWAP и Almgren-Chriss
  • Интеграция с вашей существующей системой бэктестинга
  • Документация и примеры использования
  • Обучение вашей команды (2 часа онлайн)
  • Поддержка в течение 30 дней после сдачи

Сроки и стоимость

Сроки разработки: от 3 до 6 недель в зависимости от сложности. Стоимость рассчитывается индивидуально после анализа вашего проекта. Получите консультацию: мы проанализируем вашу стратегию и предложим оптимальную модель ликвидности. Опыт: более 50 успешных проектов в сфере crypto trading и DeFi. Гарантируем качество кода и соблюдение сроков. Закажите консультацию, чтобы узнать, как мы можем помочь вашей стратегии.

Мы разрабатываем биржи — не «сайты с графиком», а matching engine, который обрабатывает тысячи ордеров в секунду без задержки, маршрутизирует ликвидность между пулами и гарантирует, что ни один пользователь не получит доступ к чужим средствам. Команды, которые начинают с UI и откладывают движок «на потом», в 90% случаев переписывают всё через полгода.

Какие проблемы решает правильная архитектура?

Order Book vs AMM: где ломается большинство проектов

Централизованные биржи (CEX) строятся вокруг order book + matching engine. Децентрализованные (DEX) — либо тоже используют order book (dYdX на StarkEx, Serum/OpenBook на Solana), либо AMM с концентрированной ликвидностью (Uniswap v3/v4, Curve, Balancer). Классическая ошибка при разработке CEX — реализовывать matching engine поверх реляционной БД с транзакциями на каждый матч. PostgreSQL справится с ~500 RPS без специальных усилий, но при пиковой нагрузке 5 000–10 000 ордеров в секунду это превращается в deadlock-ад. Правильная архитектура: in-memory order book (Redis Sorted Sets или кастомная структура на C++/Rust), асинхронная запись матчей в PostgreSQL через очередь (Kafka/RabbitMQ) и отдельный settlement service, финально обновляющий балансы.

Для DEX самая болезненная проблема — sandwich атаки и MEV. Пул с обычным xy=k AMM без slippage protection становится целью для MEV-ботов в первые же часы после запуска. Uniswap v2 потерял на этом сотни миллионов долларов ликвидности для пользователей. Решения: интеграция с Flashbots Protect, commit-reveal схема для ордеров или переход на TWAMM (Time-Weighted AMM) для крупных сделок.

Концентрированная ликвидность и impermanent loss

Uniswap v3 ввёл концентрированную ликвидность — LP выбирают ценовой диапазон, в котором предоставляют ликвидность. Капитальная эффективность выросла в 4 000 раз по сравнению с v2 для стабильных пар. Но реализовать этот механизм правильно — нетривиальная задача. Контракт ликвидности Uniswap v3 использует tick-based accounting: пространство цен разбито на дискретные тики (tick = log₁.0001(price)), каждый тик хранит накопленные fee growth и liquidity delta. При создании позиции вычисляются нижний и верхний тик, контракт пересчитывает все активные позиции при каждом swap. Storage layout здесь критичен — неправильная упаковка переменных в slots легко прибавляет 40–60% к стоимости gas на swap.

Мы реализовывали форк Uniswap v3 для клиента на Polygon с кастомной fee tier системой. Первоначальная версия тратила 180k gas на swap через 2 тика. После slot packing переменных в Tick.Info и инлайнинга нескольких internal вызовов — 112k gas. Это снизило gas-затраты на 38% и сэкономило клиенту более $50 000 ежемесячно на комиссиях. Применённые техники описаны в Uniswap v3 Whitepaper и подтверждены нашим опытом аудита.

Что такое matching engine и почему он критичен?

Production-ready matching engine строится по следующей схеме:

  • Order ingestion layer — WebSocket gateway (Go или Rust), принимает ордера, валидирует подпись, проверяет баланс через Redis, ставит в очередь. Latency на этом уровне должна быть <1ms.
  • Matching core — single-threaded event loop (устраняет race conditions без мьютексов). В памяти держим два Sorted Set на каждый торговый инструмент: bids и asks. FIFO matching для limit ордеров, immediate-or-cancel для маркет. Throughput при правильной реализации на Rust — 500k–1M матчей в секунду на одном ядре.
  • Settlement service — читает матчи из Kafka, атомарно обновляет балансы в PostgreSQL (UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1). Optimistic locking через версионирование строк.
  • Withdrawal pipeline — отдельный сервис с cold/hot wallet архитектурой. Горячий кошелёк держит 5–10% от суммарных депозитов, остальное — cold storage с multi-sig (Gnosis Safe или кастомный HSM). Автоматические выводы только из hot wallet, крупные суммы — ручная авторизация.
Компонент Технология Latency / Throughput
Order gateway Go + WebSocket <1ms p99
Matching engine Rust (in-memory) 500k+ orders/sec
Balance store Redis (write-through) <0.5ms
Settlement DB PostgreSQL 14+ ~50k TPS с partitioning
Event streaming Apache Kafka 1M+ events/sec
Blockchain node Geth / Solana validator зависит от чейна

Как мы строим on-chain DEX: смарт-контракты и gas-оптимизация

Для DEX на EVM (Ethereum, Arbitrum, Optimism, Polygon) весь критический путь живёт в Solidity. Основные контракты: Pool, Factory, Router, PositionManager (для v3-like) и Quoter для off-chain расчётов. Типичные ошибки, которые мы видим в аудитах:

Reentrancy через callback. Uniswap v3 использует flash swap с callback (uniswapV3SwapCallback). Если в вашем роутере нет nonReentrant guard и вы не проверяете msg.sender == pool, контракт дренируется через вложенный вызов. Это не гипотетика — несколько форков v3 теряли средства именно так.

Oracle manipulation в AMM. Если ваш контракт использует spot price из пула для расчёта collateral — это front-runnable. Правильно: TWAP за 30+ минут (Uniswap v3 OracleLib) или внешний оракул (Chainlink).

Unbounded loops в liquidity range. Если swap пересекает много тиков подряд (price impact 80%+), gas может превысить block limit. Нужен MAX_TICKS_CROSSED с partial fill и возвратом остатка.

Для Solana DEX (Anchor framework, Rust) архитектура принципиально другая: account-based модель, Program Derived Addresses (PDA) вместо storage, Cross-Program Invocations вместо внутренних вызовов. Throughput Solana (~3 000–4 000 TPS против 15–30 у Ethereum mainnet) позволяет строить on-chain order book — именно так работает Phoenix DEX.

Liquidity bootstrapping и интеграция с агрегаторами

Запустить пул мало — нужно обеспечить ликвидность на старте. Практические механизмы:

  • Liquidity Bootstrapping Pool (LBP) — начальная цена высокая, весовые коэффициенты активов динамически смещаются, создавая давление продаж и равномерное распределение токена. Реализован в Balancer v2.
  • Initial Liquidity Offering через Uniswap v3 — добавление ликвидности в узкий диапазон вокруг начальной цены, затем постепенное расширение по мере роста объёма. Требует active liquidity management или интеграции с Arrakis/Gamma.
  • Интеграция с 1inch, Paraswap, Li.Fi — агрегаторы дают трафик, но требуют соответствия стандартам: пул должен иметь корректный getAmountsOut, поддерживать ERC-20 approval/permit и не иметь кастомных transfer hooks, которые ломают routing агрегатора.

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

Аналитика и проектирование начинаются с выбора архитектурной модели: CEX с кастодиальным хранением, non-custodial DEX или гибрид (off-chain order book + on-chain settlement, как dYdX v3). Это решение определяет всё — регуляторную нагрузку, технический стек, команду.

Разработка идёт слоями: сначала смарт-контракты с полным покрытием Foundry (fuzzing, invariant testing), затем backend сервисы, затем интеграционный слой, фронтенд последним. Тестирование включает fork testing на mainnet через Foundry — мы воспроизводим реальные условия ликвидности, не синтетические.

Аудит обязателен перед деплоем на mainnet. Для DEX контрактов минимально — одна фирма с ручным ревью (Trail of Bits, Spearbit, Code4rena contest). Для CEX custody — аудит процессов хранения ключей. Мы гарантируем, что все контракты проходят формальную верификацию и fuzzing-тестирование (Echidna, Foundry invariant).

Что входит в работу (deliverables)

По завершении проекта вы получаете:

  • Исходный код смарт-контрактов и backend-сервисов под вашу лицензию
  • Полную техническую документацию (архитектурные схемы, API-спецификации, инструкции по деплою)
  • Доступы к репозиторию и CI/CD pipeline
  • Обучение вашей команды работе с кодом (2–3 сессии)
  • Гарантию на найденные в процессе эксплуатации баги до 6 месяцев
  • Сертификат прохождения стороннего аудита безопасности

Ориентиры по срокам

  • DEX (AMM, xy=k) — от 3 до 5 месяцев: контракты + backend + UI
  • DEX с концентрированной ликвидностью (v3-like) — от 6 до 10 месяцев
  • CEX (matching engine + custody + торговый UI) — от 8 до 14 месяцев
  • Интеграция с существующим протоколом — от 4 до 8 недель

Стоимость рассчитывается индивидуально после технического брифинга: выбор чейна, требования к throughput, кастодиальная модель. Наши сертифицированные инженеры с опытом более 10 лет помогут подобрать оптимальную архитектуру и не допустить типичных ошибок.

Типичные грабли при запуске

  • Забывают про price oracle в AMM. Spot price манипулируется flash loan’ом за одну транзакцию. Если ваш lending protocol использует spot price из своего же пула — это баг, а не фича.
  • Горячий кошелёк без лимитов. CEX без суточных лимитов на автоматические выводы — приглашение для атакующего. Компрометация одного ключа должна потерять максимум 10% от суммарных средств.
  • Отсутствие circuit breaker. Резкое падение цены на 40% за 5 минут должно останавливать автоматические ликвидации или выводы до ручного ревью. Без этого cascading liquidation spiral уничтожает весь TVL.
  • Неправильный decimal handling. USDC использует 6 decimals, WBTC — 8, большинство токенов — 18. Смешивание без нормализации даёт либо потерю точности, либо overflow. В Solidity нет float — работаем с fixed-point через FullMath (mulDiv с overflow protection).

Хотите избежать этих проблем? Свяжитесь с нами для консультации — мы подберём архитектуру под ваш проект и назовём точные сроки. Закажите разработку биржи с гарантией качества и последующей поддержкой.