Розробка платформи fan-токенів (Chiliz-стиль)

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

Fan-токени — утилітарні токени спортивних клубів, музикантів, медіа-брендів. Chiliz ($CHZ) та платформа Socios.com популяризували концепцію: держатель токена FC Barcelona голосує за колір перчаток вратаря або отримує доступ до еклюзивного контенту. Токени торгуються — і тут виникає специфічна біржева задача: як зробити ринок для токенів з малою ринковою капіталізацією, неравномірною активністю (матч → всплиск, міжсезонье → тишина), та аудиторією, де значна частина людей ніколи не використовувала crypto.

Біржа fan-токенів — це не звичайний DEX. Тут важлива ліквідність (при малому обсязі AMM дає величезний slippage), onboarding (більшість користувачів без Web3 досвіду), та event-driven активність (потрібно витримувати пікові навантаження в дні матчів).

Архітектура ліквідності

Проблема тонкого ринку

Розглянемо fan-токен FC SomeClub з market cap $500K. Uniswap V2 пул з $50K liquidity (10% від market cap): покупка на $5K дає 9% price impact. Неприйнятно — користувач бачить "вы отримаєте на 9% менше чем показує ціна".

Рішень кілька, найкращий вибір залежить від очікуваного обсяг торгів:

Concentrated liquidity (Uniswap V3 стиль). Liquidity providers концентрують позиції в вузькому цінновому діапазоні. При тій же $50K ліквідності, сконцентрованій в ±5% від поточної ціни — ефективна глибина ринку еквівалентна $500K+ в V2 пулі. Проблема: якщо ціна виходить за пределы range — позиція стає 100% в одному токені (impermanent loss максимальний).

Virtual AMM (vAMM). Як у Perpetual Protocol: price discovery через віртуальний AMM, реальний коллатераль зберігається окремо. Немає реальних LP — протокол сам є market maker. Ризик: протокол приймає на себе directional exposure.

Order book + AMM гібрид. Limit orders виконуються з order book, решта — через AMM. CoW Protocol використовує подібну модель (batch auctions). Складніше в реалізації, але кращий UX для активних трейдерів.

Market maker програма. Off-chain маркет-мейкер (традиційний, через API) підключається до on-chain або централізованого orderbook. Клуб може субсидувати маркет-мейкера для підтримки спредів. Найпростіше рішення для запуску — не потрібно вирішувати проблему ліквідності on-chain, її вирішує професіональний учасник.

Для стартового запуску рекомендую hybrid: AMM як backstop ліквідності + incentivized market maker програма. AMM гарантує що торговля завжди можливра (навіть при уході маркет-мейкера), маркет-мейкер забезпечує хороші спреди в нормальний час.

Динаміка подій

В день крупного матчу торговий обсяг може вирости в 50-100x. Для on-chain AMM це не проблема (смарт-контракт масштабується). Для централізованої біржі або гібриду — потрібні load tests та горизонтальне масштабування бекенду.

Більш цікава цінова динаміка: за годину до матчу, при оголошенні стартового складу, при голі — ціна fan-токена різко рухається. AMM з фіксованим fee в такі моменти стає мішенню для MEV (front-running передбачуваних рухів). Рішення: dynamic fees (Uniswap V4 hooks дозволяють піднімати fee при високій волатильності), або trading pause в часі офіційних оголошень.

Смарт-контракти біржі

Factory та Registry

Кожен fan-токен — окремий ERC20 (або ERC20Votes якщо планується governance). Factory контракт деплоїть новий токен та створює для нього торгову пару:

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 зберігає метаданні клубів: логотип IPFS hash, опис, verified статус (клуб офіційно партнер або ні).

Торговий контракт з fee distribution

Fan-токен біржа заробляє на trading fee. Розподіл fee — ключовий токеномічний вопрос. Типова схема:

Fee distribution реалізується через fee controller контракт. При кожному swap — fee розділяється та відправляється в відповідні контракти (LP reward pool, club revenue contract, treasury).

Vesting та emission schedule

