Інфраструктура крипто-фонду: смарт-контракти, NAV та ключі

Розробка інфраструктури крипто-фонду — завдання, яке виходить далеко за рамки простого мультисига та торгового акаунту. Щодня ми стикаємося з необхідністю організувати прозорий і аудитований процес: розрахунок NAV у реальному часі, ізоляція активів LP, автоматичне виконання redemption. Наприклад, нещодавній проєкт: фонд з AUM $50M вимагав інтеграції 15 різних джерел цін. Без правильного NAV oracle та circuit breaker маніпуляції ціною могли призвести до втрати $2M за одну транзакцію. Ми впровадили TWAP-агрегатор та захист від flash loan атак, знизивши ризик до нуля. Наша команда з 7+ роками досвіду в Web3 вирішує ці завдання так, щоб інвестори могли спати спокійно. За 7 років ми реалізували 50+ проєктів для фондів з AUM від $10M до $500M. Гарантуємо прозорість та безпеку на всіх рівнях — від смарт-контрактів для фонду до off-chain сервісів. Зниження витрат на управління фондом досягає 30% за рахунок автоматизації NAV calculator та performance fee розрахунку. Економія на комісіях за транзакції — до 40% завдяки оптимізації gas та вибору L2. Зв'яжіться з нами, щоб обговорити ваше завдання.

Як влаштований Vault-контракт для обліку часток LP?

Типовий крипто-фонд складається з кількох технічних шарів: On-chain шар (смарт-контракти):

• Vault-контракт (вальт контракт) — зберігання активів, облік часток LP
• NAV oracle — подача актуальної вартості активів
• Subscription/Redemption контракт — управління входом/виходом LP
• Fee module — розрахунок та збір management fee та performance fee

Off-chain шар:

• NAV calculator — агрегація цін, розрахунок вартості портфеля
• Trade execution engine — виконання ордерів через CEX/DEX
• Reporting pipeline — звітність для LP та регуляторів
• Risk monitoring — моніторинг позицій, drawdown, exposure

Операційний шар:

• Multi-sig для управління — Gnosis Safe з політиками підписантів
• Key management — hardware security modules (HSM) або MPC-гаманці
• Audit trail — незмінний лог всіх операцій

Стандарт EIP-4626 — відправна точка для більшості on-chain фондів. Визначає інтерфейс deposit/withdraw/mint/redeem з ERC-20 shares:

// Упрощённая структура vault contract FundVault is ERC4626, AccessControl { bytes32 public constant MANAGER_ROLE = keccak256("MANAGER_ROLE"); bytes32 public constant NAV_ORACLE_ROLE = keccak256("NAV_ORACLE_ROLE"); uint256 private _reportedNavPerShare; // NAV на share, обновляется oracle uint256 public lastNavUpdate; uint256 public constant NAV_STALENESS_THRESHOLD = 24 hours; // Переопределяем totalAssets() для учёта off-chain активов function totalAssets() public view override returns (uint256) { require( block.timestamp - lastNavUpdate <= NAV_STALENESS_THRESHOLD, "NAV is stale" ); return _reportedNavPerShare * totalSupply() / 1e18; } // NAV oracle обновляет стоимость портфеля function updateNAV(uint256 newNavPerShare) external onlyRole(NAV_ORACLE_ROLE) { require(newNavPerShare > 0, "Invalid NAV"); _reportedNavPerShare = newNavPerShare; lastNavUpdate = block.timestamp; emit NAVUpdated(newNavPerShare, block.timestamp); } } 

Ключова складність: totalAssets() в EIP-4626 передбачає активи всередині контракту. Для фонду з позиціями на CEX, в DeFi-протоколах, в BTC — активи розподілені. NAV oracle повинен агрегувати всі джерела та подавати єдине значення on-chain.

Subscription та Redemption: управління ліквідністю

Простий deposit/withdraw з EIP-4626 не працює для фонду з періодичними вікнами ліквідності. Реальна схема:

Subscription queue. LP подає subscribeRequest(amount) + переказує USDC. Запит поміщається в чергу. В кінці періоду (наприклад, щотижня) менеджер обробляє чергу: розраховує shares за актуальним NAV, мінтить їх LP.

Redemption queue. Аналогічно: redeemRequest(shares), блокування shares, виплата в кінці періоду. Lock-up period (зазвичай 30-90 днів) реалізується через timestamp-перевірку.

