Разработка системы Monte Carlo симуляции портфеля
Криптопортфель может потерять 30% за год — стандартные метрики волатильность, бета, Sharpe ratio не дают вероятностной оценки. Monte Carlo симуляция генерирует тысячи сценариев и показывает полное распределение исходов. Мы, инженеры с 8+ годами опыта в блокчейн-разработке и 30+ реализованными проектами по риск-анализу, строим такие системы под ключ: от выбора модели (GBM, t-распределение, GARCH) до интерактивного дашборда.
Инвестиции в систему окупаются: типичная экономия на ребалансировке составляет 20–40% годовых. Средняя доходность портфеля после внедрения повышается на 5–10% годовых.
Как Monte Carlo симуляция помогает оценить риск криптопортфеля?
Вместо «портфель вырастет на X%» мы получаем: «с вероятностью 70% портфель вырастет на 20–80%, с вероятностью 15% потеряет 10–30%». Это достигается моделированием ценовых траекторий на основе статистических свойств рыночных данных. В основе — Geometric Brownian Motion (GBM), но для крипты требуется модификация из-за fat tails и кластеризации волатильности.
import numpy as np
def simulate_gbm(initial_price, mu, sigma, days, n_simulations=10000):
"""
mu: среднедневная доходность
sigma: среднедневная волатильность
"""
dt = 1
random_returns = np.random.normal(
mu * dt,
sigma * np.sqrt(dt),
(n_simulations, days)
)
cumulative = np.cumprod(1 + random_returns, axis=1)
price_paths = initial_price * cumulative
return price_paths
Мультиактивная симуляция с корреляциями
Для портфеля важно учитывать корреляции между активами:
from numpy.linalg import cholesky
def simulate_correlated_portfolio(initial_prices, means, cov_matrix,
days=365, n_sims=10000):
n_assets = len(initial_prices)
symbols = list(initial_prices.keys())
L = cholesky(cov_matrix)
portfolio_paths = []
for _ in range(n_sims):
z = np.random.standard_normal((days, n_assets))
correlated_returns = z @ L.T
daily_means = np.array([means[s] for s in symbols])
actual_returns = correlated_returns + daily_means
prices = np.zeros((days + 1, n_assets))
prices[0] = [initial_prices[s] for s in symbols]
for t in range(1, days + 1):
prices[t] = prices[t-1] * (1 + actual_returns[t-1])
weights = np.ones(n_assets) / n_assets
portfolio_value = (prices * weights).sum(axis=1)
portfolio_paths.append(portfolio_value)
return np.array(portfolio_paths)
Улучшенные модели returns
GBM предполагает нормальное распределение returns. Для крипты это неверно — есть fat tails и кластеризация волатильности.
| Модель |
Допущения |
Применимость для крипты |
Точность прогноза |
| GBM |
Нормальное распределение, const volatility |
Низкая из-за fat tails |
Удовлетворительная только на коротких окнах |
| Student's t |
Fat tails, const volatility |
Средняя, лучше GBM |
Выше GBM, но не учитывает изменчивость волатильности |
| GARCH(1,1) |
Условно нормальное, time-varying volatility |
Высокая |
Наилучшая для крипты среди классических моделей |
GARCH model
Student's t-distribution для fat tails:
from scipy.stats import t as t_dist
def simulate_fat_tail(mu, sigma, df, n_sims, days):
returns = t_dist.rvs(df=df, loc=mu, scale=sigma, size=(n_sims, days))
return np.cumprod(1 + returns, axis=1)
GARCH(1,1) conditional volatility:
from arch import arch_model
def fit_garch_and_simulate(returns_history, n_sims=10000, horizon=252):
model = arch_model(returns_history * 100, vol='GARCH', p=1, q=1)
result = model.fit(disp='off')
simulations = result.forecast(horizon=horizon, method='simulation',
simulations=n_sims)
return simulations.simulations.values
Почему GARCH-модель точнее GBM для крипты?
GBM предполагает, что волатильность постоянна, но на крипторынке периоды высокой волатильности сменяются затишьем. GARCH динамически адаптируется, что критически важно для оценки VaR 95% и просадок. Мы используем GARCH(1,1) как базовую модель, а для более экстремальных хвостов — комбинацию GARCH с t-распределением.
Анализ результатов симуляции
Пример расчёта VaR
```python
def analyze_simulation_results(portfolio_paths, initial_value,
confidence_levels=[0.05, 0.25, 0.50, 0.75, 0.95]):
final_values = portfolio_paths[:, -1]
percentiles = {f'p{int(c*100)}': np.percentile(final_values, c*100)
for c in confidence_levels}
prob_loss = (final_values < initial_value).mean()
returns = (final_values - initial_value) / initial_value
var_95 = np.percentile(final_values - initial_value, 5)
cvar_95 = (final_values - initial_value)[
final_values - initial_value <= var_95
].mean()
max_drawdowns = []
for path in portfolio_paths:
peaks = np.maximum.accumulate(path)
drawdowns = (peaks - path) / peaks
max_drawdowns.append(drawdowns.max())
return {
'percentiles': percentiles,
'prob_loss': prob_loss,
'expected_return': returns.mean(),
'return_std': returns.std(),
'var_95': var_95,
'cvar_95': cvar_95,
'avg_max_drawdown': np.mean(max_drawdowns),
'worst_max_drawdown': np.max(max_drawdowns)
}
```
Выходные метрики включают перцентили, вероятность убытка, ожидаемую доходность, VaR 95%, CVaR 95% и распределение максимальной просадки. Например, при 10 000 симуляциях на 252 дня, VaR 95% может составлять -15% от начального капитала.
| Метрика |
Описание |
Пример |
| VaR 95% |
Худшие 5% сценариев |
-15,2% |
| CVaR 95% |
Средний убыток в худших 5% |
-22,1% |
| Prob loss |
Вероятность убытка |
34,5% |
| Avg max drawdown |
Средняя макс просадка |
-28,3% |
Visualisation результатов
Fan chart показывает диапазон возможных траекторий портфеля. Центральная линия — медиана (50-й перцентиль). Более тёмные зоны — вероятные диапазоны (25–75%), светлее — редкие (5–95%). Return distribution histogram и drawdown distribution дополняют анализ.
Применения в управлении портфелем
- Вероятность достижения цели: вычислить, с какой вероятностью портфель вырастет на 50% за год при текущей стратегии.
- Сравнение стратегий: запустить симуляцию для двух стратегий, сравнить распределения outcomes.
- Optimal rebalancing frequency: симулировать портфель с разными частотами ребалансировки, выбрать оптимальную.
- Capital allocation: сколько выделить на рискованную vs консервативную стратегию для достижения target при допустимом риске.
Технический стек
Python (numpy, scipy, arch для GARCH), Numba для ускорения симуляций (JIT компиляция даёт 10–50x ускорение), pandas для обработки данных, matplotlib/plotly для визуализации fan charts. 10,000 симуляций на 252 дня занимают < 1 секунды с Numba.
Процесс работы
- Сбор исторических данных за 2–3 года (OHLCV) с использованием CCXT или CoinGecko API.
- Калибровка модели: оценка параметров GBM, t-распределения или GARCH(1,1) по дневным доходностям.
- Симуляция 10 000–50 000 траекторий с учётом корреляционной матрицы активов.
- Расчёт метрик риска: VaR, CVaR, максимальная просадка, вероятность убытка.
- Построение интерактивного дашборда на Plotly/Dash с fan chart и гистограммами.
- Интеграция с вашим бэкендом через REST API или WebSocket для ежедневного обновления.
Что входит в разработку
- Код на Python с комментариями и документацией
- Выбор и калибровка модели (GBM, t-student, GARCH) под ваш портфель
- Тестирование на исторических данных (backtesting)
- Интеграция с вашим бэкендом (REST API или WebSocket)
- Интерактивный дашборд на Plotly/Dash
- Обучение команды и документация
Свяжитесь с нами, чтобы обсудить ваш кейс. Получите консультацию по выбору модели и расчёт стоимости за 1 день. Закажите разработку системы под ключ — мы гарантируем точность и надёжность внедрения.
Мы разрабатываем биржи — не «сайты с графиком», а 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).
Хотите избежать этих проблем? Свяжитесь с нами для консультации — мы подберём архитектуру под ваш проект и назовём точные сроки. Закажите разработку биржи с гарантией качества и последующей поддержкой.
