Comprendre l'ERC-621 : La norme pour la création et la destruction de jetons

L'élasticité de l'offre de jetons — la capacité de créer de nouveaux jetons ou de détruire des jetons existants — est essentielle au fonctionnement des stablecoins, des programmes de RWA (actifs du monde réel), des points de fidélité et de nombreux actifs de jeu. L'ERC-621 a été une première tentative de formaliser la manière dont les jetons ERC-20 peuvent augmenter ou diminuer leur offre, en standardisant la sémantique de création et de destruction pour améliorer les outils et l'interopérabilité des portefeuilles. Bien qu'elle ne soit pas aussi largement adoptée que l'ERC-20 de base, la compréhension de l'ERC-621 reste précieuse pour les équipes concevant des cycles de vie de jetons et pour les utilisateurs évaluant les garanties qu'un jeton fournit.

Cet article explique ce que fait l'ERC-621, comment il se compare aux extensions ERC-20 courantes dans l'écosystème actuel, et ce à quoi les développeurs et les trésoriers doivent prêter attention — en particulier à mesure que les opérations de création/destruction migrent de plus en plus vers les réseaux de couche 2 (L2) à faible coût après la mise à niveau Dencun d'Ethereum.

• Référence ERC-20 : consultez la norme de jeton canonique sur Ethereum.org pour des informations de base sur les soldes, totalSupply et les événements. Référence : ERC-20 sur Ethereum.org.
• Contexte Dencun : l'activation du réseau principal a réduit les coûts de disponibilité des données pour les rollups, rendant les opérations de jetons à haute fréquence moins chères sur les L2. Référence : Annonce Dencun de la Fondation Ethereum.

Liens :

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

Qu'est-ce que l'ERC-621 ?

L'ERC-621 propose une extension à l'ERC-20 qui permet à un contrat de jeton d'augmenter ou de diminuer son offre totale via des fonctions et une sémantique d'événements standardisées. Essentiellement, il fournit un moyen convenu de reconnaître la création (augmentation de l'offre) et la destruction (diminution de l'offre) par les outils.

Idées clés :

• La création augmente totalSupply et crédite des jetons à une adresse, en émettant un événement Transfer de l'adresse zéro (address(0)) vers le destinataire.
• La destruction diminue totalSupply et débite des jetons d'une adresse, en émettant un événement Transfer du détenteur vers l'adresse zéro.
• Cette sémantique correspond à la manière dont les jetons compatibles ERC-20 sont censés représenter la création/destruction au niveau des événements, améliorant la compatibilité avec les explorateurs et les indexeurs.

Référence : EIP-621 sur eips.ethereum.org.

Lien :

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

Note de statut : l'ERC-621 a été proposé tôt dans l'écosystème et est moins souvent référencé aujourd'hui que les modèles pratiques "mintable/burnable" d'ERC-20. Néanmoins, ses conventions au niveau des événements sont largement suivies par les implémentations ERC-20 bien réalisées qui prennent en charge la création/destruction.

Pourquoi l'élasticité de l'offre est importante en 2024-2025

• Stablecoins et RWA : les émetteurs créent régulièrement des jetons lors de l'intégration de nouvelles garanties et les détruisent lors des rachats. Une sémantique d'événements claire et auditable est essentielle à la transparence.
• Opérations L2 après Dencun : des opérations groupées moins chères sur les rollups signifient des cycles de création/destruction plus fréquents pour les jetons spécifiques aux applications, sans coûts de gaz prohibitifs. Référence : Page de la feuille de route Dencun d'Ethereum.
• Contrôles de conformité et de cycle de vie : les équipes de trésorerie ont souvent besoin de créations limitées par des rôles, de destructions lors de rachats, ou d'émissions planifiées qui peuvent être suspendues en cas d'incident.

Lien :

• Feuille de route Dencun : https://ethereum.org/fr/roadmap/dencun/

ERC-621 vs les modèles ERC-20 courants d'aujourd'hui

Bien que l'ERC-621 définisse une extension formelle de création/destruction, de nombreux projets en production implémentent la création et la destruction en utilisant des bibliothèques ERC-20 largement auditées et un contrôle d'accès :

• Extensions ERC-20 d'OpenZeppelin :
  • L'extension Burnable permet aux détenteurs de jetons (ou aux dépensiers approuvés) de détruire des jetons. Référence : OpenZeppelin ERC20Burnable.
  • Le contrôle d'accès basé sur les rôles est couramment utilisé pour restreindre la création à un MINTER_ROLE ou au propriétaire. Référence : OpenZeppelin AccessControl.

Liens :

• 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

Avantages du modèle OZ courant :

• Code mature avec une utilisation et des audits communautaires étendus.
• Séparation flexible des rôles (par exemple, MINTER_ROLE, PAUSER_ROLE).
• Intégration facile avec des fonctionnalités de pause ou permit (EIP-2612).

Compromis par rapport à un ERC-621 strict :

• L'ERC-621 vise des noms de fonctions et une sémantique standard pour les changements d'offre. De nombreux jetons n'exposent pas ces signatures de fonction exactes, mais adhèrent néanmoins à la sémantique des événements (création/destruction depuis l'adresse zéro) sur laquelle les indexeurs s'appuient.
• Le support des outils est déjà solide pour les événements ERC-20 de création/destruction, même sans interfaces ERC-621 explicites.

Référence pour les flux permit : EIP-2612.

Lien :

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

La sémantique des événements qui compte

Même si un jeton n'implémente pas l'interface exacte de l'ERC-621, deux modèles compatibles ERC-20 sont essentiels pour des changements d'offre transparents :

• Création : émettre Transfer(address(0), to, amount)
• Destruction : émettre Transfer(from, address(0), amount)

