Професійні звіти бектестів: метрики та дашборди

Професійні звіти бектестів: метрики та дашборди

Зібрали бектест, отримали фінальну дохідність 340% — і що далі? Без детального звіту це просто число. Ми стикалися зі стратегіями, де win rate перевищував 80%, але стратегія зливала 60% капіталу за місяць. Тому що не рахували max drawdown і не аналізували розподіл угод. Розробка звітів з бектестів під ключ — це не просто виведення цифр, а система, яка виявляє приховані ризики, порівнює гіпотези та обґрунтовує рішення. Наш досвід — понад 5 років у криптотрейдингу та DeFi — дозволяє збирати звіти, які реально використовують у роботі. Ми автоматизували розрахунки метрик, щоб ви не витрачали час на ручні ексельки. Багато трейдерів втрачають гроші, покладаючись лише на P&L — а детальний звіт з risk-adjusted метриками дозволяє уникнути цього.

Чому стандартні брокерські звіти не підходять?

Стандартні брокерські звіти дають лише P&L та simple return. Для алготрейдингу потрібні risk-adjusted метрики: Sharpe, Sortino, drawdown duration, profit factor. Без них ви не зможете зрозуміти, чи переживе стратегія ринковий шок або серію збиткових угод. Ми використовуємо pandas, plotly та власні dataclass-и (див. код нижче). Весь пайплайн автоматизований — від завантаження угод до HTML-дашборду з інтерактивними графіками. Метрика Sharpe широко використовується у фінансах (Sharpe ratio). Ми гарантуємо, що кожен звіт проходить перевірку на консистентність.

Які підводні камені приховує типовий бектест?

Одного разу клієнт прийшов зі стратегією на Binance Futures, яка показувала Sharpe 2.3. Ми запустили звіт з коректним розрахунком drawdown — і виявили чотири занурення нижче -40%. Причина — стратегія не пережила б 2-3 невдалих угод поспіль. У звіті ми додали секцію "Max drawdown duration" та "Rolling Sharpe". Клієнт переробив логіку ризик-менеджменту — і через місяць Sharpe зріс до 3.8. Наш підхід у 3 рази швидший за ручний розрахунок в Excel.

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

Ми постачаємо повний пакет:

• Інтерактивний HTML-дашборд (Plotly) з equity curve, drawdown, monthly returns heatmap, P&L distribution.
• Вихідні файли в JSON/CSV для завантаження у ваш ризик-менеджмент.
• Документація: інтерпретація кожного графіка та метрики.
• Навчання команди: як оновлювати звіт при зміні стратегії.
• Підтримка на етапі адаптації — допомагаємо інтегрувати звіт з вашим API.

Це не разова робота: ми залишаємося на зв'язку, щоб доопрацювати метрики під нові вимоги.

Склад звіту

• Дашборди: equity curve, drawdown, monthly returns heatmap, P&L distribution (на plotly або matplotlib).
• Метрики: Sharpe, Sortino, Calmar, profit factor, win rate, average win/loss, trade duration.
• JSON/CSV/HTML формати під ваш ризик-менеджмент.
• Документація: як інтерпретувати кожен графік.
• Підтримка після здачі: ми допомагаємо адаптувати звіт під нові стратегії.

Як інтерпретувати метрики?

Порівняємо типові помилки. Високий win rate не рятує, якщо середній збиток у 3 рази більший за середній прибуток. Profit Factor (валовий прибуток / валовий збиток) має бути > 2. А Sortino Ratio кращий за Sharpe — він штрафує лише від'ємну волатильність. Наша таблиця інтерпретації:

Важливо: win rate без урахування risk/reward — пастка. Profit Factor та expectancy важливіші.

Порівняння форматів звіту

Як ми будуємо звіт: покроковий процес

1. Завантаження даних — вивантаження угод з API або CSV.
2. Розрахунок метрик — обчислення Sharpe, Sortino, drawdown та інших показників.
3. Генерація графіків — equity curve, drawdown, monthly heatmap, P&L distribution.
4. Валідація — звірка з вихідними даними, перевірка консистентності.
5. Здача — HTML-дашборд + вихідні файли (JSON/CSV).

Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Замовте розробку звіту вже сьогодні та отримайте консультацію з оптимізації метрик.

from dataclasses import dataclass
from typing import Optional
import pandas as pd
import numpy as np

