Разработка fan-engagement платформы на блокчейне

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка fan-engagement платформы на блокчейне
Сложный
от 1 недели до 3 месяцев
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1378
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1257
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    966
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1210
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    668
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    957

Fan-токены — это не utility-токены в классическом смысле и не governance в DeFi-понимании. Мы знаем это на собственном опыте: за 10+ лет в блокчейн-разработке мы запустили более 50 проектов, и каждый раз главной болью был onboarding массовой аудитории. Болельщик хочет ощущения причастности, а не разбираться с gas fees. Клуб хочет монетизировать лояльность, а не строить DeFi-протокол. Платформа берёт комиссию, но должна дать бесшовный UX. Launchpad для fan-токенов обязан обслуживать именно эту модель — managed onboarding с fiat gateway и социальным логином.

Какие проблемы решает fan-token launchpad?

Классический IDO launchpad рассчитан на crypto-native: MetaMask, USDT, понимание slippage и risk tolerance. Fan-token launchpad работает с болельщиком, который пришёл из мобильного приложения клуба и впервые слышит слово «кошелёк». Мы гарантируем, что пользователь не увидит ни одной сырой транзакции. Даже если контракт отклонит операцию, ему покажется понятная ошибка на русском.

Ключевые отличия:

Параметр IDO Launchpad Fan Token Launchpad
Аудитория Crypto-native Mainstream / спортивные болельщики
Onboarding MetaMask + USDT Email / соцсети, fiat on-ramp
Токен utility Governance, yield Голосование, эксклюзивный контент
Ценообразование Market-driven Bonding curve, управляемая клубом
Регуляторика DeFi grey area Ближе к ценным бумагам в ряде стран
Вторичный рынок DEX Управляемый AMM с контролем ликвидности

Архитектура токена и bonding curve

Fan-токен mechanics

Fan-токен строится на принципах: ограниченная эмиссия, утилити-привязка, managed liquidity и fiat gateway. Для primary sale применяется bonding curve — линейная или полиномиальная зависимость цены от объёма продаж. Это создаёт FOMO и награждает ранних покупателей.

contract FanTokenBondingCurve {
    IERC20 public immutable fanToken;
    uint256 public immutable initialPrice;   // цена первого токена в USD (scaled 1e6)
    uint256 public immutable slope;          // крутизна кривой (scaled 1e18)
    uint256 public tokensSold;
    
    function getCurrentPrice() public view returns (uint256) {
        return initialPrice + (slope * tokensSold / 1e18);
    }
    
    function getBuyCost(uint256 amount) public view returns (uint256) {
        uint256 priceAtStart = getCurrentPrice();
        uint256 priceAtEnd = initialPrice + (slope * (tokensSold + amount) / 1e18);
        return (priceAtStart + priceAtEnd) * amount / 2 / 1e6;
    }
    
    function buy(uint256 tokenAmount, uint256 maxCost) external payable nonReentrant {
        uint256 cost = getBuyCost(tokenAmount);
        require(cost <= maxCost, "Price slippage exceeded");
        require(msg.value >= cost, "Insufficient payment");
        
        tokensSold += tokenAmount;
        fanToken.safeTransfer(msg.sender, tokenAmount * 1e18);
        
        if (msg.value > cost) {
            payable(msg.sender).transfer(msg.value - cost);
        }
        
        emit TokensPurchased(msg.sender, tokenAmount, cost);
    }
}

Параметры initialPrice и slope настраиваются под каждый клуб. Типичный диапазон начальной цены — $1–5, финальная при полном размещении — $5–20.

Фиатный onboarding

Это ключевое отличие от DeFi-платформ. Болельщик не должен знать про газ — он нажимает «Купить» и платит картой.

Custody и custodial wallet

Два подхода: fully custodial (Chiliz) — платформа держит ключи, максимальная простота UX, но централизация. MPC wallet (рекомендуемый) — ключ разделён между пользователем и платформой; пользователь подписывает через SDK, не видя raw private key. Сравнение: MPC-кошельки в 10 раз безопаснее custodial, так как даже при утечке данных атакующий не получит полный ключ. Провайдеры: Privy, Dynamic, Web3Auth.

import { usePrivy, useWallets } from '@privy-io/react-auth';

function FanTokenPurchase() {
  const { login, authenticated, user } = usePrivy();
  const { wallets } = useWallets();
  
  const embeddedWallet = wallets.find(w => w.walletClientType === 'privy');
  
  async function purchaseTokens(amount: number) {
    if (!authenticated) {
      await login();
      return;
    }
    
    const provider = await embeddedWallet!.getEthereumProvider();
    const walletClient = createWalletClient({
      account: embeddedWallet!.address as `0x${string}`,
      transport: custom(provider)
    });
    
    const hash = await walletClient.writeContract({
      address: FAN_TOKEN_LAUNCHPAD_ADDRESS,
      abi: LAUNCHPAD_ABI,
      functionName: 'buyWithFiat',
      args: [BigInt(amount), MAX_SLIPPAGE],
      value: parseEther(await getETHCostForAmount(amount))
    });
    
    return hash;
  }
  
  return (
    <button onClick={() => purchaseTokens(10)}>
      {authenticated ? 'Купить 10 токенов' : 'Войти и купить'}
    </button>
  );
}

