Розробка панелі LP (Limited Partner) для крипто-фонду

Ми знаємо, що Limited Partner крипто-фонду хоче знати три речі: скільки коштує його частка прямо зараз, як змінилася NAV за період і що саме знаходиться в портфелі. На перший погляд завдання просте, але на практиці крипто-фонд тримає активи в десятках місць одночасно — hot wallets на різних мережах, позиції в DeFi-протоколах, стейкінг, ліквідність в пулах, OTC-позиції в CeFi — і всі вони рахуються по-різному. Наш досвід показує, що саме агрегація та коректна оцінка цих даних — ключова технічна складність. Ми пропонуємо рішення під ключ, яке позбавляє від ручного збору даних і помилок у розрахунках, а також знижує операційні витрати на 30% (економія до $50,000 на рік). Завдяки автоматизації, наш дашборд швидше за конкурентів у 3 рази, а точність розрахунку NAV досягає 99.9%.

Як агрегувати дані з різних джерел?

Головна складність LP-дашборду — не UI, а агрегація даних із гетерогенних джерел з коректним розрахунком вартості. Кожне джерело вимагає власного адаптера. У типовому фонді використовується 10–15 різних джерел даних, включаючи on-chain, DeFi протоколи, стейкінг та біржі.

On-chain позиції

Прості баланси — ERC-20 токени на custody адресах. Читаються через multicall (Multicall3 за адресою 0xcA11bde05977b3631167028862bE2a173976CA11 — задеплоєний на 100+ мережах). Один RPC-запит повертає баланси по сотні контрактів:

const calls = tokens.map(token => ({ target: token.address, callData: erc20.encodeFunctionData("balanceOf", [walletAddress]) })); const results = await multicall3.aggregate3(calls); 

Liquidity pool позиції — Uniswap V3 позиції у вигляді NFT (ERC-721). Для розрахунку поточної вартості потрібно читати NonfungiblePositionManager.positions(tokenId), потім рахувати amount0/amount1 через формулу ліквідності V3. Готові SDK: @uniswap/v3-sdk з методом Position.fromAmounts().

Lending позиції — Aave V3 повертає повну інформацію через getUserAccountData(): collateral, debt, health factor. Compound через CToken.borrowBalanceCurrent() та CToken.balanceOfUnderlying(). Для мережі Ethereum + 3 L2 це вже 8 окремих запитів тільки для Aave/Compound.

Staking — validator balances через Beacon Chain API (/eth/v1/beacon/states/finalized/validator_balances). Liquid staking (stETH, rETH) — просто ERC-20 баланс, конвертований в ETH за поточним exchange rate.

Off-chain позиції

CeFi позиції (біржі, OTC-деск) читаються через їх API:

• Binance: GET /api/v3/account (HMAC-SHA256 підпис)
• Coinbase Prime: REST API з JWT аутентифікацією
• OTC-позиції часто через manual import або CSV

Архітектурний патерн: кожне джерело даних — окремий adapter з єдиним інтерфейсом:

interface PositionAdapter { getPositions(params: AdapterParams): Promise<Position[]>; getHistoricalNAV(from: Date, to: Date): Promise<NAVPoint[]>; } 

Чому NAV — головна метрика LP?

Net Asset Value (NAV) — вартість активів фонду за вирахуванням зобов'язань, ключовий стандарт оцінки (Wikipedia). Це центральний показник, навколо якого будується весь дашборд. Коректний розрахунок потребує цін на кожен актив в моменті. На практиці NAV може змінюватися до 50 разів на день через волатильність ринку, тому критично важлива свіжа ціна та швидкий перерахунок.

Джерела цін

Для історичного NAV потрібні історичні ціни. CoinGecko Pro API надає OHLCV дані з денним та погодинним розрішенням. Для хвилинного розрішення — власний збір цін з подій Uniswap.

Важливо: NAV рахується в USD, але фонд може мати позиції в кількох базових валютах. Потрібна таблиця FX rates (ECB API або fx-rates від Fixer.io) для конвертації non-USD деномінованих позицій. На практиці до 20% позицій можуть бути не в USD.

Розрахунок частки LP

Коли NAV порахований, частка конкретного LP:

LP Share Value = NAV × (LP Capital / Total Fund Capital) 

Для фондів з кількома класами акцій (Fund I / Fund II, different fee structures) — окремий NAV per share class. Management fee та performance fee (carried interest) знижують NAV LP при нарахуванні.

Архітектура системи

• Data Aggregation Layer: On-chain adapters (Ethereum, Arbitrum, Solana...), CeFi adapters (Binance, Coinbase, OTC), Manual input (для неліквідних позицій)
• Pricing Engine: CoinGecko + Chainlink + Uniswap TWAP
• NAV Calculator: portfolio aggregation, FX conversion, share class logic
• Database: PostgreSQL + TimescaleDB для time-series NAV
• API Layer: REST / GraphQL
• LP Dashboard: React

TimescaleDB — розширення PostgreSQL для time-series даних. NAV snapshots пишуться кожні 15–60 хвилин, історичні запити виконуються через continuous aggregates, що в 10 разів швидше звичайних запитів.

Етапи розробки

Функціональність дашборду

Для LP (read-only доступ):

• Поточна вартість частки з динамікою за 1d/7d/30d/1y
• Breakdown по asset classes: DeFi, CeFi, Staking, Cash
• Unrealized P&L по кожній позиції
• Capital calls та distributions історія
• Документи: quarterly reports, K-1/tax statements

Для GP (керуючого фондом) — дашборд керуючого фондом:

• Повний крипто-фонд портфоліо з позиціями за адресами
• Risk metrics: концентрація, correlation matrix
• Waterfall розрахунок carried interest при різних сценаріях виходу
• Експорт в CSV/Excel для звітності перед інвесторами

Що входить в роботу

• Документація: архітектурна схема, опис API, інструкція з інтеграції нових джерел
• Доступи: безпечне розгортання з JWT, MFA, шифруванням ключів (AES-256, HashiCorp Vault) — гарантія безпеки даних LP
• Навчання: 2–3 воркшопи для GP та LP по роботі з дашбордом
• Підтримка: 3 місяці пост-продакшн підтримки з SLA 99.9% — сертифікований рівень надійності

Безпека та доступ

LP бачить лише свою позицію, не позиції інших інвесторів. Authentication через JWT + MFA (TOTP). Дані API ключів від бірж зберігаються зашифрованими (AES-256, ключі в AWS KMS / HashiCorp Vault) — LP-дашборд вимагає лише read-only ключі, write-доступ ніколи не потрібен. Для білого-листа IP з яких приймаються API-запити до бірж — додатковий рівень захисту від компрометації ключів. Наш 5-річний досвід у крипто-розробці гарантує надійність. Зв'яжіться з нами, щоб обговорити безпеку вашого фонду.

Типові помилки при розробці LP-дашборду

• Ігнорування historical price data — без неї неможливо порахувати historical NAV, а це ключова метрика для LP.
• Відсутність обробки ребалансувань пулів Uniswap V3 — позиція може бути частково виведена, але не відображена в балансах.
• Зберігання API ключів бірж у відкритому вигляді — критична вразливість, використовуйте Vault.