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

Ми розробляємо платформи фан-токенів — від контрактів до мобільних додатків. Стикалися з ситуацією, коли клуб запускає свій токен, але ринок мертвий: обсяг торгів прямує до нуля, спреди величезні, і вболівальники втрачають інтерес. У цій статті розповімо, як уникнути таких проблем і побудувати стійку біржу.

Як влаштована біржа фан-токенів?

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

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

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

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

Розглянемо фан-токен 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 гарантує, що торгівля завжди можлива (навіть при відході маркет-мейкера), маркет-мейкер забезпечує нормальні спреди у звичайний час.

Наш концентрований AMM у 5 разів глибший за стандартний V2 пул при тій же ліквідності.

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

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

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

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

Factory і Registry

Кожен фан-токен — окремий 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

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

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

Vesting і emission schedule

Фан-токен клубу не повинен весь одразу бути в обігу — інакше при первинному продажі клуб дампить весь 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. Біржа фан-токенів повинна працювати без цих знань — інакше користувацька база обмежена crypto-нативними людьми, які складають малу частку аудиторії клубів.

• 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.

Мобільний додаток

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

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

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

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

Інтеграції

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

Фан-токен без 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 бонусів.

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

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

Backend: Node.js + TypeScript + PostgreSQL. Індексатор подій (через 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 (один фан-токен, базовий AMM, Web UI): 10-14 тижнів. Production платформа з multi-club підтримкою, мобільним додатком, embedded wallets, fiat on-ramp: 6-9 місяців.

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

Що входить у роботу

• Аналіз токеноміки та юридичний висновок
• Проектування архітектури смарт-контрактів
• Розробка та аудит контрактів (Foundry, Slither, Echidna)
• Backend і фронтенд під ключ
• Інтеграція embedded wallets та fiat on-ramp
• Розгортання в продакшен і моніторинг
• Документація та навчання команди
• Пост-релізна підтримка на 3 місяці

Чому обирають нас

За 5 років роботи ми реалізували 20+ блокчейн-проектів у сфері DeFi та Fan Tokens. Наші рішення економлять до 30% на gas порівняно з аналогами. Гарантуємо проходження аудиту провідними фірмами (Trail of Bits, CertiK).

Готові обговорити ваш проект?

Зв'яжіться з нами для оцінки. Отримайте консультацію з архітектури платформи — безкоштовно до 60 хвилин.