ERC-2981 : Comment définir et implémenter les redevances NFT

Les redevances NFT ont commencé comme un contrat social entre les créateurs et les places de marché. À mesure que le commerce a mûri et que les modèles tarifaires ont évolué, l'industrie a eu besoin d'un moyen cohérent et sur la chaîne pour décrire les informations relatives aux redevances que toute place de marché pouvait lire. C'est exactement ce que fournit l'ERC-2981 : une interface minimale et interopérable pour interroger le montant de la redevance due et à qui, pour toute vente de NFT donnée. Cet article explique ce qu'est l'ERC-2981, son fonctionnement interne, les considérations pour sa mise en œuvre, ainsi que le paysage actuel de l'application par les places de marché et de la monétisation par les créateurs.

Ce que l'ERC-2981 standardise réellement

ERC-2981 est une norme Ethereum qui définit une seule fonction pour les jetons non fongibles :

• royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)

Les places de marché qui respectent les redevances appellent royaltyInfo au moment de la vente pour calculer le paiement. La norme n'impose pas le paiement ; elle décrit seulement l'interface. L'application est une question de politique de la place de marché.

Choix de conception clés :

• Basé sur un pourcentage : Les redevances sont calculées en fonction du prix de vente, généralement à l'aide d'une fraction comme des points de base (par exemple, 500 = 5 %).
• Flexibilité du destinataire : Le destinataire de la redevance peut être l'adresse d'un créateur, un multisig, un contrat de partage, ou une adresse de paiement évolutive.
• Fonctionne avec ERC-721 et ERC-1155 : L'ERC-2981 est compatible avec les normes NFT courantes et s'appuie sur ERC-165 pour la détection d'interface.

Pour une mise en œuvre prête pour la production, de nombreuses équipes s'appuient sur l'ERC2981 d'OpenZeppelin.

Pourquoi c'est important maintenant

À partir de 2023, plusieurs places de marché leaders ont fait passer l'application des redevances à un mode optionnel. Le changement le plus notable a été la décision d'OpenSea de supprimer son filtre d'opérateur, qui permettait auparavant aux créateurs de restreindre les transactions aux plateformes appliquant les redevances ; voir l'annonce d'OpenSea. Par conséquent, les normes sur la chaîne comme l'ERC-2981 sont devenues le moyen par défaut de présenter les données de redevances sur les plateformes, même si leur application varie.

Depuis lors, l'écosystème a répondu par :

• Une infrastructure de registre pour que les places de marché puissent résoudre la logique de redevance de manière unifiée, par exemple le Royalty Registry et sa spécification associée.
• Des normes programmables pour l'application ou les restrictions sur la chaîne, notamment ERC-721C (Creator Token Standards).
• Des modèles de revenus alternatifs tels que les récompenses au niveau du protocole et les incitations aux créateurs, par exemple les Creator Rewards de Zora.

En 2024-2025, l'adoption de l'ERC-2981 reste généralisée sur les réseaux L1 et L2, et les places de marché qui choisissent de respecter les redevances interrogeront généralement cette interface lors du règlement des transactions.

Comment fonctionne l'interface (sans surprises)

Au moment de la vente, une place de marché conforme effectue les opérations suivantes :

