Распределение прибыли криптофонда: HWM, performance fee, LP

Когда криптофонд фиксирует прибыль, справедливо распределить её между LP с разными датами входа и условиями — без точной математики возникают споры и потери. Мы проектируем и реализуем систему распределения прибыли, которая учитывает время вклада, корректно начисляет performance fee и защищена от манипуляций. Наша команда берёт на себя весь цикл — от выбора модели до деплоя с документацией и поддержкой.
Часто задаваемые вопросы

Отметим: когда криптофонд фиксирует прибыль и нужно распределить её между десятками LP с разными датами входа, частичными выходами и накопленным performance fee, простой пропорциональный расчёт приводит к несправедливости и дырам в математике. Например, фонд с тремя LP, зашедшими в разные дни, при квартальной выплате без учёта времени вклада даст одним LP незаслуженные доходы, а другим — потери. Мы проектируем и реализуем систему распределения прибыли криптофонда, которая математически точна, аудитабельна и защищена от манипуляций. Под ключ — от выбора модели до деплоя с документацией и поддержкой. Средняя экономия на комиссиях сети для фонда с 500 LP оценивается в $3000–$5000 в месяц. Оценим ваш проект за 1–2 дня, свяжитесь с нами.

Задачи системы распределения прибыли

Система обязана справедливо учитывать время вклада каждого LP, корректно начислять performance fee только на новую прибыль, и поддерживать масштабирование до тысяч участников. Без продуманной архитектуры возникают проблемы: reentrancy при выплатах, no-loss of precision, и уязвимости к flash loan атакам через манипуляцию оракулами. Наше решение использует проверенные паттерны из DeFi — EIP-4626 vaults и Synthetix staking rewards — и дополняет их инвариантным тестированием на Foundry.

Как выбрать модель учёта долей?

Прежде чем писать контракты, выбираем фундаментальную модель учёта долей. Два основных подхода.

Share-based (токенизированные доли)

LP получают ERC-20 shares при входе. Прибыль отражается через рост NAV per share — один share стоит больше, но количество shares не меняется. Распределение прибыли означает либо рост стоимости shares (capital appreciation), либо выплату дивидендов с уменьшением NAV per share. «EIP-4626 defines a standard for tokenized vaults that simplifies integration with DeFi protocols» — стандарт упрощает интеграцию с DeFi, но создаёт сложности при частичных выходах и interim distributions.

Point-based (накопительные очки)

Каждый LP накапливает «очки» пропорционально времени и сумме депозита. Прибыль делится пропорционально очкам. Этот подход подходит для yield-фондов с регулярными выплатами. Паттерн «Rewards per token» — проверенный способ эффективно считать накопленные rewards без итерации по всем LP.

contract ProfitDistributor {
    uint256 public rewardPerShareStored;
    uint256 public lastUpdateTime;
    uint256 public totalShares;
    mapping(address => uint256) public rewardPerSharePaid;
    mapping(address => uint256) public pendingRewards;
    mapping(address => uint256) public shares;

    modifier updateReward(address account) {
        rewardPerShareStored = rewardPerShare();
        lastUpdateTime = block.timestamp;
        if (account != address(0)) {
            pendingRewards[account] = earned(account);
            rewardPerSharePaid[account] = rewardPerShareStored;
        }
        _;
    }

    function earned(address account) public view returns (uint256) {
        return shares[account] * (rewardPerShare() - rewardPerSharePaid[account]) / 1e18 + pendingRewards[account];
    }
}
Характеристика Share-based Point-based
Прозрачность Высокая (стоимость shares видна) Средняя (очки рассчитываются off-chain)
Газ на вход/выход ~80k (ERC-20 transfer) ~50k (обновление mapping)
Поддержка частичного выхода Сложно (приходится сжигать shares) Просто (уменьшение очков)
Аудит смарт-контракта Проще (стандарт EIP-4626) Сложнее (расчёты очков)

Почему простые системы ломаются на сложных кейсах?

Входы и выходы в середине периода

Если LP зашёл в середине квартала, он не должен получать прибыль за период до его входа. И наоборот — при выходе в середине периода он должен получить свою долю начисленного, но ещё не распределённого. Решение: snapshot-based distribution. При каждом изменении состояния фиксируем checkpoint с текущим rewardPerShare. При расчёте используем разницу между текущим и checkpoint-значением.

function _updateCheckpoint(address lp) internal {
    uint256 currentRPS = rewardPerShareStored;
    uint256 lpShares = shares[lp];
    uint256 lastRPS = checkpoints[lp].rewardPerShare;
    if (lpShares > 0 && currentRPS > lastRPS) {
        uint256 accrued = lpShares * (currentRPS - lastRPS) / PRECISION;
        checkpoints[lp].pendingReward += accrued;
    }
    checkpoints[lp].rewardPerShare = currentRPS;
}

Performance fee с High Water Mark

