Инфраструктура крипто-фонда: смарт-контракты, 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 недели.

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

Свяжитесь с нами для проектирования вашей инфраструктуры — наши инженеры подготовят решение под ваши задачи. Получите консультацию по реализации фонда любой сложности.