struct RedemptionRequest { address lp; uint256 shares; uint256 requestedAt; bool processed; } mapping(uint256 => RedemptionRequest) public redemptionQueue; uint256 public redemptionQueueHead; uint256 public redemptionQueueTail; function requestRedemption(uint256 shares) external { require(shares > 0 && balanceOf(msg.sender) >= shares); // Lock-up: нельзя реализовать раньше чем через lockupPeriod require( block.timestamp >= subscriptionTimestamp[msg.sender] + lockupPeriod, "Lock-up period active" ); _transfer(msg.sender, address(this), shares); // блокируем shares redemptionQueue[redemptionQueueTail++] = RedemptionRequest({ lp: msg.sender, shares: shares, requestedAt: block.timestamp, processed: false }); } 

Як забезпечити точність NAV?

NAV calculator — найскладніший off-chain компонент. NAV повинен точно відображати вартість всіх активів фонду на момент розрахунку. Використовуємо агрегацію даних з кількох джерел із захистом від маніпуляцій.

Джерела даних для NAV:

Маніпуляція NAV — серйозна загроза. Якщо NAV залежить від одного джерела ціни, flash loan атака на DEX-пул може тимчасово спотворити ціну та дати атакуючому арбітраж через subscription/redemption. Захист: TWAP замість spot, агрегація кількох джерел, circuit breaker при різкій зміні NAV. Згідно з Chainlink documentation, використання TWAP знижує ризик маніпуляції на 90%.

class NAVCalculator: async def calculate_nav(self) -> Decimal: positions = await self.fetch_all_positions() nav = Decimal('0') for position in positions: price = await self.get_robust_price(position.asset) nav += position.quantity * price # Верификация: изменение NAV не должно превышать порог prev_nav = await self.get_last_nav() change_pct = abs(nav - prev_nav) / prev_nav * 100 if change_pct > self.MAX_NAV_CHANGE_PCT: await self.trigger_circuit_breaker(nav, prev_nav, change_pct) raise NAVCircuitBreakerError(f"NAV change {change_pct:.1f}% exceeds threshold") return nav async def get_robust_price(self, asset: str) -> Decimal: prices = await asyncio.gather( self.chainlink.get_price(asset), self.pyth.get_price(asset), self.cex_api.get_mid_price(asset), ) # Медиана из трёх источников — надёжнее, чем среднее арифметическое valid = [p for p in prices if p is not None] return sorted(valid)[len(valid) // 2] 

Чому performance fee варто рахувати за High Water Mark?

Performance fee (зазвичай 20% від прибутку) обчислюється через високу водну позначку (High Water Mark) — fee береться тільки з прибутку вище попереднього максимуму NAV. Це захист LP від подвійного оподаткування після просадки та відновлення. Без HWM менеджер міг би брати fee з волатильності, навіть не приносячи чистого прибутку.

uint256 public highWaterMark; // NAV per share на предыдущем пике function settlePerformanceFee(uint256 currentNavPerShare) external onlyRole(MANAGER_ROLE) { if (currentNavPerShare <= highWaterMark) return; // Нет прибыли выше HWM uint256 profit = currentNavPerShare - highWaterMark; uint256 feePerShare = profit * performanceFeeRate / 10000; // Конвертируем в shares и минтим менеджеру uint256 feeShares = feePerShare * totalSupply() / currentNavPerShare; _mint(feeRecipient, feeShares); highWaterMark = currentNavPerShare; emit PerformanceFeeSettled(feePerShare, feeShares); } 

Ключове управління та безпека

Gnosis Safe — стандарт для multi-sig управління фондом. Threshold політики: 3-of-5 для великих операцій (withdrawal > $1M), 2-of-3 для щоденних операцій.

MPC гаманці (Fireblocks, Copper, Liminal) — альтернатива multi-sig для інституційних фондів. Ключ ніколи не збирається цілком, що захищає від компрометації одного учасника. MPC гаманці обробляють транзакції в 3 рази швидше, ніж multi-sig, завдяки відсутності необхідності збирати всі підписи on-chain. Ще важливіше: MPC дозволяє інтегрувати approval workflow — кожна транзакція проходить compliance-перевірку перед підписанням.

HSM (Hardware Security Module) — для максимальної безпеки hot-гаманців торгового двигуна. AWS CloudHSM або фізичні HSM (Thales, Utimaco).

Принципи ізоляції:

• Холодне зберігання (multisig на air-gapped пристроях) — довгострокові активи, > 70% AUM
• Тепле зберігання (MPC/HSM) — робочий капітал для торгівлі
• Hot wallet — мінімум для gas fees та дрібних операцій

Звітність та аудитованість

LP очікують: щомісячні NAV statements, trade logs, fee розрахунки. Регулятори в ряді юрисдикцій вимагають незалежної оцінки NAV та щорічного аудиту.

Всі критичні операції записуються в immutable event log:

• Кожна зміна NAV з джерелами даних та розрахунком
• Кожен trade з ціною виконання, комісією, контрагентом
• Кожна subscription/redemption з NAV на момент обробки

Зберігання: PostgreSQL для оперативного доступу + Arweave/IPFS для незмінного архіву + on-chain хеші ключових звітів для верифікації.

Що входить в роботу: документація, доступи, навчання, підтримка

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

• Повну технічну документацію: архітектура, інтерфейси смарт-контрактів, API off-chain сервісів.
• Доступ до вихідного коду в приватному репозиторії з ліцензією на використання.
• Навчання команди: 2-3 сесії з роботи з vault-контрактом, NAV calculator та мультисиг гаманцем.
• Підтримку на етапі деплою та перші 3 місяці експлуатації (включено у вартість).
• Аудит смарт-контрактів від зовнішньої команди (Ledger, ConsenSys Diligence або аналог).

Як впровадити інфраструктуру за 7-10 тижнів?

Процес розробки складається з п'яти фаз:

1. Проектування (1 тиждень): визначення типів активів, subscription/redemption windows, fee структури, вимог до регуляторної звітності, моделі загроз.
2. Смарт-контракти (2-3 тижні): Vault, NAV oracle, fee module. Тестування на Foundry (fuzz-тести, інваріантні тести). Формальна верифікація ключових інваріантів.
3. Off-chain інфраструктура (2-3 тижні): NAV calculator, trade execution engine, reporting pipeline.
4. Інтеграція та тестування (1 тиждень): End-to-end тести на testnet, stress testing NAV oracle.
5. Аудит та деплой (1 тиждень): Зовнішній аудит смарт-контрактів, поступовий rollout з лімітами.

Мінімальна версія (vault + NAV + multi-sig без автоматизації) — 3-4 тижні.

Технологічний стек

Зв'яжіться з нами для проектування вашої інфраструктури — наші інженери підготують рішення під ваші завдання. Отримайте консультацію щодо реалізації фонду будь-якої складності.