Разработка платформы creator-токенов под ключ

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

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

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

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

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

Разработка платформы creator-токенов

Мы разрабатываем платформы для выпуска персональных токенов создателей контента. Creator-токены позволяют стримерам, музыкантам и блогерам монетизировать аудиторию через эксклюзивный доступ, голосование и доли доходов. Friend.tech довёл эту модель до $100M+ объёма торгов за несколько недель, породив волну клонов. Rally, Roll, Bitclout/DeSo пытались до него, но техническая реализация и экономический дизайн — ключевые факторы успеха.

Почему создание платформы creator-токенов — нетривиальная задача?

Главный вопрос не «как выпустить ERC-20» — это тривиально. Проблема в экономике, которая создаёт ценность и для создателя, и для держателей, а не просто спекулятивный pump-and-dump. Bonding curve, комиссии, механизмы utility — каждый компонент требует тонкой настройки.

Как работает bonding curve?

Friend.tech использует bonding curve — автоматический маркет-мейкер, где цена токена детерминированно определяется текущим supply. Нет order book, нет LP, нет внешней ликвидности. Простейшая линейная кривая: price = k * supply. Friend.tech использовал квадратичную формулу: price = supply² / divisor.

contract CreatorTokenBondingCurve {
    uint256 public constant DIVISOR = 16000;  // параметр кривой

    // Friend.tech formula: цена для N-го токена
    function getPrice(uint256 supply, uint256 amount) public pure returns (uint256) {
        uint256 sum1 = supply == 0 ? 0 : (supply - 1) * supply * (2 * (supply - 1) + 1) / 6;
        uint256 sum2 = (supply + amount - 1) * (supply + amount) * (2 * (supply + amount - 1) + 1) / 6;
        uint256 summation = sum2 - sum1;
        return summation * 1 ether / DIVISOR;
    }

    function getBuyPrice(address creator, uint256 amount) public view returns (uint256) {
        return getPrice(sharesSupply[creator], amount);
    }

    function getSellPrice(address creator, uint256 amount) public view returns (uint256) {
        return getPrice(sharesSupply[creator] - amount, amount);
    }
}

Спред между buy и sell. Из-за монотонно возрастающей кривой buy всегда дороже sell при том же supply. Это встроенный spread — основная защита от мгновенного arbitrage. При покупке 1 токена при supply=100 и немедленной продаже пользователь получает обратно меньше, чем заплатил (на величину spread).

Протокольная и creator комиссия. Friend.tech брал 10% от каждой транзакции: 5% в протокол, 5% создателю. Это пассивный доход для создателей с каждой покупки/продажи их токена.

uint256 constant PROTOCOL_FEE_PERCENT = 5;   // 5%
uint256 constant CREATOR_FEE_PERCENT  = 5;   // 5%

function buyShares(address creator, uint256 amount) external payable {
    uint256 supply = sharesSupply[creator];
    require(supply > 0 || creator == msg.sender, "Only creator can buy first share");

    uint256 price = getPrice(supply, amount);
    uint256 protocolFee = price * PROTOCOL_FEE_PERCENT / 100;
    uint256 creatorFee  = price * CREATOR_FEE_PERCENT  / 100;

    require(msg.value >= price + protocolFee + creatorFee, "Insufficient payment");

    sharesBalance[creator][msg.sender] += amount;
    sharesSupply[creator] = supply + amount;

    emit Trade(msg.sender, creator, true, amount, price, protocolFee, creatorFee, supply + amount);

    (bool success1,) = protocolFeeDestination.call{value: protocolFee}("");
    (bool success2,) = creator.call{value: creatorFee}("");
    require(success1 && success2, "Fee transfer failed");
}

Первый токен продаётся только самому создателю. Это предотвращает создание токена на чужое имя.

Проблемы bonding curve и альтернативы

Манипуляция при launch. Бот покупает первые N токенов создателя до того, как аудитория узнала о создателе. Цена уже высокая → органические покупатели переплачивают → бот продаёт. Mitigation: lock period для первых покупок, максимальная аллокация в первые часы, proof-of-humanity для создателей.

Концентрация у ранних покупателей. Первые держатели имеют самую низкую cost basis и могут в любой момент обвалить цену. Для платформы, ориентированной на долгосрочные сообщества, это системная проблема. Решения: vesting для creator-аллокации, lock-up через governance.

Отсутствие фундаментальной ценности. Если токен не даёт реальных привилегий — он чистая спекуляция. Friend.tech упал на 95%+ от пика, когда спекулятивный интерес иссяк и не оказалось utility.

Модель Преимущества Недостатки
Bonding curve Непрерывный рынок, автоматическая ликвидность Манипуляции, концентрация, спекуляция
Fixed supply + auction Прозрачность, нет манипуляции кривой Нет continuous market, сложность с ценой
NFT membership Нет спекуляции, чёткий utility Не fungible, сложнее трейдинг

Альтернативные модели:

  • Fixed supply с auction — создатель выпускает фиксированное количество, продаёт через Dutch auction. Прозрачно, но нет continuous market.
  • NFT membership — вместо fungible токенов используются NFT с tier-системой (Bronze/Gold/Platinum). Нет спекулятивной механики.
  • Revenue share token — ERC-20 с правом на долю доходов создателя. Реальный utility, но требует регуляторной проработки.

Какие utility механики реально работают?

Без utility creator-токен — спекулятивный инструмент. Список механик, которые реально работают:

Paywall контент. Доступ к exclusive контенту при балансе выше порога. Верификация off-chain через подпись кошелька (token-gating):