@dataclass
class BacktestReport:
    # Зведені метрики
    initial_capital: float
    final_capital: float
    total_return_pct: float
    annual_return_pct: float
    
    # Risk-adjusted
    sharpe_ratio: float
    sortino_ratio: float
    calmar_ratio: float
    
    # Drawdown
    max_drawdown_pct: float
    avg_drawdown_pct: float
    max_drawdown_duration_days: int
    
    # Торгівля
    total_trades: int
    win_rate: float
    profit_factor: float
    avg_win_pct: float
    avg_loss_pct: float
    best_trade_pct: float
    worst_trade_pct: float
    avg_trade_duration_hours: float
    
    # Комісії
    total_commission: float
    commission_as_pct_of_pnl: float
    
    # Часові серії
    equity_curve: pd.Series
    monthly_returns: pd.DataFrame
    trade_list: pd.DataFrame

def compute_all_metrics(equity_curve: pd.Series, trades: list[dict]) -> BacktestReport:
    returns = equity_curve.pct_change().dropna()
    annual_factor = 252

    # Базові
    total_return = (equity_curve.iloc[-1] / equity_curve.iloc[0]) - 1
    days = (equity_curve.index[-1] - equity_curve.index[0]).days
    annual_return = (1 + total_return) ** (365 / max(days, 1)) - 1

    # Sharpe (risk-free rate = 0 для крипто)
    sharpe = (returns.mean() * annual_factor) / (returns.std() * np.sqrt(annual_factor)) if returns.std() > 0 else 0

    # Sortino (лише downside volatility)
    downside = returns[returns < 0].std()
    sortino = (returns.mean() * annual_factor) / (downside * np.sqrt(annual_factor)) if downside > 0 else 0

    # Drawdown
    rolling_max = equity_curve.cummax()
    drawdown_series = (equity_curve - rolling_max) / rolling_max
    max_dd = drawdown_series.min()

    # Max drawdown duration
    in_drawdown = drawdown_series < 0
    dd_start = None
    max_duration = 0
    for date, is_dd in in_drawdown.items():
        if is_dd and dd_start is None:
            dd_start = date
        elif not is_dd and dd_start is not None:
            duration = (date - dd_start).days
            max_duration = max(max_duration, duration)
            dd_start = None

    # Calmar
    calmar = annual_return / abs(max_dd) if max_dd != 0 else 0

    # Trade-level
    trades_df = pd.DataFrame(trades)
    if not trades_df.empty:
        winning = trades_df[trades_df['pnl'] > 0]
        losing = trades_df[trades_df['pnl'] < 0]

        win_rate = len(winning) / len(trades_df)
        gross_profit = winning['pnl'].sum()
        gross_loss = abs(losing['pnl'].sum())
        profit_factor = gross_profit / gross_loss if gross_loss > 0 else float('inf')

        avg_win_pct = (winning['pnl'] / winning['entry_value'] * 100).mean() if not winning.empty else 0
        avg_loss_pct = (losing['pnl'] / losing['entry_value'] * 100).mean() if not losing.empty else 0
    else:
        win_rate = profit_factor = avg_win_pct = avg_loss_pct = 0

    return BacktestReport(
        initial_capital=equity_curve.iloc[0],
        final_capital=equity_curve.iloc[-1],
        total_return_pct=total_return * 100,
        annual_return_pct=annual_return * 100,
        sharpe_ratio=round(sharpe, 3),
        sortino_ratio=round(sortino, 3),
        calmar_ratio=round(calmar, 3),
        max_drawdown_pct=max_dd * 100,
        avg_drawdown_pct=drawdown_series[drawdown_series < 0].mean() * 100,
        max_drawdown_duration_days=max_duration,
        total_trades=len(trades),
        win_rate=win_rate,
        profit_factor=profit_factor,
        avg_win_pct=avg_win_pct,
        avg_loss_pct=avg_loss_pct,
        equity_curve=equity_curve,
        trade_list=trades_df,
    )

def compute_monthly_returns(equity_curve: pd.Series) -> pd.DataFrame:
    """Створюємо матрицю місячних дохідностей для heatmap"""
    monthly = equity_curve.resample('ME').last()
    monthly_returns = monthly.pct_change().dropna()

    # Створюємо матрицю рік × місяць
    matrix = monthly_returns.groupby([
        monthly_returns.index.year,
        monthly_returns.index.month
    ]).first().unstack()

    matrix.columns = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
                       'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
    return matrix * 100  # у відсотках

