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

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

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

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

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

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

// 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");

        // Вага = баланс на момент snapshotBlock
        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% — клуб/організація: vesting 2-3 роки, показує commitment
• 15% — engagement rewards: раздаються болільникам за активність (посещення матчів, участь в опросах, покупка мерча)
• 15% — treasury: майбутні партнерства, листинги на біржах
• 10% — команда розробки: vesting

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

Чейн та листинг

Для fan-токенів з реальною користувацькою базою: не mainnet Ethereum (газ занадто високий для мікротранзакцій). Оптимальні варіанти:

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 та листинг. Строки залежать від вибраної платформи та юрисдикції.

Вартість розраховується за результатами аналітики.