Fan-токен клубу не повинен весь сразу бути в обороті — іншче при першій продажі клуб дампить весь supply. Рекомендуємий розподіл:

• 30% — public sale / initial DEX offering
• 25% — клуб (4-year vesting, 1-year cliff)
• 20% — rewards pool (болільникам за активність: посещення матчів, покупки мерча)
• 15% — платформа (4-year vesting)
• 10% — liquidity (locked в пулі)

Vesting реалізується через стандартні контракти (TokenVesting від OpenZeppelin або аналог) з configurable cliff та linear vesting.

Користувальницький досвід та onboarding

Проблема Web3 onboarding

Болільник Барселони не знає що таке MetaMask. Біржа fan-токенів повинна працювати без цих знань — іншче користувацька база обмежена crypto-native людьми, які складають малу частину аудиторії клубів.

Embedded wallet (Account Abstraction). Privy, Dynamic, Web3Auth — провайдери embedded wallets. Користувач логінить через Google/Apple або email. Під капотом створюється smart account (ERC-4337), користувач не бачить seed phrase при реєстрації.

Account Abstraction (EIP-4337) також дозволяє газ абстракцію: платформа може спонсорувати газ (paymaster), користувач платить в USDC або взагалі не платить gas — важливо для retention серед crypto-новичків.

Fiat on-ramp. Moonpay, Transak, Stripe (для Ethereum-based активів) — інтегруються як SDK. Користувач купує токени картою, не знаючи що происходит on-chain.

Мобільне приложение

Fan-токен аудиторія — мобільна. React Native + WalletConnect + embedded wallet провайдер. Push notifications при значимих событях (гол, перемога — як тригер для торговлі). Deep links з матч-сторінок клубу на торговий екран.

Compliance та регулювання

Fan-токени в юрисдикції ЕС потенціально підпадають під MiCA (Markets in Crypto-Assets Regulation, застосовується з 2025). Якщо токен надає utility (права голоса, доступ до контенту) — це utility token, легший режим. Якщо токен переважно торгується як інвестиція — security token, важкий регуляторний шлях.

Для compliance: юридичне заключение по кожному токену, KYC/AML для користувачів з обсягом вище пороговых значень (типово €1000/день), whitelist/blacklist для санкційних адрес (Chainalysis або TRM Labs API).

Інтеграції

Клубний контент та перки

Fan-токен без utility — просто спекулятивний актив. Держатели повинні отримувати щось конкретне:

• Голосування (Governor-based): вибір дизайну джерсі, опросы про трансфери — off-chain Snapshot + on-chain proof of holding
• Access-gating: еклюзивний контент на сайті клубу через token-gating (Sign-in With Ethereum + balance check)
• Ticket priority: держатель N токенів отримує pre-sale доступ до квитків — інтеграція з ticketing системою клубу через API
• Physical rewards: QR-код в мобільному додатку (linked to wallet balance) для отримання скидок в клубному магазині

Oracle для спортивних даних

Для автоматичних перків за результатами матчів (бонусний дроп токенів при перемозі) потрібен oracle. Chainlink Sports Data Feeds або кастомний oracle через Chainlink Functions (off-chain API call → on-chain результат). При перемозі клубу — автоматичний snapshot holders та distribution бонусів.

Stack та архітектура

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

Backend: Node.js + TypeScript + PostgreSQL. Indexer подій (через Alchemy webhooks або The Graph), API для метаданих, market maker bot.

Frontend: Next.js + React + wagmi + Privy/Dynamic для embedded wallets. Mobile: React Native.

Infrastructure: Multi-chain (Polygon/Arbitrum для дешевих транзакцій), IPFS для media assets.

Процес та строки

MVP (один fan-токен, базовий AMM, Web UI): 10-14 тижнів. Production платформа з multi-club поддержкой, мобільним додатком, embedded wallets, fiat on-ramp: 6-9 місяців.

Аудит смарт-контрактів — обов'язковий перед запуском. Рекомендую виділити 4-6 тижнів на аудит + усунення знахідок паралельно з фінальним тестуванням.