Разработка системы управления крипто-фондом
Управление крипто-фондом — это операционная система, которая одновременно отслеживает позиции в десятках протоколов, считает NAV в реальном времени, управляет ключами так, чтобы ни один человек не мог вывести активы единолично, генерирует регуляторную отчётность и не допускает ошибок там, где цена ошибки — потеря средств инвесторов. Один из наших клиентов столкнулся с ситуацией: его фонд держал 15% активов в LP Uniswap v3, NAV считался вручную раз в неделю, а из-за отсутствия real-time мониторинга ликвидационного риска в Aave позиция была частично ликвидирована — потери составили $80 000. После внедрения нашей системы такие инциденты исключены. Мы разрабатываем такие системы под ключ, опираясь на 5+ лет опыта в блокчейн-разработке и более 30 внедрённых проектов для фондов.
Как функционирует система управления крипто-фондом?
Система состоит из нескольких ключевых подсистем, взаимодействующих через API и очереди сообщений. Рассмотрим каждую.
Управление кошельками и ключами
Это фундамент, на котором строится всё остальное, и здесь нет места для компромиссов.
MPC (Multi-Party Computation) — современный стандарт для institutional custody. В отличие от мультисига на уровне блокчейна, MPC-кошелёк выглядит как обычный EOA, но приватный ключ никогда не существует в полном виде ни на одном устройстве. Key shares распределены между участниками (например, 2-of-3: фонд + кастодиан + backup HSM). Подписание транзакции требует совместного вычисления.
Решения: Fireblocks (enterprise), Lit Protocol (on-chain MPC, более гибко), tss-lib (Go библиотека для собственной реализации GG18/GG20 threshold signature scheme).
Gnosis Safe как multisig — проверенное решение для on-chain мультисига. Схема для фонда:
Investment Committee (3/5 multisig) → Timelock contract (24–48h delay для крупных операций) → Protocol interactions Operations (2/3 multisig) → Routine rebalancing (лимит суммы per tx) → Gas топуп кошельков Разделение ролей критично: INVESTMENT_ROLE для стратегических решений (депозиты в протоколы, крупные свопы), OPERATIONS_ROLE для рутины (harvest rewards, compound). Каждая роль — отдельный Safe или отдельные signer-сеты.
HSM (Hardware Security Module) — для автоматизированных операций (harvest, rebalance), где нужна подпись без человека. Ключ в HSM (AWS CloudHSM, Nitro Enclaves, Thales), операции выполняются автоматически, но в рамках жёстко ограниченных smart contract правил.
Почему MPC-кошелёк предпочтительнее мультисига?
MPC проще в использовании (одна транзакция вместо нескольких), дешевле по газу и не оставляет видимых следов на блокчейне. Однако мультисиг прозрачен и независим от внешних сервисов. Мы комбинируем оба подхода, рекомендовав MPC для операционной рутины, а Gnosis Safe — для крупных решений.
| Решение | Прозрачность | Стоимость газа | Зависимость от третьей стороны |
|---|---|---|---|
| MPC | Низкая | Одна tx | Высокая (Fireblocks/Lit) |
| Multisig | Высокая | N tx | Низкая (только контракт) |
| HSM | Средняя | Одна tx | Высокая (облачный провайдер) |
Агрегация и оценка позиций
Крипто-фонд может иметь активы в десятках форм: spot токены на кошельках, LP positions в Uniswap v3 (это NFT с диапазонами цен), staked позиции (stETH, rETH, cbETH), lending/borrowing в Aave или Compound (aTokens, debtTokens), vault shares (ERC-4626), locked tokens (vesting, veTokens), perpetual positions на GMX или dYdX.
Каждый тип требует отдельной логики для расчёта текущей стоимости: Uniswap v3 LP position:
// Упрощённо — реальный расчёт через TickMath и FullMath (uint160 sqrtPriceX96,,,,,,) = pool.slot0(); (uint128 liquidity,,,,) = nfpm.positions(tokenId); (amount0, amount1) = LiquidityAmounts.getAmountsForLiquidity( sqrtPriceX96, sqrtLowerX96, sqrtUpperX96, liquidity ); // + accumulated fees ERC-4626 vault:
uint256 shares = vault.balanceOf(fundAddress); uint256 underlyingValue = vault.convertToAssets(shares); Для каждого протокола нужен адаптер. Стандартизированный интерфейс адаптера:
interface ProtocolAdapter { protocol: string; // "aave-v3", "uniswap-v3", "gmx-v2" getPositions(address: string): Promise<Position[]>; } interface Position { protocol: string; type: "lending" | "lp" | "staking" | "vault" | "perp"; tokens: { address: string; amount: bigint; usdValue: number }[]; totalUsdValue: number; apy?: number; healthFactor?: number; // для lending позиций } NAV расчёт
Net Asset Value = сумма всех активов − обязательства (borrowed средства в lending протоколах, outstanding fees).
Проблема: цены. Для NAV нужны честные рыночные цены, устойчивые к манипуляциям.
- Chainlink Price Feeds — для основных активов. Aggregated, устойчивы к flash loan атакам, но latency ~1–5 мин и не все токены покрыты.
- Uniswap v3 TWAP — для токенов без Chainlink.
IUniswapV3Pool.observe([1800, 0])даёт TWAP за 30 минут. Манипуляция требует огромного капитала. - CoinGecko/CoinMarketCap API — для off-chain NAV отчётности. Нельзя использовать on-chain (оракул-риск), но ок для dashboard и reporting.
NAV пересчитывается по расписанию (каждые 5–15 минут для внутреннего мониторинга, ежедневно для официальных отчётов инвесторам) и при каждой значимой операции.
Управление рисками
Health factor мониторинг — для позиций в lending протоколах. Aave: HF < 1.0 → ликвидация. В нашем проекте с фондом на $12M мы настроили алерт при HF < 1.3 и автоматическое частичное погашение долга при HF < 1.15. Это предотвратило $320 000 потенциальных потерь за первый квартал.
Concentration limits — не более 15% фонда в одном протоколе, не более 8% в одном токене. Проверяется при каждом rebalancing.
Liquidation price tracking — для каждой collateralized позиции рассчитываем и отображаем цену ликвидации. Интеграция с ценовыми алертами.
Smart contract risk scoring — TVL протокола, возраст контракта, наличие аудита, история хаков. Интегрируем данные из DeFiLlama (TVL), DefiSafety (audit scores), Rekt.news API (hack history).
Торговое исполнение
Ручные операции через multisig — медленно для ребалансировки. Автоматизация через:
1inch / Paraswap как aggregator — лучший execution price через routing по всем DEX. API для получения котировки + данных для транзакции:
const quote = await fetch( `https://api.1inch.dev/swap/v6.0/1/swap?` + `src=${tokenIn}&dst=${tokenOut}&amount=${amount}&from=${fundAddress}&slippage=0.5` ).then(r => r.json()); // Транзакция через Safe SDK const safeTx = await safe.createTransaction({ to: quote.tx.to, data: quote.tx.data, value: quote.tx.value, }); TWAP исполнение — для крупных позиций, чтобы не двигать рынок. Дробим на N равных частей, исполняем с интервалами. Cowswap / UniswapX для MEV protection.
Бухгалтерия и отчётность
Cost basis tracking
Для налоговой отчётности нужно отслеживать себестоимость каждой позиции. Методы: FIFO, LIFO, HIFO, Specific Identification. Каждый своп, получение reward, добавление ликвидности — это налоговое событие в большинстве юрисдикций.
Особая сложность: LP fees и staking rewards — это обычно income в момент получения (harvest), не capital gain. Системе нужно различать эти типы событий.
Инвесторские отчёты
- Daily NAV + изменение vs. benchmarks (BTC, ETH, DeFi Pulse Index)
- Monthly P&L по каждому протоколу и стратегии
- Capital calls и distributions
- Auditor-ready trial balance с полной цепочкой on-chain доказательств
Безопасность и операционные процедуры
Transaction simulation перед каждым исполнением — Tenderly или forked mainnet. Никакая транзакция не отправляется без предварительной симуляции и проверки ожидаемого результата.
Allowance management — approve только на конкретную транзакцию или использовать increaseAllowance с минимальными суммами. Регулярный ревью существующих approvals через Revoke.cash API.
Emergency procedures — задокументированный runbook: как действовать при компрометации ключа, при ликвидационном риске, при обнаруженном hack в используемом протоколе. Safe Guard контракты для автоматической паузы при аномалиях.
Что входит в разработку системы
- Аудит текущих бизнес-процессов и выбор архитектуры
- Разработка смарт-контрактов (Gnosis Safe, timelock, адаптеры)
- Бэкенд для агрегации позиций, расчёта NAV, рисков
- Фронтенд dashboard с real-time данными
- Интеграция с биржами, агрегаторами, протоколами DeFi
- Настройка мониторинга и алертов (Prometheus + Grafana + PagerDuty)
- Документация, обучение команды и техническая поддержка 3 месяца после запуска
| Этап | Содержание | Ориентировочный срок |
|---|---|---|
| Аналитика | Интервью, описание процессов, выбор стека | 2–3 недели |
| Проектирование | Архитектура, ERD, API спецификации | 3–4 недели |
| Разработка MVP | Custody + позиции + NAV + dashboard | 4–6 месяцев |
| Полная система | + торговля, отчётность, compliance | 9–14 месяцев |
| Тестирование и деплой | Симуляции, аудит, развёртывание | 1–2 месяца |
Сроки варьируются в зависимости от сложности интеграций и требований к автоматизации. Стоимость рассчитывается индивидуально после анализа проекта.
Оценим ваш проект — свяжитесь с нами для консультации. Мы гарантируем безопасность и соответствие лучшим практикам institutional custody. Получите детальное коммерческое предложение в течение 2 рабочих дней.







