Compreendendo o ERC-621: O Padrão para Mintar e Queimar Tokens

A elasticidade do fornecimento de tokens – a capacidade de criar novos tokens ou queimar os existentes – é central para o funcionamento de stablecoins, programas de RWA (Ativos do Mundo Real), pontos de fidelidade e muitos ativos de jogos. O ERC-621 foi uma tentativa inicial de formalizar como os tokens ERC-20 podem aumentar ou diminuir o fornecimento, padronizando a semântica de mintar e queimar para melhorar as ferramentas e a interoperabilidade das carteiras. Embora não seja tão amplamente adotado quanto o ERC-20 principal, entender o ERC-621 ainda é valioso para equipes que projetam ciclos de vida de tokens e para usuários que avaliam as garantias que um token oferece.

Este artigo explica o que o ERC-621 faz, como ele se compara às extensões comuns do ERC-20 no ecossistema atual e o que construtores e tesoureiros devem observar – especialmente à medida que as operações de mintar/queimar se movem cada vez mais para redes de Camada 2 de baixo custo após a atualização Dencun do Ethereum.

• Referência ERC-20: consulte o padrão canônico de token em Ethereum.org para obter informações básicas sobre saldos, totalSupply e eventos. Referência: ERC-20 em Ethereum.org.
• Contexto Dencun: a ativação da rede principal reduziu os custos de disponibilidade de dados para rollups, tornando as operações de token de alta frequência mais baratas em L2s. Referência: Anúncio Dencun da Ethereum Foundation.

Links:

• ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
• Dencun: https://blog.ethereum.org/2024/03/13/dencun-mainnet

O que é ERC-621?

O ERC-621 propõe uma extensão ao ERC-20 que permite que um contrato de token aumente ou diminua seu fornecimento total por meio de funções e semânticas de eventos padronizadas. Essencialmente, ele fornece uma maneira acordada para que a criação (aumento do fornecimento) e a queima (diminuição do fornecimento) sejam reconhecidas pelas ferramentas.

Ideias chave:

• A criação aumenta o totalSupply e credita tokens a um endereço, emitindo um evento Transfer do endereço zero (address(0)) para o destinatário.
• A queima diminui o totalSupply e debita tokens de um endereço, emitindo um evento Transfer do detentor para o endereço zero.
• Essas semânticas estão alinhadas com a forma como se espera que os tokens compatíveis com ERC-20 representem a criação/queima na camada de eventos, melhorando a compatibilidade com exploradores e indexadores.

Referência: EIP-621 em eips.ethereum.org.

Link:

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

Nota de status: O ERC-621 foi proposto no início do ecossistema e é menos referenciado hoje do que os padrões práticos de "mintable/burnable" do ERC-20. Ainda assim, suas convenções de nível de evento são amplamente seguidas por ERC-20 bem implementados que suportam criação/queima.

Por que a elasticidade do fornecimento importa em 2024–2025

• Stablecoins e RWAs: os emissores criam rotineiramente quando novas garantias são embarcadas e queimam quando ocorrem resgates. Semânticas de eventos claras e auditáveis são essenciais para a transparência.
• Operações L2 após Dencun: operações em lote mais baratas em rollups significam ciclos mais frequentes de criação/queima para tokens específicos de aplicativos sem custos de gás punitivos. Referência: Página do roteiro Dencun do Ethereum.
• Controles de conformidade e ciclo de vida: as equipes de tesouraria geralmente precisam de criação com restrição de função, queima mediante resgate ou emissões agendadas que podem ser pausadas durante incidentes.

Link:

• Roteiro Dencun: https://ethereum.org/en/roadmap/dencun/

ERC-621 vs. Padrões Comuns de ERC-20 Atuais

Embora o ERC-621 defina uma extensão formal de criação/queima, muitos projetos em produção implementam criação e queima usando bibliotecas ERC-20 amplamente auditadas e controle de acesso:

• Extensões ERC-20 da OpenZeppelin:
  • A extensão Burnable permite que os detentores de tokens (ou gastos aprovados) destruam tokens. Referência: OpenZeppelin ERC20Burnable.
  • O controle de acesso baseado em função é comumente usado para restringir a criação a uma MINTER_ROLE ou proprietário. Referência: OpenZeppelin AccessControl.

Links:

• 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

Prós do padrão comum da OZ:

• Código maduro com auditoria e uso comunitário extensivos
• Separação flexível de funções (por exemplo, MINTER_ROLE, PAUSER_ROLE)
• Fácil integração com recursos pausáveis ou permit (EIP-2612)

Compromissos vs. ERC-621 estrito:

• O ERC-621 visa nomes de função e semânticas padronizados para alterações de fornecimento. Muitos tokens não expõem essas assinaturas de função exatas, mas ainda aderem às semânticas de eventos (criação/queima pelo endereço zero) em que os indexadores confiam.
• O suporte de ferramentas hoje já é forte para eventos de criação/queima de ERC-20, mesmo sem interfaces ERC-621 explícitas.

Referência para fluxos de permit: EIP-2612.

Link:

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

Semânticas de Eventos que Importam

Mesmo que um token não implemente a interface exata do ERC-621, dois padrões compatíveis com ERC-20 são críticos para alterações transparentes de fornecimento:

• Criação: emitir Transfer(address(0), to, amount)
• Queima: emitir Transfer(from, address(0), amount)

Indexadores, carteiras e exploradores confiam nesses eventos para entender as alterações de fornecimento sem lógica de análise personalizada. É precisamente esse alinhamento que o ERC-621 buscou codificar. Referência: Padrão de token ERC-20.

Link:

• Padrão ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/

Um Padrão de Implementação Mínimo e Moderno

Abaixo está um exemplo simplificado que se alinha com a semântica do ERC-621, utilizando ferramentas populares. Ele não implementa as assinaturas literais de função do ERC-621, mas emite os eventos Transfer esperados a partir do endereço zero e usa funções para segurança.

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

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.[sol](https://onekey.so/blog/pt/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/pt/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.[sol](https://onekey.so/blog/pt/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/pt/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/pt/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/pt/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount); // Emite Transfer([address](https://onekey.so/blog/pt/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount)
    }
    // Funções de queima herdadas de ERC20Burnable (iniciadas pelo detentor)
}

• A criação é restrita por função e emite o evento Transfer do endereço zero.
• A queima é opcional para detentores ou gastos aprovados, emitindo o Transfer para o endereço zero.

Referências da OpenZeppelin:

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

Considerações de Segurança e Governança

• Controle de acesso e separação de funções
  • Use funções distintas para MINTER, PAUSER e DEFAULT_ADMIN. Evite um único EOA para todos os poderes.
  • Prefira administração baseada em multisig ou módulo para reduzir o risco de chave única. Uma abordagem conhecida é colocar as funções administrativas por trás de um multisig dedicado. Referência: Documentação da Safe sobre o que é uma Safe.
• Pausa e disjuntores
  • Contratos pausáveis ajudam a responder a incidentes ou falhas de oráculos.
• Auditorias e melhores práticas
  • Siga as diretrizes de segurança estabelecidas para atualizabilidade, inicialização e revogação de funções. Referência: Melhores Práticas para Contratos Inteligentes do Ethereum pela ConsenSys Diligence.

Links:

• Visão geral da Safe: https://docs.safe.global/learn/what-is-safe
• Melhores práticas de contratos inteligentes: https://consensys.github.io/smart-contract-best-practices/

Nuances de L2 e Ponte

• Tokens Canônicos vs. Tokens Ponteados
  • Se o seu token for canônico em uma L2, a criação geralmente ocorre diretamente nessa L2; as pontes refletem então o fornecimento em outras redes.
  • Se for canônico em L1, considere quem está autorizado a criar representações em L2 e como os contratos de ponte controlam essa autoridade.
• Operações em lote
  • Considere a criação/resgate em lote para minimizar custos e melhorar a clareza contábil em rollups, que são muito mais baratos após o Dencun. Referência: Visão geral do Dencun do Ethereum.

Link:

• Visão geral do Dencun: https://ethereum.org/en/roadmap/dencun/

Como Avaliar um Token que Pode Criar ou Queimar

Para usuários e integradores:

• Leia o código ou a fonte verificada
  • Verifique se a criação é restrita por função; identifique o controlador (EOA, multisig, DAO).
• Verifique a semântica dos eventos
  • Procure eventos Transfer padrão de/para o endereço zero para alterações de fornecimento.
• Revise a atualizabilidade
  • Se for atualizável, entenda quem pode atualizar e sob qual processo.

Referências de exploradores e documentação ajudam aqui:

• Visão geral do padrão ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
• Detalhes da proposta ERC-621: https://eips.ethereum.org/EIPS/eip-621

Você Deve Adotar o ERC-621 Hoje?

• Se você deseja assinaturas de função explícitas para gerenciamento de fornecimento que carteiras ou middleware possam direcionar, o ERC-621 fornece uma interface claramente nomeada.
• Se você já confia nos padrões da OpenZeppelin, provavelmente atende às partes importantes do espírito do ERC-621 – eventos Transfer padronizados para o endereço zero – ao mesmo tempo em que se beneficia de bibliotecas auditadas e design flexível de funções.
• Qualquer que seja a sua escolha, documente sua política de criação/queima (quem pode criar, quando, limites, processo de auditoria) e torne-a legível para os integradores.

Considerações Finais e uma Recomendação Prática

A criação e a queima são alavancas poderosas que exigem governança rigorosa. Se você adotar a interface explícita do ERC-621 ou se apegar às extensões ERC-20 amplamente utilizadas, os aspectos mais importantes são semânticas de eventos padronizadas, design claro de funções e gerenciamento seguro de chaves – especialmente à medida que a atividade de emissão e resgate se acelera nas L2s em 2025.

Para segurança operacional, mantenha as chaves de criação e de administração em armazenamento frio dedicado e exija aprovações de multisig para ações sensíveis. As carteiras de hardware OneKey podem servir como signatários seguros para funções de tesouraria e administração em redes EVM, integrando-se com configurações populares de multisig e dApps. Usar uma carteira de hardware para coassinar transações de criação/queima e gerenciamento de funções ajuda a reduzir o risco de ponto único de falha, ao mesmo tempo que preserva fluxos de trabalho eficientes para as operações do seu token.