ERC-621 verstehen: Der Standard für die Prägung und Vernichtung von Tokens

Die Elastizität des Tokenangebots – die Fähigkeit, neue Tokens zu prägen oder bestehende zu vernichten – ist entscheidend für die Funktionsweise von Stablecoins, RWA-Programmen, Treuepunkten und vielen Gaming-Assets. ERC-621 war ein früher Versuch, die Erhöhung oder Verringerung des Angebots von ERC-20-Tokens zu formalisieren und die Semantik für Prägung und Vernichtung zu standardisieren, um Werkzeuge und Wallet-Interoperabilität zu verbessern. Obwohl nicht so weit verbreitet wie das Kern-ERC-20, ist das Verständnis von ERC-621 immer noch wertvoll für Teams, die Token-Lebenszyklen entwerfen, und für Benutzer, die die Garantien eines Tokens bewerten.

Dieser Artikel erklärt, was ERC-621 tut, wie es sich im heutigen Ökosystem mit gängigen ERC-20-Erweiterungen vergleicht und worauf Entwickler und Schatzmeister achten sollten – insbesondere da Präge-/Vernichtungsoperationen nach dem Dencun-Upgrade von Ethereum zunehmend auf kostengünstige Layer-2-Netzwerke verlagert werden.

• ERC-20 Referenz: siehe den kanonischen Token-Standard auf Ethereum.org für Hintergrundinformationen zu Guthaben, Gesamtangebot und Ereignissen. Referenz: ERC-20 auf Ethereum.org.
• Dencun Kontext: Die Aktivierung des Mainnets senkte die Kosten für die Datenverfügbarkeit für Rollups, wodurch Token-Operationen mit hoher Frequenz auf L2s günstiger wurden. Referenz: Ankündigung des Dencun-Upgrades der 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

Was ist ERC-621?

ERC-621 schlägt eine Erweiterung von ERC-20 vor, die es einem Token-Vertrag ermöglicht, sein Gesamtangebot über standardisierte Funktionen und Ereignissemantik zu erhöhen oder zu verringern. Im Wesentlichen bietet es eine vereinbarte Methode, damit Prägung (Erhöhung des Angebots) und Vernichtung (Verringerung des Angebots) über Werkzeuge hinweg erkannt werden.

Schlüsselideen:

• Prägung erhöht totalSupply und schreibt Tokens einem Adress zu, wobei ein Transfer-Ereignis von der Nulladresse (address(0)) an den Empfänger emittiert wird.
• Vernichtung verringert totalSupply und bucht Tokens von einer Adresse ab, wobei ein Transfer-Ereignis vom Halter an die Nulladresse emittiert wird.
• Diese Semantik entspricht der Art und Weise, wie ERC-20-kompatible Tokens Prägung/Vernichtung auf der Ereignisebene darstellen sollen, was die Kompatibilität mit Explorern und Indexern verbessert.

Referenz: EIP-621 auf eips.ethereum.org.

Link:

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

Hinweis zum Status: ERC-621 wurde früh im Ökosystem vorgeschlagen und wird heute seltener referenziert als praktische ERC-20 "mintable/burnable"-Muster. Dennoch werden seine Konventionen auf Ereignisebene von gut implementierten ERC-20s, die Prägung/Vernichtung unterstützen, weitgehend befolgt.

Warum Angebotelastizität in 2024–2025 wichtig ist

• Stablecoins und RWAs: Emittenten prägen routinemäßig bei der Aufnahme neuer Sicherheiten und vernichten bei Einlösungen. Klare, prüfbare Ereignissemantiken sind für die Transparenz unerlässlich.
• L2-Operationen nach Dencun: Günstigere Stapeloperationen auf Rollups bedeuten häufigere Präge-/Vernichtungszyklen für anwendungsspezifische Tokens, ohne dass übermäßige Gaskosten anfallen. Referenz: Ethereum Dencun Roadmap-Seite.
• Compliance- und Lebenszyklussteuerungen: Treasury-Teams benötigen oft rollenbasierte Prägung, Vernichtung bei Einlösung oder geplante Emissionen, die bei Vorfällen pausiert werden können.

Link:

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

