Понимание ERC-621: Стандарт для выпуска и сжигания токенов

16 окт. 2025 г.

Ключевые выводы

• ERC-621 позволяет токенам ERC-20 увеличивать или уменьшать общее предложение.

• Четкая семантика событий важна для прозрачности операций с токенами.

• Стандарт ERC-621 не так широко используется, как ERC-20, но остается актуальным для разработчиков.

• Операции выпуска и сжигания становятся дешевле благодаря обновлениям Layer 2 в Ethereum.

• Использование проверенных библиотек, таких как OpenZeppelin, может обеспечить безопасность и гибкость.

Эластичность предложения токенов — возможность выпускать новые токены или сжигать существующие — является основой работы стейблкоинов, программ RWA, баллов лояльности и многих игровых активов. ERC-621 был ранней попыткой формализовать, как токены ERC-20 могут увеличивать или уменьшать предложение, стандартизируя семантику выпуска и сжигания для улучшения инструментов и совместимости кошельков. Несмотря на то, что он не получил такого широкого распространения, как основной стандарт ERC-20, понимание ERC-621 по-прежнему ценно для команд, разрабатывающих жизненные циклы токенов, и для пользователей, оценивающих гарантии, которые предоставляет токен.

В этой статье объясняется, что делает ERC-621, как он соотносится с распространенными расширениями ERC-20 в современной экосистеме, и на что следует обратить внимание разработчикам и казначеям — особенно в свете того, что операции выпуска/сжигания все чаще переходят на недорогие сети Layer 2 после обновления Dencun в Ethereum.

Справочник по ERC-20: см. канонический стандарт токенов на Ethereum.org для получения информации о балансах, общем предложении и событиях. Ссылка: ERC-20 на Ethereum.org.
Контекст Dencun: активация основной сети снизила затраты на доступность данных для роллапов, сделав высокочастотные операции с токенами более дешевыми на L2. Ссылка: Анонс Dencun от Ethereum Foundation.

Ссылки:

Что такое ERC-621?

ERC-621 предлагает расширение для ERC-20, которое позволяет контракту токена увеличивать или уменьшать свое общее предложение с помощью стандартизированных функций и семантики событий. По сути, он предоставляет согласованный способ распознавания выпуска (увеличение предложения) и сжигания (уменьшение предложения) различными инструментами.

Ключевые идеи:

Выпуск увеличивает totalSupply и зачисляет токены на адрес, генерируя событие Transfer от нулевого адреса (address(0)) получателю.
Сжигание уменьшает totalSupply и списывает токены с адреса, генерируя событие Transfer от держателя к нулевому адресу.
Эта семантика соответствует тому, как токены, совместимые с ERC-20, должны представлять выпуск/сжигание на уровне событий, улучшая совместимость с обозревателями и индексаторами.

Ссылка: EIP-621 на eips.ethereum.org.

Ссылка:

ERC-621: https://eips.ethereum.org/EIPS/eip-621

Примечание о статусе: ERC-621 был предложен на раннем этапе развития экосистемы и сегодня реже упоминается, чем практические шаблоны ERC-20 "mintable/burnable". Тем не менее, его соглашения на уровне событий широко соблюдаются хорошо реализованными ERC-20, поддерживающими выпуск/сжигание.

Почему эластичность предложения важна в 2024–2025 годах

Стейблкоины и RWA: эмитенты регулярно выпускают токены при зачислении нового обеспечения и сжигают их при погашении. Четкая, проверяемая семантика событий имеет решающее значение для прозрачности.
Операции L2 после Dencun: более дешевые пакетные операции на роллапах означают более частые циклы выпуска/сжигания для токенов, специфичных для приложений, без высоких затрат на газ. Ссылка: страница дорожной карты Dencun в Ethereum.
Соответствие требованиям и контроль жизненного цикла: казначейские команды часто нуждаются в выпуске, ограниченном ролями, сжигании при погашении или запланированных эмиссиях, которые могут быть приостановлены во время инцидентов.

