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

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

Мы разрабатываем платформы fan-токенов — от контрактов до мобильных приложений. Сталкивались с ситуацией, когда клуб запускает свой токен, но рынок мёртв: объём торгов стремится к нулю, спреды огромны, и болельщики теряют интерес. В этой статье расскажем, как избежать таких проблем и построить устойчивую биржу.

Как устроена биржа fan-токенов?

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

Биржа fan-токенов — это не обычный DEX. Здесь важна ликвидность (при малом объёме AMM даёт огромный слиппаж), 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 гарантирует что торговля всегда возможна (даже при уходе маркет-мейкера), маркет-мейкер обеспечивает нормальные спреды в нормальное время.

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

Динамика событий

В день крупного матча торговый объём может вырасти в 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-нативными людьми, которые составляют малую долю от аудитории клубов.

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, вступивший в силу недавно). Если токен предоставляет 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 бонусов.

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

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 (один fan-токен, базовый 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 минут.

Разработка токенов: ERC-20, токеномика, вестинг

«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.

ERC-20: что под капотом

Стандарт ERC-20 — девять функций. Сложность начинается с расширений:

ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.

ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.

Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.

Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.

Tokenomics: где математика превращается в экономику

Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.

Emission schedule и инфляция

Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.

Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.

Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.

Supply distribution

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.

Vesting контракты: детали имеют значение

Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типичные ошибки при реализации:

Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.

Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.

Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.

Liquidity Bootstrapping

Запуск ликвидности — критический момент. Три основных подхода:

Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.

Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.

Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.

TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.

Governance токены и voting механики

OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.

Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.

Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.

Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.

Стек для токен-разработки

Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling

Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации

Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue

Процесс

Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).

Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.

Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.

Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.

Сроки

• ERC-20 с permit и basic governance: 2–3 недели
• Vesting контракт с revocation и cliff: 2–4 недели
• Полный governance (Governor + Timelock + Token): 4–7 недель
• Токен + LBP + governance + vesting: 8–14 недель