Розробка системи fee distribution для протоколу
Уявіть: ваш DeFi-протокол генерує $100k комісій на день, але власники токена не отримують нічого. Uniswap V3 зіткнувся з цим до включення fee switch — governance перенаправив частину fees до treasury, знадобилася надійна система збору, акумуляції та розподілу. Ми розробляємо такі системи під ключ з урахуванням gas optimization та безпеки. Synthetix StakingRewards — еталонний патерн, який ми адаптуємо під вашу архітектуру.
Два патерни розподілу: push vs pull
Чому pull distribution вигідніший за push?
Push distribution — розсилка всім. Контракт накопичує fees і періодично викликає distribute(), яка пробігає по списку стейкерів і переказує кожному частку. Просто в розумінні, складно в реалізації: unbounded loop — класичний gas griefing вектор. При 10 000 стейкерах транзакція перевищить block gas limit (потрібно ~3 млн газу замість типових 150 тис.).
Допустимо тільки для систем з явним cap на кількість учасників і batch обробкою (pagination). У більшості випадків — неправильний вибір. Pull distribution скорочує газові витрати на claim у 4 рази, що критично при масштабуванні до тисяч стейкерів.
Pull distribution — користувач сам забирає. Контракт веде rewardPerTokenStored — накопичений reward на одиницю стейку з моменту запуску. При кожному deposit/withdraw/claim оновлює userRewardPerTokenPaid для конкретного користувача. Винагорода = (rewardPerTokenStored - userRewardPerTokenPaid) * balance.
Це математика з Synthetix StakingRewards — одного з найбільш скопійованих патернів у DeFi. Ключова властивість: Gas-complexity O(1) для claim, не залежить від кількості стейкерів.
function earned(address account) public view returns (uint256) { return ( (balanceOf[account] * (rewardPerToken() - userRewardPerTokenPaid[account])) / 1e18 ) + rewards[account]; } Цей патерн ми використовуємо як базу для більшості fee distribution систем.
| Характеристика | Push distribution | Pull distribution |
|---|---|---|
| Gas на claim | ~200 000 + O(N) | ~50 000 O(1) |
| Проблема при 10 000 стейкерах | Перевищення limit | Незначне зростання |
| Складність бага | Висока (повтори, frontrun) | Середня (математика) |
| Масштабованість | Погана | Відмінна |
Збір fees та конвертація
Як конвертувати fees без втрат?
Протоколи генерують fees у різних токенах — swap fees у торгованих токенах, lending fees у debt-токенах. Перш ніж розподілити стейкерам, потрібно конвертувати в один target token (зазвичай protocol token або USDC).
FeeCollector контракт — агрегує fees з усіх source контрактів. Періодично викликається keeper (Chainlink Automation, Gelato) або будь-яким користувачем.
Конвертація через DEX — swap accumulated fees у target token через Uniswap V3. Важливо: конвертація великого обсягу за раз створює price impact і MEV-можливості. Рішення: конвертувати малими частинами через TWAP-орієнтовані свопи або використовувати Cow Protocol для MEV-захищених свопів. Це знижує прослизання на 20-30%.
Розподіл у кількох токенах — іноді правильніше не конвертувати, а розподіляти в оригінальних fee-токенах. Curve розподіляє 3CRV LP-токени (кошик стейблкоїнів) замість конвертації. Це дорожче в реалізації (multi-reward staking), але зберігає цінність без slippage.
Багатоканальний розподіл
Рідко весь fee йде тільки стейкерам. Типова схема:
| Отримувач | Частка | Механізм |
|---|---|---|
| Стейкери токена | 40-60% | Pull-distribution, rewardPerToken |
| Treasury | 20-30% | Прямий переказ на multisig |
| Insurance fund | 10-20% | Накопичення для покриття bad debt |
| Burn | 5-10% | token.burn() |
Пропорції задаються через governance-керовані параметри з timelock. FeeDistributor контракт читає актуальні пропорції при кожному виклику distribute().
veToken модель (vote-escrowed)
Curve ввела модель, де для отримання fees потрібно залочити CRV на термін до 4 років. Чим довший lock — тим більше veCRV, тим більша частка fees. Це вирівнює інтереси: довгострокові власники отримують більше. Реалізація складніша за базовий staking — потрібен decay розрахунок voting power, періодичні checkpoints, інтеграція з gauge voting.
Якщо потрібна veToken механіка — це окремий scope робіт поверх базового fee distribution.
Що входить у роботу
- Аудит існуючої архітектури та вибір оптимального патерну (pull/push/hybrid).
- Розробка смарт-контрактів: FeeCollector, FeeDistributor, Staking (з урахуванням reentrancy-захисту, перевірки на OpenZeppelin).
- Інтеграція з DEX для конвертації (Uniswap V3, Cow Protocol).
- Написання тестів (Foundry, fuzz, fork-тести) з покриттям edge cases.
- Деплой та верифікація контрактів в Etherscan.
- Документація для governance та аудиторів.
- Підтримка після запуску (моніторинг, гарячі виправлення).
Гарантуємо відсутність reentrancy та frontrunning-вразливостей. Досвід команди: 7+ років у блокчейні, 50+ смарт-контрактів, 5 років на ринку. Зв'яжіться з нами для аудиту вашої архітектури — оцінимо проєкт за 1 день. Замовте розробку fee distribution системи — отримайте консультацію з архітектури.
Які ризики приховує push distribution?
Push distribution при великій кількості стейкерів може перевищити block gas limit, а також піддається frontrunning-атакам на момент виклику distribute(). Для великих протоколів pull distribution безпечніший.
Процес роботи та орієнтири за термінами
Проектування (2-3 дні). Визначаємо source контракти, target token, пропорції розподілу, keeper механізм для періодичної конвертації.
Розробка (5-8 днів). FeeCollector + FeeDistributor + Staking контракт. Тести з Foundry: коректність розрахунку earned() при зміні total supply, коректна обробка deposit/withdraw у тому ж блоці що distribute().
Інтеграційні тести. Fork-тест з реальним Uniswap V3 pool для перевірки конвертації fees. Fuzz-тести на математику розподілу — edge cases при дуже маленьких або дуже великих балансах.
Базова система (pull-distribution, один reward token, periodic collect) — 1 тиждень. З конвертацією через DEX і multi-reward — 1.5-2 тижні. veToken механіка — додаткові 2-3 тижні. Вартість розраховується індивідуально залежно від складності та необхідного аудиту.