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

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

Крипто-фонд — це не просто "мультисиг + торговий аккаунт на бірже". Як тільки в фонді кілька 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% щорічно) нараховується безперервно. Реалізація через мінтинг нових 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, розрахунок fees. Регулятори в деяких юрисдикціях (Кайманови острови, BVI) вимагають незалежної оцінки 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 тижні.