Performance fee (обычно 20%) должна браться только с новой прибыли — выше предыдущего HWM. Это защита LP от двойного fee после просадки и восстановления. Выбор между Global HWM и Per-LP HWM: первый проще, второй справедливее, но дороже по газу. Если в фонде более 50 LP, разница в газе может превысить 30%. Для фондов с капиталом от $5 млн экономия от Per-LP HWM может составить до $2000 в месяц за счёт справедливого учёта.

mapping(address => uint256) public lpHighWaterMark;

function calculatePerformanceFee(address lp, uint256 currentNAVPerShare) public view returns (uint256 feeAmount) {
    uint256 hwm = lpHighWaterMark[lp];
    if (currentNAVPerShare <= hwm) return 0;
    uint256 profitPerShare = currentNAVPerShare - hwm;
    uint256 lpShareBalance = shares[lp];
    feeAmount = profitPerShare * lpShareBalance * performanceFeeRate / (PRECISION * 10000);
}

Hurdle rate

Некоторые фонды берут performance fee только если доходность превысила benchmark (например, 8% годовых). Реализуется как дополнительный порог поверх HWM.

Защита от oracle manipulation при расчёте performance fee

Используем TWAP вместо spot prices, вводим cooldown между обновлением NAV и settleFee. Это предотвращает flash loan атаки, когда злоумышленник временно искажает цену для начисления fee. Дополнительно — multi-sig для операций менеджера.

Методы организации выплат

Метод Газ на одну выплату Подходит для Риски
Реинвестирование Низкий Любой масштаб Нет
Pull pattern (claim) ~50k gas До 1000 LP LP должен клеймить сам
Merkle drop O(log N) ~60k Тысячи LP (в 10 раз дешевле push pattern) Требуется off-chain расчёт
Push pattern O(N) ~100k+ До ~50 LP Может упасть на контракте-получателе

Merkle distribution — оптимальный выбор для тысяч LP: менеджер вычисляет выплаты off-chain, строит Merkle tree, публикует root on-chain. Каждый LP клеймит свою выплату с proof, газ не зависит от числа получателей. Uniswap использует этот паттерн для UNI-дистрибуции.

bytes32 public merkleRoot;

function claimMerkle(
    uint256 index,
    address account,
    uint256 amount,
    bytes32[] calldata merkleProof
) external {
    require(!isClaimed(index), "Already claimed");
    bytes32 node = keccak256(abi.encodePacked(index, account, amount));
    require(MerkleProof.verify(merkleProof, merkleRoot, node), "Invalid proof");
    _setClaimed(index);
    IERC20(rewardToken).safeTransfer(account, amount);
    emit Claimed(index, account, amount);
}

Безопасность и аудит: защита от манипуляций

Ключевые уязвимости:

  • Reentrancy при выплатах — обнуляем pendingRewards до transfer.
  • Precision loss — используем fixed-point арифметику с масштабом 1e18, округление вниз.
  • Oracle manipulation — TWAP и cooldown между NAV update и fee settlement.
  • Centralization менеджера — timelock 24–48h и multi-sig для операции settleFee.

Детали gas optimization: Используем storage packing, уменьшаем число SSTORE, применяем unchecked для overflow-safe операций. Это снижает газ на 30–40% по сравнению с наивной реализацией. В одном проекте с 500 LP экономия составила существенную сумму на комиссиях. Мы гарантируем аудитабельность контрактов: наша команда имеет опыт в смарт-контрактах на Solidity, Rust (Solana), Vyper. Каждый смарт-контракт проходит формальную верификацию и инвариантное тестирование на Foundry. Более 30 успешных проектов: фонды, DEX, NFT-маркетплейсы. Экономия газа за счёт оптимизации достигает 40% по сравнению с наивными реализациями.

Что вы получаете: этапы и deliverables

  1. Проектирование (3–5 дней): выбор модели, структуры fee, HWM per-LP vs global, механизма выплат. Формализация инвариантов. Документация схемы.
  2. Разработка контрактов (7–10 дней): vault, distributor, fee module. Юнит-тесты, fuzz-тесты, инвариантные тесты. Исходный код + развёрнутая документация.
  3. Off-chain компоненты (3–5 дней): NAV calculator, Merkle tree builder, скрипты клейма. Интеграционные тесты.
  4. Аудит (1–2 недели): внешний аудит обязателен для систем, управляющих чужими деньгами. Отчёт с рекомендациями. Стоимость внешнего аудита варьируется от $10 000 до $25 000 в зависимости от сложности — мы помогаем с выбором подрядчика.
  5. Деплой и мониторинг (2–3 дня): graduated rollout, мониторинг инвариантов в реальном времени. Доступ к дашборду.

После деплоя передаём полную техническую документацию, конфигурации и обучение команды. Поддержка на 30 дней. Гарантия на уязвимости — 6 месяцев. Получите консультацию — свяжитесь с нами, оценим проект в срок. Закажите разработку системы распределения прибыли для вашего криптофонда уже сегодня.

Дополнительно: при фонде с капиталом $10 млн и 1000 LP экономия на комиссиях за счёт оптимизации газа составит около $4 000 в месяц.

Направления блокчейн-разработки

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1543
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1142