Розробка системи управління крипто-фондом
Управління крипто-фондом — це операційна система, яка одночасно відстежує позиції в десятках протоколів, рахує 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 робочих днів.