Ссылка:

Дорожная карта Dencun: https://ethereum.org/en/roadmap/dencun/

ERC-621 в сравнении с современными распространенными шаблонами ERC-20

Хотя ERC-621 определяет формальное расширение для выпуска/сжигания, многие реальные проекты реализуют выпуск и сжигание с использованием широко проверенных библиотек ERC-20 и контроля доступа:

Расширения ERC-20 от OpenZeppelin:
- Расширение Burnable позволяет держателям токенов (или одобренным расходователям) уничтожать токены. Ссылка: OpenZeppelin ERC20Burnable.
- Контроль доступа на основе ролей (Role-Based Access Control) обычно используется для ограничения выпуска ролью MINTER_ROLE или владельцем. Ссылка: OpenZeppelin AccessControl.

Ссылки:

OpenZeppelin ERC20Burnable: https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Burnable
OpenZeppelin AccessControl: https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl

Преимущества распространенного шаблона OZ:

Зрелый код с обширными аудитами и использованием сообществом.
Гибкое разделение ролей (например, MINTER_ROLE, PAUSER_ROLE).
Простая интеграция с функциями Pausable или Permit (EIP-2612).

Компромиссы по сравнению со строгим ERC-621:

ERC-621 нацелен на стандартизированные имена функций и семантику изменений предложения. Многие токены не предоставляют именно эти сигнатуры функций, но при этом придерживаются семантики событий (выпуск/сжигание через нулевой адрес), на которые полагаются индексаторы.
Инструментальная поддержка сегодня уже сильна для событий выпуска/сжигания ERC-20, даже без явных интерфейсов ERC-621.

Справочник по потокам permit: EIP-2612.

Ссылка:

EIP-2612: https://eips.ethereum.org/EIPS/eip-2612

Семантика событий, которая имеет значение

Даже если токен не реализует точный интерфейс ERC-621, два шаблона, совместимых с ERC-20, имеют решающее значение для прозрачных изменений предложения:

Выпуск: сгенерировать Transfer(address(0), to, amount)
Сжигание: сгенерировать Transfer(from, address(0), amount)

Индексаторы, кошельки и обозреватели полагаются на эти события для понимания изменений предложения без специальной логики парсинга. Именно это соответствие ERC-621 стремился кодифицировать. Ссылка: стандарт токенов ERC-20.

Ссылка:

Стандарт ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/

Минимальный, современный шаблон реализации

Ниже приведен упрощенный пример, соответствующий семантике ERC-621 при использовании популярных инструментов. Он не реализует буквальные сигнатуры функций ERC-621, но генерирует ожидаемые события Transfer через нулевой адрес и использует роли для безопасности.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.[sol](https://onekey.so/blog/ru/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.[sol](https://onekey.so/blog/ru/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.[sol](https://onekey.so/blog/ru/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/ru/ecosystem/what-is-a-smart-contract/) ElasticToken is ERC20, ERC20Burnable, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    constructor(string memory name_, string memory symbol_, [address](https://onekey.so/blog/ru/ecosystem/what-is-a-crypto-wallet-address/) admin) ERC20(name_, symbol_) {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(MINTER_ROLE, admin);
    }

    function mint([address](https://onekey.so/blog/ru/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount); // Генерирует Transfer([address](https://onekey.so/blog/ru/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount)
    }
    // Функции сжигания, унаследованные от ERC20Burnable (инициируются держателем)
}

Выпуск контролируется ролями и генерирует событие Transfer от нулевого адреса.
Сжигание является добровольным для держателей или одобренных расходователей и генерирует событие Transfer к нулевому адресу.

Ссылки на OpenZeppelin:

ERC20Burnable: https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Burnable
AccessControl: https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl

Вопросы безопасности и управления

