Разработка BRC-20 токена (Bitcoin Ordinals) под ключ

Запуск токена на Bitcoin через протокол Ordinals влечёт множество технических ловушек: двухшаговый transfer, зависимость от UTXO, разные индексеры. Мы — команда блокчейн-инженеров с 10+ летним опытом в Ethereum и Bitcoin. Разрабатываем BRC-20 токены под ключ: от деплоя JSON-контракта до создания собственного индексера и explorer. Закажите разработку BRC-20 токена под ключ — получите консультацию инженера.

Какие проблемы решает разработка BRC-20 токена?

Двухшаговый transfer: типичная ошибка новичков

Transfer BRC-20 — это не одна транзакция. Сначала создаётся transfer inscription на адрес отправителя. Затем эта inscription передаётся получателю через стандартную Bitcoin транзакцию. Индекстер фиксирует оба шага и засчитывает перевод только при отправке именно той UTXO, в которой находится transfer inscription. Если UTXO потрачена не туда — токены безвозвратно сжигаются. Комиссия сети Bitcoin за inscription обычно составляет от $5 до $15 в зависимости от нагрузки.

Зависимость от UTXO: как не потерять токены

BRC-20 баланс привязан к Bitcoin UTXO, содержащим inscriptions. Если кошелёк не aware об inscriptions и случайно потратит UTXO с inscription как обычный биткоин (fee bumping, объединение UTXO) — токены потеряны. Требуется специальный кошелёк, поддерживающий Ordinals.

Разные индексеры — разные балансы

В ранний период BRC-20 разные индексеры интерпретировали edge cases по-разному. Сейчас ситуация стабилизировалась, но при разработке обязательно сверять результаты на нескольких сервисах: Hiro, UniSat, OKX Ordinals.

Как работает BRC-20?

BRC-20 использует JSON-формат, записываемый в witness-часть SegWit транзакции. Всего три операции: deploy, mint, transfer. Каждая — отдельная Ordinals inscription.

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "MYTK",
  "max": "21000000",
  "lim": "1000"
}

{
  "p": "brc-20",
  "op": "mint",
  "tick": "MYTK",
  "amt": "1000"
}

{
  "p": "brc-20",
  "op": "transfer",
  "tick": "MYTK",
  "amt": "500"
}

Почему важен выбор индексера для BRC-20?

Индексеры — это off-chain сервисы, которые отслеживают inscriptions и вычисляют балансы. Разные индексеры могут давать разные результаты из-за неоднозначностей в обработке edge cases. Например, как обрабатывать double mint или transfer невалидной суммы. Поэтому важно выбрать надёжный индекстер и при необходимости запустить собственный.

Как мы разрабатываем BRC-20: стек и пример деплоя

Используем официальный клиент ord и API Ordinalsbot для создания inscriptions. Вот пример деплоя через TypeScript:

import axios from 'axios';

async function deployBRC20Token(config: {
    tick: string;
    max: string;
    lim: string;
    receiverAddress: string;
}) {
    const inscriptionData = JSON.stringify({
        p: "brc-20",
        op: "deploy",
        tick: config.tick,
        max: config.max,
        lim: config.lim,
    });
    const response = await axios.post('https://api.ordinalsbot.com/inscribe', {
        files: [{
            name: "deploy.json",
            size: Buffer.byteLength(inscriptionData),
            type: "text/plain;charset=utf-8",
            dataURL: `data:text/plain;charset=utf-8,${inscriptionData}`,
        }],
        receiveAddress: config.receiverAddress,
        fee: 15,
        lowPostage: false,
    });
    return response.data;
}

После деплоя проверяем балансы через индексеры. Hiro API — один из наиболее надёжных:

async function getBRC20Balance(address: string, ticker: string): Promise<string> {
    const response = await axios.get(
        `https://api.hiro.so/ordinals/v1/brc-20/balances/${address}`,
        {
            params: { ticker: ticker.toUpperCase() },
            headers: { 'x-api-key': process.env.HIRO_API_KEY },
        }
    );
    const token = response.data.results.find(
        (t: any) => t.ticker.toLowerCase() === ticker.toLowerCase()
    );
    return token?.overall_balance ?? "0";
}

Сравнение BRC-20 и ERC-20

BRC-20 в десятки раз дешевле при деплое, но уступает в гибкости. Экономия на деплое по сравнению с ERC-20 может достигать 90% (разработка смарт-контракта на Ethereum стоит от $2000). Для проектов, которым нужна программируемость, рекомендуем Stacks или Bitcoin L2.

Процесс работы над проектом

1. Аналитика — обсуждаем тикер, эмиссию, механизм распределения.
2. Проектирование — выбираем стек инструментов (ord, API, индексеры).
3. Реализация — деплой, написание mint-сервиса, интеграция с кошельками.
4. Тестирование — проверка на testnet, симуляция всех операций.
5. Деплой — публикация в mainnet, настройка мониторинга.

Что входит в проект

• Деплой BRC-20 токена с выбранным тикером и параметрами.
• Создание mint-сервиса для пользователей (если нужен fair launch).
• Интеграция с индексерами (Hiro, UniSat, OKX).
• Документация по использованию токена и API.
• Обучение команды заказчика работе с BRC-20.
• Поддержка в течение 2 недель после запуска.

Сроки ориентировочно

Простой деплой токена — несколько часов. Полноценная инфраструктура (индекстер, explorer, mint-сервис) — от 4 до 8 недель. Стоимость рассчитывается индивидуально в зависимости от объёма работ.

Наш опыт подтверждён десятками проектов. Гарантируем корректную работу всех компонентов. Используем проверенные инструменты и следуем лучшим практикам. Свяжитесь с нами для консультации — наши инженеры помогут с выбором тикера, развертыванием инфраструктуры и интеграцией с индексерами.

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