// Token-gating middleware
async function checkCreatorTokenAccess(
    walletAddress: string,
    creatorAddress: string,
    requiredBalance: number,
    provider: ethers.Provider
): Promise<boolean> {
    const contract = new ethers.Contract(PLATFORM_ADDRESS, ABI, provider);
    const balance = await contract.sharesBalance(creatorAddress, walletAddress);
    return balance >= requiredBalance;
}

Governance в сообществе. Голосование за контент. Вес голоса пропорционален балансу.

Revenue share. Часть доходов создателя распределяется держателям. Требует off-chain сбор данных, oracle или trusted verifier, Merkle distributor.

contract CreatorRevenueDistributor {
    struct Distribution {
        address creator;
        uint256 totalAmount;
        bytes32 merkleRoot;
        uint256 snapshotBlock;
        bool finalized;
    }

    mapping(uint256 => Distribution) public distributions;
    mapping(uint256 => mapping(address => bool)) public claimed;

    function claimRevenue(
        uint256 distributionId,
        uint256 amount,
        bytes32[] calldata proof
    ) external {
        Distribution storage dist = distributions[distributionId];
        require(!claimed[distributionId][msg.sender], "Already claimed");

        bytes32 leaf = keccak256(abi.encodePacked(msg.sender, amount));
        require(MerkleProof.verify(proof, dist.merkleRoot, leaf), "Invalid proof");

        claimed[distributionId][msg.sender] = true;
        payable(msg.sender).transfer(amount);

        emit RevenueClaimed(distributionId, msg.sender, amount);
    }
}

Ticket гарантии. Держатель N токенов получает guaranteed access к ивентам. Верификация через POAP или специализированный ticket NFT.

Социальный граф и discovery

Creator-токен платформа — не только контракты. Ключевой компонент — социальные features: discovery новых создателей, лента активности, leaderboard держателей.

On-chain события как социальный граф. Каждый Trade event — public информация о том, кто поддерживает какого создателя. Индексирование через The Graph:

type Trade @entity {
    id: ID!
    trader: Bytes!
    subject: Bytes!
    isBuy: Boolean!
    shareAmount: BigInt!
    ethAmount: BigInt!
    timestamp: BigInt!
    blockNumber: BigInt!
}

type Creator @entity {
    id: ID!
    address: Bytes!
    totalSupply: BigInt!
    holders: [Holder!]! @derivedFrom(field: "creator")
    totalTradingVolume: BigInt!
}

Social proof механика. Показывать «ваши друзья держат токены X» — мощный growth механизм. Требует знания social graph (Twitter/X API, Lens Protocol, Farcaster).

Мобильное-first: архитектурные решения

Creator-токен платформы почти всегда mobile-first. Это влияет на архитектуру:

Embedded wallet. Пользователи не хотят устанавливать MetaMask. Privy, Dynamic, Magic — embedded wallet SDKs с email/social login. Ключ хранится в secure enclave или MPC.

Gas abstraction. Пользователь платит в ETH, но процесс должен быть transparent. Account abstraction (EIP-4337) с paymaster — протокол спонсирует первые N транзакций нового пользователя.

Base chain. Friend.tech выбрал Base — Coinbase L2. Низкие комиссии (до $0.10 за транзакцию), быстрое подтверждение, хорошая ликвидность, поддержка Coinbase wallet нативно. Bonding curve на Base в 20 раз дешевле по газу, чем на Ethereum mainnet.

Каковы основные риски и как их минимизировать?

Rug pull создателем. Создатель владеет первым токеном (cheap entry), накапливает и продаёт при пике аудитории. Mitigation: lock период для creator shares, public disclosure creator holdings.

Wash trading. Искусственное накручивание объёма торгов. Сложно предотвратить полностью, но: minimum hold period перед sell, fee структура которая делает wash trading убыточным.

Сybersquatting. Регистрация токенов на имена популярных личностей до того как они сами пришли. Mitigation: верификация через OAuth (Twitter, Instagram), только верифицированные аккаунты могут создавать токены.

Этапы разработки платформы creator-токенов

  1. Анализ и проектирование экономики токена (1–2 недели): выбор модели bonding curve, определение комиссий, utility-механик.
  2. Разработка смарт-контрактов (4–6 недель): bonding curve, revenue share, governance, Merkle distributor.
  3. Backend и индексер (4–6 недель): The Graph, API, социальные фичи.
  4. Интеграция embedded wallet и account abstraction (2–3 недели).
  5. Мобильное приложение (6–10 недель): iOS + Android.
  6. Creator onboarding + KYC (1–2 недели).
  7. Аудит контрактов и формальная верификация (3–4 недели).
  8. Деплой, документация и поддержка.

Что входит в работу

  • Смарт-контракты: bonding curve, revenue share, governance, Merkle distributor
  • Backend: индексер (The Graph), API, социальные фичи
  • Embedded wallet интеграция + account abstraction
  • Мобильное приложение (iOS + Android)
  • Creator onboarding + KYC
  • Аудит контрактов и формальная верификация
  • Документация, деплой, поддержка после запуска

Сроки разработки

Компонент Срок
Смарт-контракты (bonding curve, revenue share, governance) 4–6 недель
Backend (индексер, API, social features) 4–6 недель
Embedded wallet интеграция + account abstraction 2–3 недели
Mobile приложение (iOS + Android) 6–10 недель
Creator onboarding + KYC 1–2 недели
Аудит контрактов 3–4 недели

MVP с bonding curve, базовым token gating и мобильным приложением: 3–4 месяца. Платформа с revenue share, governance и полноценными social features: 5–7 месяцев.

Наша команда имеет 10+ лет опыта в блокчейн-разработке и 50+ успешных проектов в области DeFi, NFT и социальных токенов. Проводим аудит контрактов с использованием Slither, Mythril и Echidna, гарантируя безопасность. Оценим ваш проект и предложим оптимальную архитектуру.

Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре и срокам.

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