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

Отметим: когда криптофонд фиксирует прибыль и нужно распределить её между десятками 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]; } } 

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

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

Если 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 для операций менеджера.

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

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 в месяц.