Розробка системи управління крипто-фондом

Розробка системи управління крипто-фондом

Управління крипто-фондом — це не просто "тримати токени на гаманці". Це операційна система, яка повинна одночасно відслідковувати позиції в десятках протоколів, рахувати NAV у реальному часі, керувати ключами так щоб жодна людина не могла вивести активи поодинці, генерувати нормативну звітність і не допускати помилок де ціна помилки — втрата коштів інвесторів. Існуючі TradFi-рішення сюди не підходять: вони не розуміють on-chain активи, DeFi позиції, staking rewards, LP tokens.

Архітектура: ключові підсистеми

Управління гаманцями і ключами

Це фундамент, на якому будується все решта, і тут нема місця для компромісів.

MPC (Multi-Party Computation) — сучасний стандарт для institutional custody. На відміну від мультисиґу на рівні блокчейну, MPC-гаманець виглядає як звичайний EOA, але приватний ключ ніколи не існує в повному виді ні на одному пристрої. Key shares розподілені між учасниками (наприклад, 2-of-3: фонд + кастодіан + backup HSM). Підписання транзакції потребує спільного обчислення.

Рішення: Fireblocks (enterprise, $10k+/мес), 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 затримка для великих операцій)
    → Protocol interactions

Operations (2/3 multisig)
  → Routine rebalancing (лімітація суми per tx)
  → Gas топап гаманців

Розділення ролей критично: INVESTMENT_ROLE для стратегічних рішень (депозити в протоколи, великі своппи), OPERATIONS_ROLE для рутини (harvest rewards, compound). Кожна роль — окремий Safe або окремі сigner-сети.

HSM (Hardware Security Module) — для автоматизованих операцій (harvest, rebalance) де потрібна підпис без людини. Ключ у HSM (AWS CloudHSM, Nitro Enclaves, Thales), операції виконуються автоматично але у межах жорстко обмежених smart contract правил.

Агрегація і оцінка позицій

Крипто-фонд може мати активи в десятках форм: 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 позиції на 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
);
// + нараховані комісії

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 = сума всіх активів − зобов'язання (запозичені кошти в lending протоколах, непогашені комісії).

Проблема: ціни. Для NAV потрібні чесні ринкові ціни, стійкі до маніпуляцій.

• Chainlink Price Feeds — для основних активів. Агреговані, стійкі до flash loan атак, але latency ~1–5 хв і не всі токени покриті.
• Uniswap v3 TWAP — для токенів без Chainlink. IUniswapV3Pool.observe([1800, 0]) дає TWAP за 30 хв. Маніпуляція потребує величезного капіталу.
• CoinGecko/CoinMarketCap API — для off-chain NAV звітності. Не можна використовувати on-chain (oracle ризик), але ок для dashboard і звітності.

NAV перераховується за розписанням (кожні 5–15 хв для внутрішнього моніторингу, щодня для офіційних звітів інвесторам) і при кожній значимій операції.

Управління рисками

Health factor моніторинг — для позицій у lending протоколах. Aave: HF < 1.0 → ліквідація. Alert при HF < 1.3, автоматичне частичне погашення боргу при HF < 1.15 (якщо дозволено операційною політикою).

Concentration limits — не більше X% фонду в одному протоколі, не більше Y% в одному токені. Перевіряється при кожному rebalancing.

Liquidation price tracking — для кожної collateralized позиції розраховуємо й відображаємо ціну ліквідації. Інтеграція з ціновими alert.

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 контракти для автоматичної паузи при аномаліях.

Стек реалізації

Срок разработки MVP (custody + позиції + NAV + базовий dashboard): 4–6 місяців. Повна система з торговим виконанням, звітністю й compliance: 9–14 місяців.