Контроль доступа и разделение обязанностей
- Используйте отдельные роли для MINTER, PAUSER и DEFAULT_ADMIN. Избегайте единого EOA для всех полномочий.
- Отдавайте предпочтение мультиподписям или модульному администрированию для снижения риска, связанного с одним ключом. Распространенный подход — размещение ролей администратора за выделенной мультиподписью. Ссылка: документация Safe о том, что такое Safe.
Приостановка и блокировка
- Контракты с возможностью приостановки помогают реагировать на инциденты или сбои оракулов.
Аудиты и лучшие практики
- Следуйте установленным рекомендациям по безопасности для обновлений, инициализации и отзыва ролей. Ссылка: Лучшие практики смарт-контрактов Ethereum от ConsenSys Diligence.

Ссылки:

Обзор Safe: https://docs.safe.global/learn/what-is-safe
Лучшие практики смарт-контрактов: https://consensys.github.io/smart-contract-best-practices/

Нюансы L2 и мостов

Канонические против мостовых токенов
- Если ваш токен является каноническим на L2, выпуск часто происходит напрямую на этом L2; мосты затем отражают предложение в других сетях.
- Если канонический на L1, рассмотрите, кто уполномочен выпускать токены на представлениях L2 и как контракт моста контролирует эту власть.
Пакетные операции
- Рассмотрите возможность пакетного выпуска/погашения, чтобы минимизировать затраты и улучшить ясность учета на роллапах, которые стали намного дешевле после Dencun. Ссылка: обзор Dencun в Ethereum.

Ссылка:

Обзор Dencun: https://ethereum.org/en/roadmap/dencun/

Как оценить токен, который может выпускаться или сжигаться

Для пользователей и интеграторов:

Прочитайте код или проверенный исходный код.
- Проверьте, контролируется ли выпуск ролями; определите контроллера (EOA, мультиподпись, DAO).
Проверьте семантику событий.
- Ищите стандартные события Transfer в/из нулевого адреса для изменений предложения.
Просмотрите возможность обновления.
- Если возможно обновление, поймите, кто может обновлять и по какому процессу.

Здесь помогут ссылки на обозреватели и документацию:

Обзор стандарта ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
Детали предложения ERC-621: https://eips.ethereum.org/EIPS/eip-621

Стоит ли вам сегодня принимать ERC-621?

Если вам нужны явные сигнатуры функций для управления предложением, на которые могут ориентироваться кошельки или промежуточное ПО, ERC-621 предоставляет вам четко названный интерфейс.
Если вы уже полагаетесь на шаблоны OpenZeppelin, вы, вероятно, соответствуете важным частям духа ERC-621 — стандартные события Transfer через нулевой адрес — при этом получая преимущества проверенных библиотек и гибкого дизайна ролей.
Что бы вы ни выбрали, документируйте свою политику выпуска/сжигания (кто может выпускать, когда, лимиты, процесс аудита) и сделайте ее понятной для интеграторов.

Заключительные мысли и практическая рекомендация

Выпуск и сжигание — это мощные рычаги, требующие строгого управления. Независимо от того, принимаете ли вы явный интерфейс ERC-621 или придерживаетесь широко используемых расширений ERC-20, наиболее важными аспектами являются стандартизированная семантика событий, четкий дизайн ролей и безопасное управление ключами — особенно в связи с ускорением деятельности по выпуску и погашению на L2 в 2025 году.

Для операционной безопасности храните ключи выпуска и администрирования в выделенной холодной памяти и требуйте одобрения мультиподписи для конфиденциальных действий. Аппаратные кошельки OneKey могут служить безопасными подписантами для казначейских и административных ролей в сетях EVM, интегрируясь с популярными настройками мультиподписей и dApps. Использование аппаратного кошелька для совместного подписания транзакций выпуска/сжигания и управления ролями помогает снизить риск единой точки отказа, сохраняя при этом эффективные рабочие процессы для ваших операций с токенами.