def generate_html_report(report: BacktestReport, strategy_name: str) -> str:
    import plotly.graph_objects as go
    from plotly.subplots import make_subplots

    fig = make_subplots(
        rows=3, cols=2,
        subplot_titles=['Equity Curve', 'Drawdown', 'Monthly Returns', 'Trade P&L Distribution', 'Win/Loss', 'Rolling Sharpe'],
    )

    # Equity curve
    fig.add_trace(go.Scatter(x=report.equity_curve.index, y=report.equity_curve.values,
                              name='Portfolio', line=dict(color='#00C853')), row=1, col=1)

    # Drawdown
    rolling_max = report.equity_curve.cummax()
    drawdown = (report.equity_curve - rolling_max) / rolling_max * 100
    fig.add_trace(go.Scatter(x=drawdown.index, y=drawdown.values,
                              fill='tozeroy', name='Drawdown', line=dict(color='#FF5252')), row=1, col=2)

    # P&L distribution
    if not report.trade_list.empty:
        pnl_pct = report.trade_list['pnl'] / report.trade_list['entry_value'] * 100
        fig.add_trace(go.Histogram(x=pnl_pct, name='Trade P&L %', nbinsx=30), row=2, col=1)

    fig.update_layout(
        title=f'Backtest Report: {strategy_name}',
        height=1000,
        showlegend=False,
        template='plotly_dark',
    )

    return fig.to_html(include_plotlyjs='cdn')

Розробка бірж: matching engine визначає успіх

Ми розробляємо біржі, де matching engine обробляє тисячі ордерів на секунду без затримки, маршрутизує ліквідність між пулами та гарантує, що жоден користувач не отримає доступ до чужих коштів. Команди, які починають з UI і відкладають движок «на потім», у 90% випадків переписують все через півроку. Наш досвід — 15+ запущених біржових проєктів. Оцініть ваш проєкт — отримайте консультацію.

Типові проблеми архітектури бірж

Order Book vs AMM

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

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

Як захистити DEX від MEV-атак?

Flashbots Protect дозволяє відправляти транзакції напряму в блок без публічного mempool. Commit-reveal схема робить неможливим front-running, приховуючи параметри ордера до моменту виконання. Для децентралізованих order book-бірж (на кшталт dYdX) це критично — без захисту MEV-боти викачують прибуток маркет-мейкерів. Ми реалізовували таку інтеграцію для клієнта на Arbitrum: після підключення Flashbots частка sandwich-атак знизилась з 12% до 0.2% від усіх угод.

Концентрована ліквідність та 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% і зекономило клієнту понад $5,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, великі суми — ручна авторизація.

Як будувати on-chain DEX: смарт-контракти та газ-оптимізація

Для 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 і поверненням залишку.

Як оптимізувати газ для смарт-контрактів DEX?

Оптимізація gas включає packing змінних у storage slots, використання inline assembly для критичних операцій та мінімізацію зовнішніх викликів. Правильне розміщення полів у структурі Tick.Info дозволяє зменшити gas на 20–30% порівняно з базовою реалізацією. Для 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 агрегатора.

Використовуйте LBP для створення початкового цінового діапазону, а потім підключайте агрегатори для забезпечення постійного потоку замовлень. Активне управління ліквідністю через професійні протоколи допомагає уникнути втрат від impermanent loss. Наш досвід — 15+ запущених біржових проєктів, які пройшли незалежний аудит. Середня економія клієнтів на gas-комісіях після оптимізації — $5,000 щомісяця.

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

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

Як проходить тестування смарт-контрактів?

Ми використовуємо Foundry для unit-тестів, fuzzing та invariant testing. Fork testing на mainnet дозволяє відтворити реальні умови ліквідності, що критично для верифікації поведінки контрактів.

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

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

Що входить в роботу (deliverables)

Після завершення проєкту ви отримуєте:

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

Орієнтири за строками

Вартість розраховується індивідуально після технічного брифінгу: вибір чейну, вимоги до throughput, кастодіальна модель. Сертифіковані інженери з досвідом більше 10 років допоможуть підібрати оптимальну архітектуру та не допустити типових помилок.

Зв'яжіться з нами для консультації — ми підберемо архітектуру під ваш проєкт і назвемо точні терміни. Замовте розробку біржі з гарантією якості та подальшою підтримкою.