Comprendiendo ERC-621: El estándar para acuñar y quemar tokens

La elasticidad de la oferta de tokens —la capacidad de acuñar nuevos tokens o quemar los existentes— es fundamental para el funcionamiento de stablecoins, programas de RWA, puntos de fidelidad y muchos activos de juegos. ERC-621 fue un intento temprano de formalizar cómo los tokens ERC-20 pueden aumentar o disminuir su oferta, estandarizando la semántica de acuñar y quemar para mejorar las herramientas y la interoperabilidad de las billeteras. Aunque no está tan extendido como el ERC-20 principal, comprender ERC-621 sigue siendo valioso para los equipos que diseñan ciclos de vida de tokens y para los usuarios que evalúan las garantías que proporciona un token.

Este artículo explica qué hace ERC-621, cómo se compara con extensiones comunes de ERC-20 en el ecosistema actual y qué deben tener en cuenta los constructores y tesoreros, especialmente a medida que las operaciones de acuñación/quema se trasladan cada vez más a redes de Capa 2 de bajo costo después de la actualización Dencun de Ethereum.

• Referencia ERC-20: consulte el estándar canónico de tokens en Ethereum.org para obtener información sobre saldos, totalSupply y eventos. Referencia: ERC-20 en Ethereum.org.
• Contexto Dencun: la activación de la red principal redujo los costos de disponibilidad de datos para los rollups, haciendo que las operaciones de tokens de alta frecuencia sean más baratas en L2. Referencia: Anuncio de Dencun de la Fundación Ethereum.

Enlaces:

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

¿Qué es ERC-621?

ERC-621 propone una extensión de ERC-20 que permite a un contrato de token aumentar o disminuir su oferta total a través de funciones estandarizadas y semántica de eventos. En esencia, proporciona una forma acordada para que la acuñación (aumento de la oferta) y la quema (disminución de la oferta) sean reconocidas por las herramientas.

Ideas clave:

• La acuñación aumenta totalSupply y acredita tokens a una dirección, emitiendo un evento Transfer desde la dirección cero (address(0)) al destinatario.
• La quema disminuye totalSupply y debita tokens de una dirección, emitiendo un evento Transfer desde el poseedor a la dirección cero.
• Esta semántica se alinea con la forma en que se espera que los tokens compatibles con ERC-20 representen la acuñación/quema a nivel de evento, mejorando la compatibilidad con exploradores e indexadores.

Referencia: EIP-621 en eips.ethereum.org.

Enlace:

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

Nota de estado: ERC-621 se propuso en una etapa temprana del ecosistema y hoy en día se hace referencia a él con menos frecuencia que a los patrones prácticos de "acuñable/quemable" de ERC-20. Aun así, sus convenciones a nivel de evento son seguidas ampliamente por los ERC-20 bien implementados que admiten acuñación/quema.

Por qué la elasticidad de la oferta importa en 2024-2025

• Stablecoins y RWAs: los emisores acuñan rutinariamente cuando se incorpora nueva garantía y queman cuando ocurren rescates. La semántica de eventos clara y auditable es esencial para la transparencia.
• Operaciones L2 después de Dencun: las operaciones por lotes más baratas en rollups significan ciclos de acuñación/quema más frecuentes para tokens específicos de aplicaciones sin costos de gas prohibitivos. Referencia: Página del hoja de ruta Dencun de Ethereum.
• Controles de cumplimiento y ciclo de vida: los equipos de tesorería a menudo necesitan acuñación controlada por roles, quema por rescate o emisiones programadas que se pueden pausar durante incidentes.

Enlace:

• Hoja de ruta Dencun: https://ethereum.org/en/roadmap/dencun/

ERC-621 vs. Patrones comunes de ERC-20 actuales

Aunque ERC-621 define una extensión formal de acuñación/quema, muchos proyectos en producción implementan la acuñación y quema utilizando bibliotecas ERC-20 ampliamente auditadas y control de acceso:

• Extensiones ERC-20 de OpenZeppelin:
  • La extensión Burnable permite a los poseedores de tokens (o a los gastadores aprobados) destruir tokens. Referencia: OpenZeppelin ERC20Burnable.
  • El control de acceso basado en roles se utiliza comúnmente para restringir la acuñación a un MINTER_ROLE o propietario. Referencia: OpenZeppelin AccessControl.

Enlaces:

• 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

Ventajas del patrón común de OZ:

• Código maduro con auditorías extensas y uso comunitario.
• Separación de roles flexible (por ejemplo, MINTER_ROLE, PAUSER_ROLE).
• Fácil integración con características pausables o permit (EIP-2612).

Compromisos vs. ERC-621 estricto:

• ERC-621 se centra en nombres de funciones y semántica estándar para cambios de suministro. Muchos tokens no exponen esas firmas de funciones exactas, pero aún así se adhieren a la semántica de eventos (acuñación/quema con dirección cero) en la que confían los indexadores.
• El soporte de herramientas hoy en día ya es sólido para los eventos de acuñación/quema de ERC-20, incluso sin interfaces ERC-621 explícitas.

Referencia para flujos de permit: EIP-2612.

Enlace:

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

Semántica de eventos que importan

Incluso si un token no implementa la interfaz exacta de ERC-621, dos patrones compatibles con ERC-20 son críticos para cambios de suministro transparentes:

