Fan Token Platform Development (Chiliz Style)

Fan-Token Exchange Platform Development

Fan tokens — utility tokens of sports clubs, musicians, media brands. Chiliz ($CHZ) and Socios.com platform popularized concept: Barcelona token holder votes on keeper's glove color or gets exclusive content access. Tokens trade — and here specific exchange task arises: how to make market for low-cap tokens with uneven activity (match → spike, off-season → quiet), and audience where significant part never used crypto.

Fan-token exchange — not regular DEX. Important here is liquidity (small volume AMM gives huge slippage), onboarding (most users without Web3 experience), and event-driven activity (must handle peak load on match days).

Liquidity Architecture

Problem of Thin Market

Consider fan-token FC SomeClub with market cap $500K. Uniswap V2 pool with $50K liquidity (10% of market cap): $5K purchase gives 9% price impact. Unacceptable — user sees "you'll get 9% less than shown price".

Several solutions, best choice depends on expected trading volume:

Concentrated liquidity (Uniswap V3 style). Liquidity providers concentrate positions in narrow price range. Same $50K liquidity concentrated within ±5% of current price — effective market depth equivalent to $500K+ in V2 pool. Problem: if price goes beyond range — position becomes 100% of one token (impermanent loss maximal).

Virtual AMM (vAMM). Like in Perpetual Protocol: price discovery via virtual AMM, real collateral stored separately. No real LPs — protocol is market maker itself. Risk: protocol takes directional exposure.

Order book + AMM hybrid. Limit orders executed from order book, rest — via AMM. CoW Protocol uses similar model (batch auctions). Harder to implement, but better UX for active traders.

Market maker program. Off-chain market maker (traditional, via API) connects to on-chain or centralized orderbook. Club can subsidize market maker for spread maintenance. Simplest solution for launch — no need solving on-chain liquidity, professional participant solves it.

For startup recommend hybrid: AMM as backstop liquidity + incentivized market maker program. AMM guarantees trading always possible (even if market maker leaves), market maker provides good spreads in normal time.

Event Dynamics

On big match day trading volume can spike 50-100x. For on-chain AMM not a problem (smart contract scales). For centralized exchange or hybrid — need load tests and horizontal backend scaling.

More interesting price dynamics: hour before match, on lineup announcement, on goal — fan-token price moves sharply. AMM with fixed fee becomes MEV target (front-running predictable moves). Solution: dynamic fees (Uniswap V4 hooks allow raising fee on high volatility), or trading pause during official announcements.

Exchange Smart Contracts

Factory and Registry

Each fan-token — separate ERC20 (or ERC20Votes if governance planned). Factory contract deploys new token and creates trading pair:

contract FanTokenFactory {
    mapping(address => address) public tokenToPool;
    
    event FanTokenCreated(
        address indexed token,
        address indexed pool,
        string clubName,
        uint256 initialSupply
    );
    
    function createFanToken(
        string calldata name,
        string calldata symbol,
        string calldata clubName,
        uint256 initialSupply,
        uint256 initialLiquidityETH
    ) external payable returns (address token, address pool) {
        require(msg.value == initialLiquidityETH, "Wrong ETH");
        
        // Deploy token
        token = address(new FanToken(name, symbol, initialSupply, msg.sender));
        
        // Create pool with initial liquidity
        pool = _createPool(token, initialSupply / 2, initialLiquidityETH);
        tokenToPool[token] = pool;
        
        emit FanTokenCreated(token, pool, clubName, initialSupply);
    }
}

Registry stores club metadata: logo IPFS hash, description, verified status (officially partner or not).

Trading Contract with Fee Distribution

Fan-token exchange earns on trading fee. Fee distribution — key tokenomic question. Typical scheme:

Fee distribution via fee controller contract. Each swap — fee split and sent to respective contracts (LP reward pool, club revenue contract, treasury).

Vesting and Emission Schedule

Fan-token of club shouldn't all be in circulation immediately — otherwise at initial sale club dumps entire supply. Recommended distribution:

• 30% — public sale / initial DEX offering
• 25% — club (4-year vesting, 1-year cliff)
• 20% — rewards pool (to fans for activity: match attendance, merch purchases)
• 15% — platform (4-year vesting)
• 10% — liquidity (locked in pool)

Vesting via standard contracts (TokenVesting from OpenZeppelin or similar) with configurable cliff and linear vesting.

User Experience and Onboarding

Web3 Onboarding Problem

Barcelona fan doesn't know MetaMask. Fan-token exchange must work without this knowledge — otherwise user base limited to crypto-native people, tiny portion of club audience.

Embedded wallet (Account Abstraction). Privy, Dynamic, Web3Auth — embedded wallet providers. User logs via Google/Apple or email. Under the hood smart account (ERC-4337) created, user doesn't see seed phrase on signup.

Account Abstraction (EIP-4337) also allows gas abstraction: platform can sponsor gas (paymaster), user pays in USDC or no gas at all — important for retention of crypto newcomers.

Fiat on-ramp. Moonpay, Transak, Stripe (for Ethereum-based assets) — integrate as SDK. User buys tokens with card, doesn't know what happens on-chain.

Mobile App

Fan-token audience — mobile. React Native + WalletConnect + embedded wallet provider. Push notifications on significant events (goal, win — trigger for trading). Deep links from club match pages to trading screen.

Compliance and Regulation

Fan tokens in EU potentially fall under MiCA (Markets in Crypto-Assets Regulation, applies from 2025). If token provides utility (voting rights, content access) — utility token, lighter regime. If token primarily traded as investment — security token, heavy regulatory path.

For compliance: legal opinion for each token, KYC/AML for users above threshold volumes (typically €1000/day), whitelist/blacklist for sanctioned addresses (Chainalysis or TRM Labs API).

Integrations

Club Content and Perks

Fan token without utility — just speculative asset. Holders should get something concrete:

• Voting (Governor-based): jersey design selection, transfer polls — off-chain Snapshot + on-chain proof of holding
• Access-gating: exclusive content on club site via token-gating (Sign-in With Ethereum + balance check)
• Ticket priority: N token holder gets pre-sale ticket access — ticketing system integration via API
• Physical rewards: QR-code in mobile app (linked to wallet balance) for shop discounts

Sports Data Oracle

For automatic perks based on match results (bonus token drop on victory) need oracle. Chainlink Sports Data Feeds or custom oracle via Chainlink Functions (off-chain API call → on-chain result). On victory — auto snapshot holders and bonus distribution.

Stack and Architecture

Smart contracts: Solidity + Foundry + OpenZeppelin. Factory, FanToken (ERC20Votes), Pool (Uniswap V3 fork or custom AMM), VestingController, FeeDistributor.

Backend: Node.js + TypeScript + PostgreSQL. Event indexer (via Alchemy webhooks or The Graph), metadata API, market maker bot.

Frontend: Next.js + React + wagmi + Privy/Dynamic for embedded wallets. Mobile: React Native.

Infrastructure: Multi-chain (Polygon/Arbitrum for cheap transactions), IPFS for media assets.

Process and Timeline

MVP (one fan-token, basic AMM, Web UI): 10-14 weeks. Production platform with multi-club support, mobile app, embedded wallets, fiat on-ramp: 6-9 months.

Smart contract audit — mandatory before launch. Recommend allocating 4-6 weeks for audit + finding remediation in parallel with final testing.