Ошибка при выборе модели распределения наград может стоить тысяч долларов газа и потерю пользователей. Разработка системы вознаграждений для fan-токенов — наша специализация, и мы знаем, как этого избежать. Fan-токены — отдельная ниша: Chiliz/Socios модель, токены спортивных клубов, музыкантов, стримеров. Механика отличается от DeFi-стейкинга: здесь ценность не только финансовая. Держатели ожидают доступ к exclusive контенту, право голосовать в опросах, NFT-дропы, meet-and-greet лотереи. Стейкинг должен это отражать. Мы реализуем гибкие контракты с поддержкой множества reward-механик, оптимизируя газ на 30–40% по сравнению с типовыми решениями.
Разработка системы вознаграждений для fan-токенов: тиры лояльности
Классический подход для fan-токенов: три-четыре тира с разным набором преимуществ. Логика: чем больше застейкано и чем дольше — тем выше тир.
| Тир | Минимум токенов | Lock период | Преимущества |
|---|---|---|---|
| Bronze | 100 FAN | Нет | Голосование, базовый контент |
| Silver | 500 FAN | 30 дней | + ранний доступ к NFT-дропам |
| Gold | 2000 FAN | 90 дней | + лотерея на мерч/билеты |
| Platinum | 10000 FAN | 180 дней | + meet-and-greet, эксклюзивные звонки |
Тир определяется on-chain через стейкинг-контракт. Off-chain сервисы (контент-платформа, лотерейная система) читают тир через view-функцию и открывают соответствующие возможности.
Почему pull-модель лучше для fan-токенов?
Подход 1 — Pull model (MasterChef-стиль) — разработка системы вознаграждений
Каждый стейкер накапливает pending rewards, которые клеймит вручную. Используется accRewardPerShare — аккумулятор, обновляемый при каждом deposit/withdraw. Хорошо масштабируется: газ на reward раздачу платит пользователь, а не протокол.
struct UserInfo { uint256 amount; // застейкано FAN uint256 rewardDebt; // долг для корректного расчёта pending uint256 lockedUntil; // timestamp разблокировки uint8 tier; // текущий тир } function pendingReward(address user) public view returns (uint256) { UserInfo storage info = userInfo[user]; uint256 accPerShare = accRewardPerShare; // обновлённое значение if (block.timestamp > lastRewardTime && totalStaked > 0) { uint256 elapsed = block.timestamp - lastRewardTime; uint256 newReward = elapsed * rewardPerSecond; accPerShare += newReward * 1e12 / totalStaked; } return info.amount * accPerShare / 1e12 - info.rewardDebt; } Подход 2 — Push model (снапшоты)
Команда периодически делает snapshot застейканных балансов и распределяет награды (например, после каждого матча — раздать пул наград всем Gold+ держателям). Реализуется как MerkleDistributor раунды.
Плюс push: можно распределять non-fungible награды (NFT) и off-chain ценности (коды доступа). Минус: требует регулярных транзакций со стороны команды протокола.
Для fan-токенов оптимально: pull-модель для финансовых наград (токены), push/snapshot для специальных событий (NFT-дропы, лотереи). Pull-модель экономит до 70% газа по сравнению с push при 10 000 пользователей.
Как интегрировать NFT в систему вознаграждений?
Популярный паттерн: стейкинг открывает доступ к минту exclusive NFT. Не бесплатный (иначе все минтят и продают) — минт доступен при условии достижения тира и поддержания стейка.
Реализация: NFT-контракт проверяет стейкинг-контракт в функции mint:
function mintExclusive(uint256 tokenId) external { IFanStaking staking = IFanStaking(stakingContract); require(staking.getUserTier(msg.sender) >= GOLD_TIER, "Insufficient tier"); require(!hasMinted[msg.sender][tokenId], "Already minted"); hasMinted[msg.sender][tokenId] = true; _mint(msg.sender, tokenId); } Бонусы за время и loyalty multiplier
Чем дольше адрес держит стейк без вывода, тем выше его effective стейк для расчёта наград. Механика: loyaltyMultiplier растёт со временем (например, +10% каждые 30 дней, cap 200%). При любом withdraw — сброс до 100%.
Хранить multiplier как uint256 процентов и умножать на amount перед расчётом rewardDebt. Это создаёт incentive не трогать стейк — что снижает circulating supply и давление на цену.
Голосование для держателей
Fan-опросы — это простые on-chain голосования, доступные только застейканным адресам нужного тира. Не нужен полноценный DAO фреймворк. Достаточно лёгкого контракта:
function vote(uint256 pollId, uint8 optionIndex) external { require(stakingContract.getUserTier(msg.sender) >= polls[pollId].minTier, "Tier too low"); require(block.timestamp < polls[pollId].endTime, "Poll ended"); require(!hasVoted[pollId][msg.sender], "Already voted"); hasVoted[pollId][msg.sender] = true; uint256 weight = stakingContract.getStakedAmount(msg.sender); // голос = вес стейка polls[pollId].votes[optionIndex] += weight; emit VoteCast(pollId, msg.sender, optionIndex, weight); } Результаты публично верифицируемы on-chain, что важно для доверия фанатов.
Технические особенности fan-среды
ERC-20 с трансферными ограничениями
Некоторые fan-токены запрещают трансфер в официальных маркетплейсах (только через одобренные DEX или Chiliz Chain). При разработке стейкинга учитывайте: если токен имеет transferFrom ограничения, депозит в стейкинг-контракт может быть заблокирован. Решение: whitelist стейкинг-контракта в токене.
Multi-chain раздельность
Chiliz Chain — отдельный EVM-совместимый L1. Если fan-токен живёт там, весь стейкинг контракт деплоится на Chiliz Chain. Газ дешёвый, но экосистема ограничена. Возможен bridge на Ethereum/Polygon для DeFi интеграций.
Регуляторная осторожность
Fan-токены в некоторых юрисдикциях квалифицируются как ценные бумаги, если дают финансовые права. Стейкинг с токен-наградами усиливает этот риск. Юридическая консультация до запуска — обязательна. Мы гарантируем, что все контракты проходят аудит и соответствуют лучшим практикам безопасности.
Что входит в разработку
- Анализ требований и выбор модели распределения наград
- Проектирование архитектуры смарт-контрактов
- Разработка контрактов (Solidity, Foundry)
- Интеграция с frontend (wagmi, React)
- Аудит кода (Slither, Mythril, Echidna)
- Документация и деплой
- Поддержка после запуска
| Этап | Срок | Результат |
|---|---|---|
| Аналитика | 3-5 дней | Техническое задание |
| Разработка контрактов | 2-4 недели | Рабочие контракты |
| Интеграция frontend | 1-2 недели | Интерфейс стейкинга |
| Аудит | 2-3 недели | Отчёт аудита |
Аудит смарт-контрактов перед запуском
Аудит обязателен перед запуском с реальными средствами. Мы используем автоматизированные инструменты (Slither, Mythril) и ручную проверку логики. Типовые уязвимости: reentrancy, ошибки округления, доступ к функциям. Наш сертифицированный опыт в области безопасности блокчейна подтверждён десятками проектов.
Закажите консультацию инженера для оценки вашего проекта. Свяжитесь с нами для обсуждения сроков и стоимости разработки системы вознаграждений для fan-токенов.