Fan Tokens Development

Fan Tokens Development

Fan tokens — not just branded coins. Properly made fan token gives fans real rights: voting on jersey design, choosing stadium music, priority ticket access. Chiliz and Socios.com showed the model works for top clubs (Barcelona, Juventus, PSG). Question is how to replicate mechanics for smaller scale club or artist without getting empty coin with zero utility.

Technically fan-token — ERC-20 with additional logic: governance rights, access control for perks, distribution mechanism. Complexity not in code, but in tokenomics and creating real value for holders.

Token Structure

Basic Contract

// 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 tokens

    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);
    }

    // Required override for 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 provides snapshot mechanism for voting (block checkpoints), ERC20Permit — gasless approve via signature. Both extensions important: votes needed for polling contract, permit reduces friction on interaction.

Polling Contract

Voting — central mechanic. Club creates poll, holders vote with weight proportional to balance:

contract FanPoll {
    IVotes public immutable token;

    struct Poll {
        string question;
        string[] options;
        uint256 snapshotBlock;  // block for weight calculation
        uint256 startTime;
        uint256 endTime;
        uint256 minTokensRequired;  // minimum balance to participate
        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");

        // Weight = balance at snapshot
        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 critical: without it someone can buy tokens right before voting, vote, and sell. Snapshot taken at poll creation, weights fixed in past.

Access Control for Perks

Fan tokens give not just voice, but physical access. Typical tier levels:

For perk verification two approaches: on-chain check (contract checks balance at moment of use — simple, but balance can be temporarily borrowed) and snapshot + Merkle proof (rights fixed at specific moment — more reliable for seasonal perks).

Integration with physical world: QR code scanned at entrance, backend verifies signature signed by user wallet via WalletConnect. No private keys on device — just message signature.

Distribution and Tokenomics

Mistake #1 of fan tokens: entire supply sold via Socios/Chiliz exchange, club gets money immediately, but market saturated, price falls, holders unhappy. Sustainable model:

Typical fan-token allocation:

• 40% — public sale via Fan Token Offering (FTO): phased, not all at once
• 20% — club/organization: 2-3 year vesting, shows commitment
• 15% — engagement rewards: distributed to fans for activity (attending matches, poll participation, merch purchases)
• 15% — treasury: future partnerships, exchange listings
• 10% — team: vesting

Engagement rewards — most important for sustainability. Tokens should organically distribute to real fans, not just traders. Mechanics: ticket scan at match = token reward, poll participation = micro-reward, merch purchase with code = reward.

Chain and Listing

For fan tokens with real user base: not mainnet Ethereum (gas too high for microtransactions). Optimal options:

Chiliz Chain (CHZ): specialized for fan-tokens, own DEX (Chiliz DEX), Socios.com integration. If goal — maximum reach of existing audience.

Polygon PoS or Polygon zkEVM: cheap gas, large ecosystem, many ready tools. Optimal for independent launch without Socios tie-in.

Base: Coinbase L2, growing audience, good liquidity. Logical choice if target audience — North American market.

CEX listing — separate process with legal and compliance sides. DEX listing (Uniswap, QuickSwap) can be done independently by adding liquidity pool.

Legal Side

Fan tokens with governance rights — potentially securities in some jurisdictions. SEC (US) and ESMA (Europe) scrutinize them. Standard defense: token doesn't give club share, doesn't promise financial return, rights — purely for participation in non-commercial voting.

Project requires legal consultation before launch. Not optional.

Work Process

Tokenomics design (1-2 weeks). Allocation, engagement rewards mechanics, tier system perks, listing criteria.

Contract development (2-3 weeks). FanToken ERC-20 + FanPoll + EngagementRewards distributor + tests.

Audit (1-2 weeks). Contracts manage valuable assets — external audit mandatory.

Backend and frontend development (2-4 weeks). Admin panel for club, holder dashboard, WalletConnect integration.

FTO launch and listing. Timeline depends on chosen platform and jurisdiction.

Cost calculated after analytics.