Разработка системы расчета NAV для крипто-фонда

Формула NAV выглядит просто: (активы минус обязательства) делить на количество долей. Но для крипто-фонда каждое слагаемое — вызов. Цены активов меняются каждую секунду, часть средств заперта в DeFi-протоколах, обязательства включают начисленные комиссии, а количество долей меняется при входах и вых

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

Часто задаваемые вопросы

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

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

Формула NAV выглядит просто: (активы минус обязательства) делить на количество долей. Но для крипто-фонда каждое слагаемое — вызов. Цены активов меняются каждую секунду, часть средств заперта в DeFi-протоколах, обязательства включают начисленные комиссии, а количество долей меняется при входах и выходах инвесторов. Система, которая пересчитывает NAV раз в сутки по данным CoinGecko, не подходит для регулируемого фонда. Мы строим архитектуру, которая выдерживает аудит и работает в реальном времени. Один из наших клиентов столкнулся с ситуацией, когда из-за использования единственного источника цен его NAV расходился с реальной стоимостью портфеля на 12% — это привело к ребалансировке и потере доверия инвесторов. Мы решили эту проблему внедрением многоуровневого оракула. Опираемся на многолетний опыт: более 8 лет в блокчейн-разработке, десятки реализованных проектов для крипто-фондов.

Как выбрать источники цен для NAV?

Выбор ценового источника — методологический вопрос с техническими последствиями. Рассмотрим три категории источников:

Centralized exchange (CEX) цены: Binance, Coinbase, Kraken API дают real-time цены с задержкой < 100 мс. Проблемы: rate limits, расхождение цен между биржами, риск манипуляции на малоликвидных парах, зависимость от uptime. Для официального NAV (T-1 или T-0) используем VWAP за последние 1–4 часа по топ-3 биржам:

def calculate_vwap(trades: List[Trade], window_hours: int = 1) -> Decimal: cutoff = datetime.utcnow() - timedelta(hours=window_hours) recent = [t for t in trades if t.timestamp >= cutoff] total_volume = sum(t.volume for t in recent) if total_volume == 0: return recent[-1].price if recent else Decimal('0') return sum(t.price * t.volume for t in recent) / total_volume 

On-chain oracle цены: Chainlink Price Feeds — децентрализованные оракулы с агрегацией от профессиональных провайдеров. Обновление при отклонении > 0.5% или раз в час. Для on-chain расчёта NAV — единственный приемлемый вариант. Uniswap V3 TWAP — Time-Weighted Average Price из observation buffer, устойчив к flash loan, но уязвим к длительным манипуляциям.

Composited pricing pipeline: Для production фонда используем многоуровневую схему:

Уровень Источник Условие переключения
Primary Chainlink / CoinGecko Работает, данные свежие
Fallback 1 CEX VWAP (Binance+Coinbase+Kraken) Primary недоступен или stale
Fallback 2 On-chain TWAP (Uniswap V3, 30 мин) Fallback 1 недоступен
Stale Последняя известная цена + флаг Ручной override обязателен

Сравнение надёжности: Chainlink Oracle в 10 раз надёжнее одного биржевого API, так как агрегирует данные от множества независимых нод.

Как настроить многоуровневую схему цен? Пошаговое руководство

  1. Определите базовый актив и список вторичных активов.
  2. Подключите Chainlink Price Feeds для основных пар (ETH/USD, BTC/USD).
  3. Настройте fallback-потоки: VWAP с Binance, Coinbase, Kraken.
  4. Реализуйте on-chain TWAP для пар с низкой ликвидностью.
  5. Добавьте мониторинг staleness и механизм ручного оверрайда.
  6. Протестируйте корректность при стрессовых сценариях (внезапная волатильность, отключение биржи).

Как учитывать DeFi-позиции при расчёте NAV?

Это самая сложная часть для крипто-фонда с активной DeFi-стратегией. Активы могут быть одновременно в liquidity positions Uniswap V3, в Aave как collateral, в lending позициях (долг), в стейкинге с lock-up, в Curve/Convex как LP токены. Каждый тип требует отдельного расчётчика.