ERC-621 im Vergleich zu gängigen ERC-20-Mustern von heute

Obwohl ERC-621 eine formale Erweiterung für Prägung und Vernichtung definiert, implementieren viele Produktionsprojekte diese Funktionen mithilfe von weitgehend geprüften ERC-20-Bibliotheken und Zugriffssteuerungen:

• OpenZeppelin ERC-20-Erweiterungen:
  • Die Burnable-Erweiterung ermöglicht es Token-Inhabern (oder genehmigten Ausgebern), Tokens zu vernichten. Referenz: OpenZeppelin ERC20Burnable.
  • Rollenbasierte Zugriffssteuerung wird häufig verwendet, um die Prägung auf eine MINTER_ROLE oder den Eigentümer zu beschränken. Referenz: 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

Vorteile des gängigen OZ-Musters:

• Ausgereifter Code mit umfangreichen Audits und Community-Nutzung
• Flexible Rollentrennung (z. B. MINTER_ROLE, PAUSER_ROLE)
• Einfache Integration mit pausierbaren oder permit (EIP-2612) Funktionen

Abwägungen gegenüber striktem ERC-621:

• ERC-621 zielt auf standardisierte Funktionsnamen und Semantiken für Angebotsänderungen ab. Viele Tokens stellen diese exakten Funktionssignaturen nicht bereit, halten sich aber an die Ereignissemantiken (Nulladressen-Prägung/Vernichtung), auf die Indexer angewiesen sind.
• Tooling-Unterstützung ist heute bereits stark für ERC-20 Präge-/Vernichtungsereignisse, auch ohne explizite ERC-621-Schnittstellen.

Referenz für Permit-Flüsse: EIP-2612.

Link:

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

Ereignissemantik, die zählt

Auch wenn ein Token nicht die exakte Schnittstelle von ERC-621 implementiert, sind zwei ERC-20-kompatible Muster für transparente Angebotsänderungen von entscheidender Bedeutung:

• Prägung: emittiere Transfer(address(0), to, amount)
• Vernichtung: emittiere Transfer(from, address(0), amount)

Indexer, Wallets und Explorer verlassen sich auf diese Ereignisse, um Angebotsänderungen ohne spezielle Parsing-Logik zu verstehen. Dies ist genau die Ausrichtung, die ERC-621 kodifizieren wollte. Referenz: ERC-20 Token-Standard.

Link:

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

Ein minimales, modernes Implementierungsmuster

Unten finden Sie ein vereinfachtes Beispiel, das mit der ERC-621-Semantik übereinstimmt und dabei beliebte Werkzeuge verwendet. Es implementiert nicht die buchstäblichen ERC-621-Funktionssignaturen, emittiert aber die erwarteten Transfer-Ereignisse der Nulladresse und verwendet Rollen für die Sicherheit.

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

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

[contract](https://onekey.so/blog/de/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/de/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/de/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount); // Emittiert Transfer([address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount)
    }
    // Burn-Funktionen geerbt von ERC20Burnable (vom Halter initiiert)
}

• Die Prägung ist rollengesteuert und emittiert das Transfer-Ereignis der Nulladresse.
• Die Vernichtung ist opt-in für Halter oder genehmigte Ausgeber und emittiert den Transfer an die Nulladresse.

OpenZeppelin Referenzen:

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

Sicherheits- und Governance-Überlegungen

• Zugriffssteuerung und Aufgabentrennung
  • Verwenden Sie unterschiedliche Rollen für MINTER, PAUSER und DEFAULT_ADMIN. Vermeiden Sie eine einzige EOA für alle Befugnisse.
  • Bevorzugen Sie Multisig oder Modul-basierte Verwaltung, um das Risiko eines einzelnen Schlüssels zu reduzieren. Ein bekannter Ansatz ist die Platzierung von Admin-Rollen hinter einem dedizierten Multisig. Referenz: Safe-Dokumentation zu dem, was ein Safe ist.
• Pausieren und Notbremsen
  • Pausierbare Verträge helfen bei der Reaktion auf Vorfälle oder Oracle-Ausfälle.
