Разработка инфраструктуры крипто-фонда

Разработка инфраструктуры крипто-фонда

Крипто-фонд — это не просто "мультисиг + торговый аккаунт на бирже". Как только в фонде несколько LP, начинаются вопросы: как считается NAV в реальном времени, как обеспечить изоляцию активов LP, как автоматизировать redemption без ручного вмешательства, как обеспечить аудитабельность каждой операции. Инфраструктура фонда — это комплекс смарт-контрактов, off-chain сервисов и операционных процессов. Разберём по слоям.

Архитектура: что входит в инфраструктуру фонда

Типичный крипто-фонд состоит из нескольких технических слоёв:

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 — неизменяемый лог всех операций

Vault-контракт: учёт долей LP

Стандарт EIP-4626 (Tokenized Vault Standard) — отправная точка для большинства 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 Calculator: расчёт стоимости портфеля

Это самый сложный off-chain компонент. NAV должен точно отражать стоимость всех активов фонда на момент расчёта.

Источники данных для NAV:

Манипуляция NAV — серьёзная угроза. Если NAV зависит от одного источника цены, flash loan атака на DEX-пул может временно исказить цену и дать атакующему арбитраж через subscription/redemption. Защита: time-weighted average price (TWAP) вместо spot, агрегация нескольких источников, circuit breaker при резком изменении NAV.

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]

Fee Module: management fee и performance fee

Management fee (обычно 1-2% годовых) начисляется непрерывно. Реализация через mintинг новых shares в пользу менеджера:

// Management fee: mint shares пропорционально времени
function accrueManagementFee() public {
    uint256 elapsed = block.timestamp - lastFeeAccrual;
    if (elapsed == 0) return;

    // fee = totalSupply * feeRate * elapsed / YEAR
    uint256 feeShares = totalSupply() * managementFeeRate * elapsed
        / (10000 * 365 days);

    if (feeShares > 0) {
        _mint(feeRecipient, feeShares);
        lastFeeAccrual = block.timestamp;
        emit ManagementFeeAccrued(feeShares);
    }
}

Performance fee (обычно 20% от прибыли) считается через High Water Mark (HWM) — fee берётся только с прибыли выше предыдущего максимума NAV. Это защита LP от двойного обложения после просадки и восстановления.

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 позволяет интегрировать 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 хэши ключевых отчётов для верификации.

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

Процесс разработки

Фаза 1 (1 неделя): проектирование. Определение типов активов, subscription/redemption windows, fee структуры, требований к регуляторной отчётности, модели угроз.

Фаза 2 (2-3 недели): смарт-контракты. Vault, NAV oracle, fee module. Тестирование на Foundry (fuzz-тесты, инвариантные тесты). Формальная верификация ключевых инвариантов.

Фаза 3 (2-3 недели): off-chain инфраструктура. NAV calculator, trade execution engine, reporting pipeline.

Фаза 4 (1 неделя): интеграция и тестирование. End-to-end тесты на testnet, stress testing NAV oracle.

Фаза 5 (1 неделя): аудит и деплой. Внешний аудит смарт-контрактов, постепенный rollout с лимитами.

Итого: 7-10 недель для полной инфраструктуры. Минимальная версия (vault + NAV + multi-sig без автоматизации) — 3-4 недели.