Les indexeurs, les portefeuilles et les explorateurs s'appuient sur ces événements pour comprendre les changements d'offre sans logique d'analyse personnalisée. C'est précisément l'alignement que l'ERC-621 cherchait à codifier. Référence : Norme de jeton ERC-20.

Lien :

• Norme ERC-20 : https://ethereum.org/fr/developers/docs/standards/tokens/erc-20/

Un modèle d'implémentation minimal et moderne

Voici un exemple simplifié qui respecte la sémantique de l'ERC-621 tout en utilisant des outils populaires. Il n'implémente pas les signatures de fonction littérales de l'ERC-621, mais il émet les événements Transfer attendus depuis l'adresse zéro et utilise des rôles pour la sécurité.

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

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

[contract](https://onekey.so/blog/fr/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/fr/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/fr/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount); // Émet Transfer([address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount)
    }
    // Fonctions de destruction héritées de ERC20Burnable (initiées par le détenteur)
}

• La création est limitée par des rôles et émet l'événement Transfer depuis l'adresse zéro.
• La destruction est optionnelle pour les détenteurs ou les dépensiers approuvés, émettant le Transfer vers l'adresse zéro.

Références OpenZeppelin :

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

Considérations sur la sécurité et la gouvernance

• Contrôle d'accès et séparation des tâches
  • Utilisez des rôles distincts pour le CRÉATEUR (MINTER), le METTEUR EN PAUSE (PAUSER) et l'ADMINISTRATEUR PAR DÉFAUT (DEFAULT_ADMIN). Évitez une seule EOA (adresse contrôlée par une clé privée) pour tous les pouvoirs.
  • Privilégiez une administration multi-signature ou basée sur des modules pour réduire le risque lié à une seule clé. Une approche bien connue consiste à placer les rôles d'administration derrière un multi-signature dédié. Référence : Documentation de Safe sur ce qu'est un Safe.
• Mise en pause et disjoncteurs
  • Les contrats pouvant être mis en pause aident à réagir aux incidents ou aux échecs d'oracles.
• Audits et meilleures pratiques
  • Suivez les directives de sécurité établies pour l'évolutivité, l'initialisation et la révocation des rôles. Référence : Meilleures pratiques pour les contrats intelligents sur Ethereum par ConsenSys Diligence.

Liens :

• Aperçu de Safe : https://docs.safe.global/learn/what-is-safe
• Meilleures pratiques pour les contrats intelligents : https://consensys.github.io/smart-contract-best-practices/

Nuances L2 et de ponts

• Jetons canoniques vs jetons pontés
  • Si votre jeton est canonique sur une L2, la création se fait souvent directement sur cette L2 ; les ponts reflètent alors l'offre sur d'autres réseaux.
  • Si canonique sur L1, considérez qui est autorisé à créer des représentations sur L2 et comment les contrats de pont régissent cette autorité.
• Opérations groupées
  • Envisagez la création/les rachats groupés pour minimiser les coûts et améliorer la clarté de la comptabilité sur les rollups, qui sont beaucoup moins chers après Dencun. Référence : Aperçu Dencun d'Ethereum.

Lien :

• Aperçu Dencun : https://ethereum.org/fr/roadmap/dencun/

Comment évaluer un jeton qui peut être créé ou détruit

Pour les utilisateurs et les intégrateurs :

• Lisez le code ou la source vérifiée
  • Vérifiez si la création est limitée par des rôles ; identifiez le contrôleur (EOA, multi-signature, DAO).
• Vérifiez la sémantique des événements
  • Recherchez des événements Transfer standard vers/depuis l'adresse zéro pour les changements d'offre.
• Examinez l'évolutivité
  • S'il est évolutif, comprenez qui peut le mettre à jour et selon quel processus.

Les références des explorateurs et de la documentation sont utiles ici :

• Aperçu de la norme ERC-20 : https://ethereum.org/fr/developers/docs/standards/tokens/erc-20/
• Détails de la proposition ERC-621 : https://eips.ethereum.org/EIPS/eip-621

Devriez-vous adopter l'ERC-621 aujourd'hui ?

• Si vous souhaitez des signatures de fonction explicites pour la gestion de l'offre que les portefeuilles ou les middlewares peuvent cibler, l'ERC-621 vous offre une interface clairement nommée.
• Si vous vous appuyez déjà sur les modèles OpenZeppelin, vous respectez probablement les aspects importants de l'esprit de l'ERC-621 — les événements Transfer standardisés depuis l'adresse zéro — tout en bénéficiant de bibliothèques auditées et d'une conception de rôles flexible.
• Quelle que soit votre option, documentez votre politique de création/destruction (qui peut créer, quand, plafonds, processus d'audit) et rendez-la lisible pour les intégrateurs.

Dernières réflexions et une recommandation pratique

La création et la destruction de jetons sont des leviers puissants qui nécessitent une gouvernance rigoureuse. Que vous adoptiez l'interface explicite de l'ERC-621 ou que vous vous en teniez aux extensions ERC-20 largement utilisées, les aspects les plus importants sont une sémantique d'événements standardisée, une conception de rôles claire et une gestion sécurisée des clés — en particulier alors que l'activité d'émission et de rachat s'accélère sur les L2 en 2025.

Pour la sécurité opérationnelle, conservez les clés de création et d'administration dans un stockage à froid dédié et exigez des approbations multi-signatures pour les actions sensibles. Les portefeuilles matériels OneKey peuvent servir de signataires sécurisés pour les rôles de trésorerie et d'administration sur tous les réseaux EVM, en s'intégrant aux configurations multi-signatures et dApps populaires. L'utilisation d'un portefeuille matériel pour cosigner les transactions de création/destruction et de gestion des rôles permet de réduire le risque de point de défaillance unique tout en préservant des flux de travail efficaces pour vos opérations de jetons.