• Audits und Best Practices
  • Befolgen Sie etablierte Sicherheitsrichtlinien für Upgradefähigkeit, Initialisierung und Rollenentzug. Referenz: Ethereum Smart Contract Best Practices von ConsenSys Diligence.

Links:

• Safe Übersicht: https://docs.safe.global/learn/what-is-safe
• Best Practices für Smart Contracts: https://consensys.github.io/smart-contract-best-practices/

L2- und Bridging-Nuancen

• Kanonische vs. gebrückte Tokens
  • Wenn Ihr Token auf einem L2 kanonisch ist, erfolgt die Prägung oft direkt auf diesem L2; Bridges spiegeln dann das Angebot in anderen Netzwerken wider.
  • Wenn kanonisch auf L1, überlegen Sie, wer berechtigt ist, L2-Repräsentationen zu prägen und wie Bridge-Verträge diese Berechtigung regeln.
• Stapeloperationen
  • Erwägen Sie Stapelprägung/-einlösungen, um Kosten zu minimieren und die Klarheit der Buchhaltung auf Rollups zu verbessern, die nach Dencun erheblich günstiger sind. Referenz: Ethereum Dencun Übersicht.

Link:

• Dencun Übersicht: https://ethereum.org/en/roadmap/dencun/

So bewerten Sie einen Token, der prägen oder vernichten kann

Für Benutzer und Integratoren:

• Lesen Sie den Code oder die verifizierte Quelle
  • Prüfen Sie, ob die Prägung rollengesteuert ist; identifizieren Sie den Controller (EOA, Multisig, DAO).
• Überprüfen Sie die Ereignissemantik
  • Suchen Sie nach Standard Transfer-Ereignissen zur/von der Nulladresse für Angebotsänderungen.
• Überprüfen Sie die Upgradefähigkeit
  • Wenn upgradebar, verstehen Sie, wer upgraden kann und nach welchem Prozess.

Explorer- und Dokumentationsreferenzen helfen hier:

• ERC-20 Standard Übersicht: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
• ERC-621 Vorschlagsdetails: https://eips.ethereum.org/EIPS/eip-621

Sollten Sie ERC-621 heute übernehmen?

• Wenn Sie explizite Funktionssignaturen für die Angebotsverwaltung wünschen, auf die Wallets oder Middleware abzielen können, bietet ERC-621 eine klar benannte Schnittstelle.
• Wenn Sie bereits auf OpenZeppelin-Muster zurückgreifen, erfüllen Sie wahrscheinlich die wichtigen Teile des ERC-621-Geistes – standardmäßige Transfer-Ereignisse der Nulladresse – und profitieren gleichzeitig von geprüften Bibliotheken und flexiblem Rollendesign.
• Wählen Sie, was Sie wollen, dokumentieren Sie Ihre Präge-/Vernichtungspolitik (wer prägen kann, wann, Obergrenzen, Auditprozess) und machen Sie sie für Integratoren lesbar.

Abschließende Gedanken und eine praktische Empfehlung

Prägung und Vernichtung sind mächtige Hebel, die eine strenge Governance erfordern. Ob Sie die explizite Schnittstelle von ERC-621 übernehmen oder bei weit verbreiteten ERC-20-Erweiterungen bleiben, die wichtigsten Aspekte sind standardisierte Ereignissemantik, klares Rollendesign und sicheres Schlüsselmanagement – insbesondere da die Aktivität bei Emission und Einlösung auf L2s im Jahr 2025 zunimmt.

Für operative Sicherheit bewahren Sie Präge- und Admin-Schlüssel in dedizierten Cold Storage auf und verlangen Sie Multisig-Genehmigungen für sensible Aktionen. OneKey Hardware Wallets können als sichere Signierer für Treasury- und Admin-Rollen über EVM-Netzwerke hinweg dienen und sich in beliebte Multisig-Setups und dApps integrieren. Die Verwendung eines Hardware Wallets zum Mitunterzeichnen von Präge-/Vernichtungs- und Rollenverwaltungs-Transaktionen hilft, das Risiko eines Single Point of Failure zu reduzieren und gleichzeitig effiziente Arbeitsabläufe für Ihre Token-Operationen aufrechtzuerhalten.