Uniswap V3 позиции

NFT с переменной стоимостью в зависимости от цены и диапазона:

async function getUniswapV3PositionValue( positionId: number, priceUSD: Record<string, number> ): Promise<number> { const position = await positionManager.positions(positionId); const pool = await getPool(position.token0, position.token1, position.fee); const { amount0, amount1 } = getAmountsForLiquidity( pool.sqrtPriceX96, getSqrtRatioAtTick(position.tickLower), getSqrtRatioAtTick(position.tickUpper), position.liquidity ); // Plus accumulated fees const { fees0, fees1 } = await collectableFees(positionId); return ( (amount0 + fees0) * priceUSD[position.token0] + (amount1 + fees1) * priceUSD[position.token1] ); } 

Aave позиции: данные через getUserAccountData возвращают totalCollateralBase, totalDebtBase, health factor. Net position = collateral - debt.

Учёт комиссий управляющего и High Water Mark

Структура типичного хедж-фонда — 2/20: 2% годовых от NAV management fee (начисляется daily), 20% performance fee от прироста выше High Water Mark (HWM). Начисленные комиссии — liability фонда и уменьшают NAV.

Тип комиссии Размер Частота начисления
Management fee 2% годовых Ежедневно (1/365)
Performance fee 20% от прироста выше HWM Ежемесячно/ежеквартально
class NAVCalculator: def calculate_daily_management_fee(self, nav: Decimal, date: date) -> Decimal: daily_rate = Decimal('0.02') / Decimal('365') return nav * daily_rate def calculate_performance_fee( self, current_nav_per_share: Decimal, high_water_mark: Decimal ) -> Decimal: if current_nav_per_share <= high_water_mark: return Decimal('0') gain_above_hwm = current_nav_per_share - high_water_mark return gain_above_hwm * Decimal('0.20') 

Почему важен Multi-Oracle подход?

Использование одного источника цен — главная причина расхождений NAV. Multi-Oracle подход снижает риск манипуляции и недоступности данных. На практике мы внедряем tripe-source pipeline, который автоматически переключается по задержкам и staleness. Это повышает надёжность до 99.9% uptime.

Как избежать ошибок при расчёте NAV?

Типичные ошибки: игнорирование накопленных комиссий, неверная оценка Uniswap V3 позиций (не учёт диапазона), отсутствие механизма ручного оверрайда при сбое оракула, неправильный учёт HWM при дроблении долей. На каждый кейс мы готовим чек-лист и автотесты.

Подписки и погашения

Вход и выход инвесторов требует атомарных операций. T+0: заявка, T+1: официальный NAV и выпуск/гашение долей. Реестр может быть on-chain (ERC-1400) или off-chain. Мы предоставляем гибкую систему с KYC/AML модулями.

Аудит и reconciliation

Ежедневный NAV должен быть воспроизводим. Все данные — цены, позиции, комиссии — сохраняются в снапшотах. Независимый администратор фонда должен иметь доступ к сырым данным. Расхождение > 0.1% требует расследования. Мы проводим формальную верификацию расчётных моделей с помощью смарт-контрактов.

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

  • Аналитика и проектирование архитектуры сбора цен и расчётов
  • Разработка data collection layer (Go) и NAV engine (Python)
  • Адаптация под вашу структуру активов (включая кастомные DeFi-протоколы)
  • Интеграция с реестром долей и бухгалтерией
  • Dashboard и reporting (React + REST)
  • Документация, обучение команды, гарантийная поддержка

Сроки и как начать

Разработка системы для фонда с 10–20 активами и базовыми DeFi-позициями — 8–12 недель. Сложные стратегии — до 16 недель. Стоимость рассчитывается индивидуально после аудита вашего портфеля. Свяжитесь с нами для консультации — мы подготовим детальное предложение. Получите оценку вашего проекта прямо сейчас: мы гарантируем прозрачную отчётность и качественное выполнение работ.