Разработка fan-токенов

Разработка fan-токенов

Fan-токены — это не просто branded монеты. Правильно сделанный fan-токен даёт болельщикам реальные права: голосование за дизайн формы, выбор музыки на стадионе, приоритетный доступ к билетам. Chiliz и Socios.com показали, что модель работает для топ-клубов (Барселона, Ювентус, ПСЖ). Вопрос в том, как воспроизвести эту механику для клуба или артиста меньшего масштаба, не получив пустую монету с нулевой утилитой.

Технически fan-токен — это ERC-20 с дополнительной логикой: governance права, access control для перков, distribution механизм. Сложность не в коде, а в tokenomics и в создании реальной ценности для холдеров.

Структура токена

Базовый контракт

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";

contract FanToken is ERC20, ERC20Votes, ERC20Permit, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant POLL_MANAGER_ROLE = keccak256("POLL_MANAGER_ROLE");

    uint256 public constant MAX_SUPPLY = 20_000_000 * 10 ** 18; // 20M токенов

    constructor(
        string memory name,
        string memory symbol,
        address admin
    ) ERC20(name, symbol) EIP712(name, "1") ERC20Permit(name) {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(MINTER_ROLE, admin);
    }

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        require(totalSupply() + amount <= MAX_SUPPLY, "Exceeds max supply");
        _mint(to, amount);
    }

    // Обязательный override для ERC20Votes
    function _afterTokenTransfer(address from, address to, uint256 amount)
        internal override(ERC20, ERC20Votes)
    {
        super._afterTokenTransfer(from, to, amount);
    }

    function _mint(address to, uint256 amount)
        internal override(ERC20, ERC20Votes)
    {
        super._mint(to, amount);
    }

    function _burn(address account, uint256 amount)
        internal override(ERC20, ERC20Votes)
    {
        super._burn(account, amount);
    }
}

ERC20Votes даёт snapshot-механизм для голосования (checkpoints по блокам), ERC20Permit — gasless approve через подпись. Оба расширения важны: votes нужны для polling контракта, permit снижает трение при взаимодействии.

Polling контракт

Голосование — центральная механика. Клуб создаёт опрос, холдеры голосуют весом, пропорциональным балансу:

contract FanPoll {
    IVotes public immutable token;

    struct Poll {
        string question;
        string[] options;
        uint256 snapshotBlock;  // блок для подсчёта весов
        uint256 startTime;
        uint256 endTime;
        uint256 minTokensRequired;  // минимальный баланс для участия
        mapping(uint256 => uint256) voteCounts;
        mapping(address => bool) hasVoted;
    }

    mapping(uint256 => Poll) public polls;
    uint256 public pollCount;

    event PollCreated(uint256 indexed pollId, string question, uint256 snapshotBlock);
    event Voted(uint256 indexed pollId, address indexed voter, uint256 option, uint256 weight);

    function vote(uint256 pollId, uint256 optionIndex) external {
        Poll storage poll = polls[pollId];
        require(block.timestamp >= poll.startTime, "Not started");
        require(block.timestamp <= poll.endTime, "Ended");
        require(!poll.hasVoted[msg.sender], "Already voted");

        // Вес = баланс на момент снапшота
        uint256 weight = token.getPastVotes(msg.sender, poll.snapshotBlock);
        require(weight >= poll.minTokensRequired, "Insufficient tokens");

        poll.hasVoted[msg.sender] = true;
        poll.voteCounts[optionIndex] += weight;

        emit Voted(pollId, msg.sender, optionIndex, weight);
    }
}

snapshotBlock критичен: без него можно купить токены прямо перед голосованием, проголосовать и продать. Snapshot берётся при создании опроса, веса фиксируются в прошлом.

Access control для перков

Fan-токены дают не только голос, но и физический доступ. Типичные tier-уровни:

Для верификации перков два подхода: on-chain check (контракт проверяет balance в момент использования — прост, но баланс можно временно занять) и snapshot + Merkle proof (права фиксируются на конкретный момент — надёжнее для сезонных перков).

Интеграция с физическим миром: QR-код на входе сканируется, бэкенд проверяет signature, подписанную кошельком пользователя через WalletConnect. Никаких приватных ключей на устройстве — только подпись сообщения.

Distribution и tokenomics

Ошибка № 1 fan-токенов: весь supply продаётся через Socios/Chiliz exchange, клуб получает деньги сразу, но рынок насыщен, цена падает, холдеры недовольны. Устойчивая модель:

Allocation типичного fan-токена:

• 40% — публичная продажа через Fan Token Offering (FTO): поэтапно, не всё сразу
• 20% — клуб/организация: вестинг 2-3 года, показывает commitment
• 15% — engagement rewards: выдаются болельщикам за активность (посещение матчей, участие в опросах, покупка мерча)
• 15% — treasury: будущие партнёрства, listing на биржах
• 10% — команда разработки: вестинг

Engagement rewards — самая важная часть для жизнеспособности. Токены должны органически распределяться тем, кто реально является болельщиком, не только трейдерам. Механика: сканирование билета на матч = reward в токенах, участие в опросе = микро-reward, покупка мерча с кодом = reward.

Цепочка и листинг

Для фан-токенов с реальной пользовательской базой: не mainnet Ethereum (gas слишком высокий для микротранзакций). Оптимальные варианты:

Chiliz Chain (CHZ): специализирована для fan-токенов, собственная DEX (Chiliz DEX), интеграция с Socios.com. Если цель — максимальный reach существующей аудитории.

Polygon PoS или Polygon zkEVM: дешёвый газ, большая экосистема, много готовых инструментов. Оптимально для независимого запуска без привязки к Socios.

Base: L2 от Coinbase, растущая аудитория, хорошая ликвидность. Логичный выбор если целевая аудитория — североамериканский рынок.

Листинг на CEX (централизованная биржа) — отдельный процесс с юридической и compliance-стороной. DEX листинг (Uniswap, QuickSwap) можно сделать самостоятельно, добавив пул ликвидности.

Юридическая сторона

Fan-токены с governance правами — потенциально securities в ряде юрисдикций. SEC (США) и ESMA (Европа) рассматривают их под лупой. Стандартная защита: токен не даёт доли в клубе, не обещает финансового возврата, права — исключительно на участие в голосованиях о некоммерческих вопросах.

Проект требует юридической консультации до запуска. Это не опция.

Процесс работы

Дизайн tokenomics (1-2 недели). Allocation, механика engagement rewards, tier-система перков, критерии листинга.

Разработка контрактов (2-3 недели). FanToken ERC-20 + FanPoll + EngagementRewards distributor + тесты.

Аудит (1-2 недели). Контракты управляют ценными активами — внешний аудит обязателен.

Разработка бэкенда и frontend (2-4 недели). Admin панель для клуба, холдер-дашборд, WalletConnect интеграция.

Запуск FTO и листинг. Сроки зависят от выбранной платформы и юрисдикции.

Стоимость рассчитывается по итогам аналитики.