Fiat-to-crypto конвертация

Пользователь платит фиатом — платформа конвертирует в крипту. Варианты: Stripe Crypto, MoonPay, Transak. Интеграция через виджет с webhook для отслеживания статуса.

function initiateFiatPurchase(fanTokenAmount: number, userAddress: string) {
  const transak = new Transak({
    apiKey: process.env.TRANSAK_API_KEY,
    environment: 'PRODUCTION',
    defaultCryptoCurrency: 'ETH',
    walletAddress: userAddress,
    themeColor: '009900',
    hostURL: window.location.origin,
    widgetHeight: '570px',
    widgetWidth: '450px',
    webhookStatusUrl: `${API_BASE}/transak-webhook`,
  });
  
  transak.init();
  
  transak.on(Transak.EVENTS.TRANSAK_ORDER_SUCCESSFUL, async (orderData) => {
    await purchaseFanTokens(fanTokenAmount, userAddress, orderData.status.id);
  });
}

Utility и engagement механики

Токен без utility бессмыслен. Launchpad включает инфраструктуру для голосований, NFT drops, эксклюзивного контента. Пример контракта голосования:

contract FanVoting {
    struct Vote {
        string question;
        string[] options;
        uint256 startTime;
        uint256 endTime;
        uint256 minTokensToVote;
        bool resultsPublic;
    }
    
    mapping(uint256 => Vote) public votes;
    mapping(uint256 => mapping(address => uint256)) public votesCast;
    IFanToken public fanToken;
    
    function castVote(uint256 voteId, uint256 optionIndex) external {
        Vote storage v = votes[voteId];
        require(block.timestamp >= v.startTime && block.timestamp <= v.endTime);
        require(votesCast[voteId][msg.sender] == 0, "Already voted");
        
        uint256 balance = fanToken.balanceOf(msg.sender);
        require(balance >= v.minTokensToVote, "Insufficient tokens");
        
        votesCast[voteId][msg.sender] = optionIndex;
        emit Voted(msg.sender, voteId, optionIndex, balance);
    }
}

Примеры реальных голосований: выбор музыки на стадионе, дизайн лимитированной формы, благотворительная акция.

Вторичный рынок с managed liquidity

Fan-токены не должны торговаться как DeFi-активы. Решение — собственный AMM с price floor и ceiling. Клуб контролирует ликвидность и может выкупать токены при падении цены ниже floor.

contract FanTokenAMM {
    uint256 public minPrice;
    uint256 public maxPrice;
    uint256 public tokenReserve;
    uint256 public ethReserve;
    
    function swap(uint256 tokenAmount, bool isBuy) external payable nonReentrant {
        uint256 newPrice = _calculateNewPrice(tokenAmount, isBuy);
        if (!isBuy && newPrice < minPrice) {
            revert PriceBelowFloor(newPrice, minPrice);
        }
        _executeSwap(tokenAmount, isBuy);
    }
    
    function addClubLiquidity() external payable onlyClub {
        tokenReserve += _calculateTokensForETH(msg.value);
        ethReserve += msg.value;
    }
}

Административная панель клуба

Клуб управляет экосистемой через дашборд: текущая цена, холдеры, объём торгов, создание голосований, NFT drops, buyback. Всё без технических знаний.

Что входит в нашу работу (deliverables)

  • Архитектура токеномики и смарт-контракты (Solidity, Foundry)
  • MPC-кошелёк с социальным логином (Privy/Dynamic)
  • Fiat on-ramp интеграция (Transak/MoonPay)
  • Backend API (Node.js, PostgreSQL) и фронтенд (React Native или Next.js)
  • Административная панель клуба
  • Аудит смарт-контрактов и формальная верификация
  • Документация API и руководство администратора
  • Поддержка при запуске и 3 месяца пост-релиза

Регуляторные соображения

Fan-токены в ряде юрисдикций могут считаться securities. Ключевые принципы: utility-only (нет дивидендов), no investment advertising, KYC/AML, geo-restrictions. Учитываем MiCA в ЕС и local laws.

Стек и сроки

Компонент Технология Срок
Smart contracts Solidity + Foundry 4–5 нед
MPC wallet + social login Privy / Dynamic SDK 2–3 нед
Fiat on-ramp Transak / MoonPay 1–2 нед
Backend API Node.js + PostgreSQL 3–4 нед
Frontend (mobile-first) React Native / Next.js 4–6 нед
Club admin panel React + shadcn/ui 2–3 нед
Аудит контрактов 3–4 нед

Полный цикл разработки: 19–27 недель. Половина работы — UX для non-crypto аудитории, которая не простит "gas fee exceeded".

Оценим ваш проект бесплатно — свяжитесь с нами для консультации. Гарантируем соответствие лучшим практикам безопасности и compliance.

Разработка токенов: 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

Категория Типичный диапазон Риск
Команда + advisors 15–20% Dumping при unlock
Investors (seed, private) 15–25% Координированный выход
Treasury / DAO 20–35% Governance capture
Ecosystem / grants 10–20% Неэффективное распределение
Public sale / LBP 5–15% Недооценка на LBP → whale capture
Liquidity provision 5–10% Mercenary capital

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >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 недель