• Acuñación: emitir Transfer(address(0), to, amount)
• Quema: emitir Transfer(from, address(0), amount)

Los indexadores, billeteras y exploradores confían en estos eventos para comprender los cambios de suministro sin lógica de análisis personalizada. Esto es exactamente la alineación que ERC-621 buscaba codificar. Referencia: Estándar de tokens ERC-20.

Enlace:

• Estándar ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/

Un patrón de implementación mínimo y moderno

A continuación, se muestra un ejemplo simplificado que se alinea con la semántica de ERC-621 al tiempo que utiliza herramientas populares. No implementa las firmas de funciones literales de ERC-621, pero emite los eventos Transfer esperados con dirección cero y utiliza roles para la seguridad.

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

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

[contract](https://onekey.so/blog/es/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/es/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/es/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount); // Emite Transfer([address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount)
    }
    // Funciones de quema heredadas de ERC20Burnable (iniciadas por el poseedor)
}

• La acuñación está controlada por roles y emite el evento Transfer con dirección cero.
• La quema es opcional por parte de los poseedores o gastadores aprobados, emitiendo el evento Transfer a la dirección cero.

Referencias de OpenZeppelin:

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

Consideraciones de seguridad y gobernanza

• Control de acceso y separación de funciones
  • Utilice roles distintos para MINTER, PAUSER y DEFAULT_ADMIN. Evite una única EOA para todos los poderes.
  • Prefiera la administración basada en multisig o módulos para reducir el riesgo de clave única. Un enfoque conocido es colocar los roles de administrador detrás de un multisig dedicado. Referencia: Documentación de Safe sobre qué es un Safe.
• Pausa y disyuntores
  • Los contratos pausables ayudan a responder a incidentes o fallos de oráculos.
• Auditorías y mejores prácticas
  • Siga las directrices de seguridad establecidas para la actualizabilidad, inicialización y revocación de roles. Referencia: Mejores prácticas para contratos inteligentes de Ethereum por ConsenSys Diligence.

Enlaces:

• Resumen de Safe: https://docs.safe.global/learn/what-is-safe
• Mejores prácticas para contratos inteligentes: https://consensys.github.io/smart-contract-best-practices/

Matices de L2 y puente

• Tokens canónicos vs. puenteados
  • Si su token es canónico en una L2, la acuñación a menudo ocurre directamente en esa L2; los puentes luego reflejan la oferta en otras redes.
  • Si es canónico en L1, considere quién está autorizado a acuñar representaciones en L2 y cómo los contratos puente controlan esa autoridad.
• Operaciones por lotes
  • Considere la acuñación/rescate por lotes para minimizar costos y mejorar la claridad contable en los rollups, que son mucho más baratos después de Dencun. Referencia: Descripción general de Dencun de Ethereum.

Enlace:

• Descripción general de Dencun: https://ethereum.org/en/roadmap/dencun/

Cómo evaluar un token que puede acuñarse o quemarse

Para usuarios e integradores:

• Lea el código o la fuente verificada
  • Compruebe si la acuñación está controlada por roles; identifique el controlador (EOA, multisig, DAO).
• Verifique la semántica de eventos
  • Busque eventos Transfer estándar hacia/desde la dirección cero para cambios de suministro.
• Revise la actualizabilidad
  • Si es actualizable, comprenda quién puede actualizarlo y bajo qué proceso.

Las referencias de exploradores y documentación ayudan aquí:

• Descripción general del estándar ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
• Detalles de la propuesta ERC-621: https://eips.ethereum.org/EIPS/eip-621

¿Debería adoptar ERC-621 hoy?

• Si desea firmas de funciones explícitas para la gestión de suministro a las que las billeteras o el middleware puedan dirigirse, ERC-621 le proporciona una interfaz claramente nombrada.
• Si ya confía en los patrones de OpenZeppelin, es probable que cumpla con las partes importantes del espíritu de ERC-621 —eventos Transfer estándar con dirección cero— al tiempo que se beneficia de bibliotecas auditadas y un diseño de roles flexible.
• Elija lo que elija, documente su política de acuñación/quema (quién puede acuñar, cuándo, límites, proceso de auditoría) y hágalo legible para los integradores.

Reflexiones finales y una recomendación práctica

La acuñación y la quema son palancas poderosas que requieren una gobernanza rigurosa. Ya sea que adopte la interfaz explícita de ERC-621 o se adhiera a las extensiones de ERC-20 ampliamente utilizadas, los aspectos más importantes son la semántica de eventos estandarizada, el diseño de roles claro y la gestión segura de claves, especialmente a medida que la actividad de emisión y rescate se acelera en L2 en 2025.

Para la seguridad operativa, mantenga las claves de acuñación y administración en almacenamiento en frío dedicado y requiera aprobaciones de multisig para acciones sensibles. Las billeteras de hardware OneKey pueden servir como firmantes seguros para roles de tesorería y administración en redes EVM, integrándose con configuraciones multisig y dApps populares. El uso de una billetera de hardware para co-firmar transacciones de acuñación/quema y gestión de roles ayuda a reducir el riesgo de punto único de fallo al tiempo que preserva flujos de trabajo eficientes para sus operaciones de tokens.