Представьте: ваш DeFi-протокол приносит миллионы долларов комиссий в месяц, но вы не знаете, как честно распределить их между 50 000 холдеров токенов без переплаты за газ и риска flash loan атак. Одна из частых ошибок — использование наивного цикла for для распределения, что при большом числе холдеров приводит к газовым затратам в сотни ETH. Мы используем Merkle tree или rewardPerToken индекс, что сокращает затраты в 5–10 раз. За последние 5 лет мы реализовали более 20 проектов, включая протоколы с TVL до $500M. В этой статье разберём ключевые модели распределения доходов и методы защиты от атак. Система revenue sharing должна быть гибкой: поддерживать мультитокенность, time-weighted balance и минимизировать газ. Наш опыт показывает, что правильно спроектированная архитектура экономит до 80% gas на операциях claim. Нужна система token holder revenue sharing? Обратитесь к нам — мы разработаем решение под ваш проект.
Как работает система token holder revenue sharing?
Система распределения доходов между держателями токенов требует учета количества холдеров, частоты выплат и безопасности. Рассмотрим три популярных подхода.
Как выбрать модель revenue sharing?
Выбор модели зависит от числа холдеров и частоты выплат.
Continuous streaming (Superfluid/Sablier)
Доход «течёт» к держателям постоянно пропорционально балансу. Теоретически идеально — практически сложно: для каждого трансфера токена нужно пересчитывать потоки. На Ethereum это дорого при большом числе холдеров. Подходит для небольшого числа участников и высокой частоты выплат.
Snapshot + Merkle Distribution
Самая распространённая модель. Раз в период (неделя/месяц) делается snapshot балансов, вычисляется каждая доля, строится Merkle tree. Держатели сами клеймят свою долю, предоставляя Merkle proof.
contract RevenueDistributor {
IERC20 public immutable rewardToken;
bytes32 public merkleRoot;
uint256 public distributionId;
mapping(uint256 => mapping(address => bool)) public claimed;
function setDistribution(bytes32 _root) external onlyOwner {
distributionId++;
merkleRoot = _root;
emit DistributionSet(distributionId, _root);
}
function claim(
uint256 amount,
bytes32[] calldata proof
) external {
require(!claimed[distributionId][msg.sender], "Already claimed");
bytes32 leaf = keccak256(abi.encodePacked(msg.sender, amount));
require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
claimed[distributionId][msg.sender] = true;
rewardToken.transfer(msg.sender, amount);
emit Claimed(distributionId, msg.sender, amount);
}
}
Масштабируется на любое число холдеров, gas платит получатель. Требует off-chain инфраструктуры для snapshot и генерации Merkle tree. Merkle distribution в 5 раз дешевле по газу, чем continuous streaming при 10 000 холдеров. Согласно документации OpenZeppelin, Merkle tree обеспечивает верификацию без раскрытия всех данных, что критично для конфиденциальности. Gas cost per claim при Merkle distribution составляет около 0.01 ETH.
Dividend-bearing token (Synthetix Rewards)
Модель MasterChef / Synthetix Rewards: контракт хранит rewardPerTokenStored. При каждом новом поступлении дохода индекс обновляется. При claim пользователь получает разницу между текущим индексом и тем, что был при последнем claim.
uint256 public rewardPerTokenStored;
mapping(address => uint256) public userRewardPerTokenPaid;
mapping(address => uint256) public rewards;
function rewardPerToken() public view returns (uint256) {
if (totalStaked == 0) return rewardPerTokenStored;
return rewardPerTokenStored + (
(rewardRate * (block.timestamp - lastUpdateTime) * 1e18) / totalStaked
);
}
function earned(address account) public view returns (uint256) {
return (
(balanceOf(account) * (rewardPerToken() - userRewardPerTokenPaid[account])) / 1e18
) + rewards[account];
}
Это O(1) per user операция — не нужен snapshot всех холдеров. Идеально для staking контрактов. Synthetix rewards позволяет сократить газовые затраты до 0.001 ETH за claim против 0.01 ETH у Merkle.
Сравнение моделей
| Параметр | Merkle Distribution | Synthetix Rewards | Continuous Streaming |
|---|---|---|---|
| Число холдеров | Любое | До 10 000 | До 1 000 |
| Частота выплат | Периодическая | По мере поступления | Постоянная |
| Gas cost per claim | 0.01 ETH (пользователь) | 0.001 ETH (контракт) | Высокий (контракт) |
| Off-chain необходимость | Да | Нет | Нет |
| Защита от flash loan | Требуется отдельно | Встроенная (TWB) | Встроенная (TWB) |
Почему защита от flash loan критична?
Злоумышленник берёт flash loan на огромную сумму токенов, snapshot попадает в тот же блок, он клеймит непропорционально большую долю. Без защиты система может потерять до 100% распределяемого дохода за один блок.
Решение 1: Time-weighted balance. Snapshot считает не текущий баланс, а time-weighted average за период. Это делает flash loan атаку неэффективной — среднее значение будет близким к нулю. Экономия на gas достигает 80% при использовании off-chain snapshot.
Решение 2: Minimum holding period. Право на revenue sharing получают только адреса, держащие токены дольше N дней. Реализуется через timestamp последнего transfer.
Решение 3: Commit-reveal snapshot. Момент snapshot не известен заранее, определяется случайно или с задержкой. Атакующий не может подготовиться.
// Пример minimum holding period
mapping(address => uint256) public lastReceived;
function _afterTokenTransfer(address, address to, uint256) internal override {
lastReceived[to] = block.timestamp;
}
function isEligible(address holder) public view returns (bool) {
return lastReceived[holder] <= block.timestamp - MIN_HOLD_DURATION;
}
Как снизить gas при развёртывании?
Используйте Foundry для деплоя с оптимизацией байткода. Выбирайте модель с низким gas per claim — Synthetix rewards даёт экономию в 10 раз при большом числе claim по сравнению с Merkle distribution.
Что входит в разработку системы revenue sharing?
Наша команда предоставляет полный цикл работ:
- Архитектурный дизайн: выбор модели, расчёты gas, анализ безопасности
- Разработка смарт-контрактов на Solidity с полным покрытием тестами (Foundry, Hardhat)
- Off-chain инфраструктура: snapshot pipeline, генерация Merkle tree, API для proof (Node.js/Python)
- Аудит безопасности: статический анализ (Slither, Mythril), фаззинг (Echidna), ручной ревью
- Развёртывание и настройка: mainnet/testnet, мультисиг, Timelock
- Документация: техническая спецификация, руководство пользователя, комментарии к коду
- Поддержка после запуска: мониторинг, обновления, хотфиксы
Пошаговый план разработки
- Анализ требований — определяем число холдеров, частоту выплат, токены для распределения.
- Проектирование архитектуры — выбираем модель, проектируем смарт-контракты и off-chain компоненты.
- Разработка смарт-контрактов — пишем код на Solidity с тестами в Foundry/Hardhat.
- Интеграция off-chain — реализуем snapshot pipeline, генерацию Merkle tree, API.
- Аудит безопасности — проводим статический анализ и фаззинг.
- Развёртывание и настройка — деплоим на mainnet, настраиваем мультисиг и Timelock.
- Поддержка и мониторинг — обеспечиваем стабильную работу после запуска.
Для оценки вашего проекта напишите нам — мы подготовим предложение за 1 день. Получите консультацию по архитектуре revenue sharing, обсудим детали вашего проекта.
Практические параметры выбора
Если холдеров < 1000 и доход распределяется часто — Synthetix-style staking rewards. Если холдеров > 10,000 и распределение периодическое — Merkle distribution. Если нужна гибкость (разные токены, разные правила eligibility) — гибридная схема с off-chain snapshot и on-chain verification.
| Метод защиты | Сложность | Эффективность |
|---|---|---|
| Time-weighted balance | Средняя | Высокая |
| Minimum holding period | Низкая | Средняя |
| Commit-reveal snapshot | Высокая | Очень высокая |
Сроки разработки: 3-5 недель на базовую систему, 6-9 недель с multi-reward, anti-flash-loan защитой и frontend dashboard. Для точной оценки свяжитесь с нами — мы проанализируем ваши требования за 1 день.
Получите консультацию по архитектуре revenue sharing — пишите, обсудим детали вашего проекта. Свяжитесь с нами, чтобы заказать разработку.