1. Vérifie que le jeton prend en charge IERC2981 via ERC-165 (ID d'interface 0x2a55205a).
2. Appelle royaltyInfo(tokenId, salePrice) pour obtenir :
   • receiver : Adresse pour recevoir le paiement.
   • royaltyAmount : Montant à payer, calculé à partir de salePrice.

Les créateurs ou les propriétaires de collections définissent généralement une « redevance par défaut » et éventuellement une « redevance par jeton ». De nombreuses implémentations utilisent un dénominateur de 10 000 pour les points de base. La comptabilité de la place de marché divise ensuite les revenus de la vente entre le vendeur, les frais de protocole et le destinataire de la redevance.

Conseils de mise en œuvre :

• Évitez les reverts dans royaltyInfo : les places de marché peuvent ignorer les paiements si votre appel échoue.
• Gardez le destinataire de la redevance évolutif (par exemple, via Ownable ou des contrôles d'administrateur) pour faire pivoter les clés ou migrer vers un contrat de partage.
• Limitez les redevances à un maximum raisonnable (de nombreux projets restent ≤10 %) pour encourager la liquidité du marché secondaire.

Exemple Solidity minimal

Ci-dessous un modèle simplifié utilisant OpenZeppelin. Il montre comment définir une redevance par défaut et comment ignorer le support pour ERC-165. En production, vous devriez ajouter un contrôle d'accès, des gardes d'initialisation et une logique de frappe robuste.

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

import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/fr/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/fr/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[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/) MyNFT is ERC721, ERC2981, Ownable {
    uint256 private _nextTokenId;

    constructor([address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // Définir la redevance par défaut (par exemple, 500 = 5 %)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

    function mint([address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
        _safeMint(to, _nextTokenId);
        _nextTokenId++;
    }

    // Optionnel : définir la redevance par jeton pour les objets spéciaux
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

    // Obligatoire : supportsInterface d'ERC-165
    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

Pour une documentation plus approfondie, consultez le guide ERC2981 d'OpenZeppelin.

Gestion des partages, des mises à niveau et des cas limites

Les flux de redevances réels impliquent rarement un seul destinataire. Considérez :

• Contrats de partage : Routez les revenus vers plusieurs parties selon des proportions fixes en utilisant une infrastructure bien testée comme 0xSplits.
• Recherches dans le registre : Certaines places de marché consultent un registre pour obtenir les dernières données de redevances (Royalty Registry).
• Destinataires évolutifs : Maintenez la possibilité de mettre à jour l'adresse de réception en cas de rotation de clés ou de changements organisationnels.
• Substitutions par jeton : Les éditions spéciales peuvent avoir des taux de redevance uniques par rapport à la valeur par défaut.

Notes techniques :

• Dénominateur cohérent : Restez sur les points de base (10 000) pour plus de clarté dans les intégrations hors chaîne.
• Conscience du type de jeton : Les implémentations ERC-1155 doivent calculer la redevance sur le prix de vente par jeton, pas sur le prix du lot.
• Solution de repli élégante : Si le destinataire de la redevance n'est pas défini, renvoyez zéro pour éviter les appels échoués de la place de marché.

Réalité des places de marché : signalisation contre application

L'ERC-2981 signale l'intention du créateur ; il n'impose pas le paiement. Différentes plateformes :

• Peuvent honorer pleinement l'ERC-2981.
• Peuvent plafonner ou réduire les redevances dans certaines conditions.
• Peuvent ignorer complètement les redevances.

Compte tenu de cette variabilité, de nombreux créateurs expérimentent des modèles hybrides :

• Restrictions sur la chaîne via ERC-721C pour limiter les transferts aux opérateurs respectant les redevances.
• Récompenses au niveau du protocole comme les Creator Rewards de Zora.
• Normes communautaires et pression sociale autour du respect des revenus des créateurs.

La décision d'OpenSea en 2023 de mettre fin au filtrage des opérateurs reflète la tendance plus large vers le choix du marché plutôt que l'application au niveau du protocole, détaillée dans leur annonce. En 2024-2025, cet équilibre se poursuit : l'ERC-2981 reste l'interface canonique pour les métadonnées de redevance, tandis que l'application est fragmentée.

Test, vérification et surveillance

Pour garantir un comportement fiable des redevances :

• Vérifiez la prise en charge de l'interface : Confirmez que votre contrat renvoie supportsInterface(0x2a55205a) == true selon ERC-165.
• Simulez les appels : Testez royaltyInfo pour des prix de vente et des jetons extrêmes.
• Compatibilité avec l'indexation : Enregistrez votre contrat dans les registres pertinents comme Royalty Registry si vos partenaires de place de marché s'y fient.
• Documentez clairement : Publiez votre politique de redevance, vos plafonds et votre logique de destinataire pour minimiser les surprises pour les acheteurs et les places de marché.
• Apprenez la norme : Si vous êtes nouveau sur ERC-2981, cet aperçu par Alchemy est un bon point de départ : Qu'est-ce que ERC-2981 ?.

Sécurité et gestion des clés pour les créateurs

Les configurations de redevances sont contrôlées par l'administrateur. Si un attaquant obtient l'accès à vos clés de déploiement ou d'administrateur, il peut rediriger les redevances ou les désactiver. Bonnes pratiques :

• Utilisez un portefeuille matériel pour les actions à privilèges élevés comme la définition de la redevance par défaut, la mise à jour des destinataires ou le déploiement de contrats de partage.
• Privilégiez les configurations multisig pour les collections gérées par une équipe.
• Gardez les flux de signature transparents et audibles.

Pour les créateurs et les studios qui souhaitent une signature sécurisée et portable sans compromettre l'expérience utilisateur, les portefeuilles matériels OneKey offrent :

• Stockage hors ligne des clés privées avec un firmware open-source et des pratiques de sécurité transparentes.
• Intégration transparente avec les outils Ethereum courants pour le déploiement de contrats et les opérations d'administration.
• Prise en charge multi-chaînes, utile si vos NFT sont frappés sur des L2 ou plusieurs réseaux EVM.

L'utilisation d'un portefeuille matériel pour gérer les paramètres de redevance garantit que vos signaux de revenus sur la chaîne ne peuvent pas être falsifiés par des appareils compromis ou des portefeuilles chauds.

Conclusion

L'ERC-2981 est la couche fondamentale des redevances NFT : une interface simple et universelle que les places de marché peuvent lire pour déterminer les paiements des créateurs. Il ne garantit pas l'application – ce sont les politiques du marché qui le font – mais il standardise le signal. Dans un monde où l'application est facultative et en évolution, la combinaison de l'ERC-2981 avec des registres, des contrats de partage et des restrictions programmables comme ERC-721C offre aux créateurs des outils pratiques pour soutenir leur travail.

Si vous gérez des collections NFT ou une infrastructure de créateur, implémentez l'ERC-2981 proprement, testez-le minutieusement et sécurisez vos clés d'administration avec un portefeuille matériel. Cette combinaison maximise l'interopérabilité entre les places de marché tout en protégeant les flux de revenus dont dépend votre projet.