Разработка ERC-1155 токена (мульти-токен)

ERC-721 хорош для уникальных активов, ERC-20 — для взаимозаменяемых. Но что делать, когда вашему проекту нужны оба типа одновременно? Типичная ситуация: в игровом проекте золото и ресурсы — fungible токены, персонажи — NFT, зелья — semi-fungible (100 единиц одного типа). До появления ERC-1155 для этого требовалось деплоить несколько контрактов — дорого и неудобно. Мы разрабатываем единый мульти-токенный контракт на основе EIP-1155, который решает эту задачу с существенно меньшим gas overhead. В этой статье разберём технические детали: от проектирования ID схемы до интеграции с OpenSea. Наш опыт показывает, что переход на ERC-1155 снижает затраты на газ на 40–60%, что при активной торговле экономит тысячи долларов в месяц. Свяжитесь с нами для консультации — оценим ваш проект за 1 день.

Сравнение: ERC-1155 vs ERC-20+ERC-721

ERC-1155 выполняет batch transfers в 3 раза быстрее по газу по сравнению с отдельными ERC-20 и ERC-721 контрактами, что делает его идеальным для high-volume игр.

Как работает batch transfer в ERC-1155?

Главное преимущество — возможность передавать несколько токенов разного типа за одну транзакцию. Вместо N вызовов transferFrom:

// ERC-721: N транзакций
for (uint i = 0; i < tokenIds.length; i++) {
    nft.transferFrom(from, to, tokenIds[i]); // N*gas
}

// ERC-1155: одна транзакция
erc1155.safeBatchTransferFrom(from, to, ids, amounts, data); // ~gas

Экономия газа при batch transfer: 40–60% по сравнению с раздельными транзакциями. Это критично для игр с частыми внутриигровыми переводами. В одном из кейсов для MMORPG с 10 000 ежедневных транзакций мы сократили затраты на газ на $2 000 в месяц.

Почему стоит использовать OpenZeppelin для ERC-1155?

OpenZeppelin ERC1155 — проверенный и протестированный базовый контракт. Он корректно реализует callback-безопасность и включает полезные расширения. Мы всегда начинаем с него:

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Burnable.sol";
import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155URIStorage.sol";

contract GameItems is ERC1155, ERC1155Burnable, ERC1155Supply, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    mapping(uint256 => string) private _tokenURIs;

    constructor() ERC1155("") {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(MINTER_ROLE, msg.sender);
    }

    function mint(address to, uint256 id, uint256 amount, bytes memory data) external onlyRole(MINTER_ROLE) {
        _mint(to, id, amount, data);
    }

    function mintBatch(address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data) external onlyRole(MINTER_ROLE) {
        _mintBatch(to, ids, amounts, data);
    }
}

OpenZeppelin Contracts are audited by independent security firms and used in thousands of production contracts.

Проектирование ID схемы: наш подход на практике

Для сложных проектов (например, MMORPG с тысячами предметов) мы используем bit-packed ID — разные части uint256 кодируют категорию, редкость, тип и экземпляр. Это позволяет фильтровать токены без хранения дополнительных данных:

// Пример: верхние 128 бит = тип, нижние 128 = instance ID
uint256 constant TYPE_MASK = uint256(type(uint128).max) << 128;
uint256 constant NF_INDEX_MASK = type(uint128).max;

function getTokenType(uint256 id) internal pure returns (uint256) {
    return id & TYPE_MASK;
}

function isNonFungible(uint256 id) internal pure returns (bool) {
    return id & TYPE_MASK == id; // instance ID = 0 значит базовый тип
}

Такая схема даёт гибкость: внутри одного контракта можно выпускать как массовые расходники, так и легендарные мечи с уникальными ID. Для проектов с простой логикой подходит последовательная нумерация — дешевле на уровне вычислений, но сложнее в аналитике.

On-chain метаданные для простых токенов

Для базовых активов (игровая валюта, ресурсы) мы храним атрибуты прямо в контракте, генерируя JSON через uri():

function uri(uint256 id) public view override returns (string memory) {
    ItemDefinition memory item = itemDefinitions[id];
    return string(abi.encodePacked(
        'data:application/json;base64,',
        Base64.encode(bytes(abi.encodePacked(
            '{"name":"', item.name, '","description":"', item.description,
            '","attributes":[{"trait_type":"rarity","value":"', item.rarity, '"}]}'
        )))
    ));
}

Это исключает зависимость от внешнего API и снижает риски цензурирования.

Типичные ошибки и как их избежать

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

• Проектирование ID схемы под бизнес-логику
• Разработка смарт-контракта на Solidity с модульными тестами (Foundry)
• Развёртывание на Ethereum, Polygon, Arbitrum или BNB Chain
• Интеграция с OpenSea через EIP-2981 (роялти)
• Полная документация и поддержка после запуска

Почему выбирают нас

Мы занимаемся Web3-разработкой с 2018 года, реализовали 30+ проектов на Ethereum, Polygon и Solana. Каждый контракт проходит внутренний аудит с использованием Slither и Mythril. Гарантируем безопасность и соответствие стандартам.

Хотите обсудить разработку мульти-токен контракта? Напишите нам — оценим проект за 1 день. Закажите разработку ERC-1155 токена с гарантией безопасности и аудитом.

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