ERC-4907 : La norme pour la location et la séparation de propriété des NFT

Les jetons non fongibles (NFT) ont dépassé le statut de simples objets de collection pour devenir des actifs dotés d'une utilité réelle dans les jeux, les terrains du métavers, les adhésions et les médias. À mesure que leur utilité croît, le besoin de séparer celui qui possède un NFT de celui qui peut l'utiliser à un moment donné devient plus pressant. L'ERC-4907 introduit une méthode simple et on-chain pour y parvenir : un rôle utilisateur standardisé avec une expiration intégrée, permettant des locations de NFT sans confiance (trustless) et une séparation de propriété claire sans nécessiter d'enveloppement (wrapping) ou de solutions de contournement custodial. Cette proposition est Finalisée dans le processus EIP d'Ethereum et largement référencée par les développeurs et les places de marché. Consultez la spécification pour plus de détails dans le document EIP officiel sur le site d'Ethereum : ERC-4907.

Pourquoi la séparation de propriété est importante

Les NFT ERC-721 traditionnels accordent tous les droits à l'adresse propriétaire. Cela est insuffisant lorsque :

• Un joueur souhaite utiliser temporairement un objet rare en jeu sans l'acheter.
• Une marque souhaite accorder un accès limité dans le temps à des avantages supplémentaires à la propriété.
• Un propriétaire de terrain dans le métavers souhaite louer son terrain en toute sécurité à des locataires.
• Un créateur souhaite conserver la provenance à long terme tout en permettant à quelqu'un d'autre de consommer l'utilité à court terme.

Historiquement, les projets ont résolu ce problème avec des places de marché custodial, des jetons enveloppés ou des contrats sur mesure, qui introduisaient tous des frictions et des risques de sécurité. L'ERC-4907 fait des locations et de l'utilité déléguée une fonctionnalité de première classe des ERC-721.

Ce que l'ERC-4907 ajoute à l'ERC-721

L'ERC-4907 étend l'ERC-721 avec deux concepts clés :

• user : une adresse qui peut utiliser l'utilité du NFT sans le posséder.
• expires : un horodatage Unix après lequel les droits de l'utilisateur prennent fin automatiquement.

Les implémentations exposent des fonctions et un événement pour que l'état de location soit traçable et composable :

• Une fonction pour définir l'utilisateur et la date d'expiration.
• Une fonction pour interroger l'utilisateur actuel et le temps restant.
• Un événement pour signaler les changements afin que les indexeurs et les places de marché puissent réagir.

Il est important de noter qu'il est conçu pour être minimal et compatible avec les normes existantes. Les développeurs peuvent le combiner avec les redevances via l' ERC-2981 et la propriété principale via l' ERC-721. Pour la spécification complète et l'interface, référez-vous à l'EIP : ERC-4907.

Note : lors d'un transfert de NFT, les implémentations typiques effacent l'utilisateur et la date d'expiration pour éviter un report involontaire, comme recommandé par les implémentations de référence communautaires. Une référence largement utilisée est maintenue par Double Protocol : Documentation et implémentation ERC-4907 et leur dépôt open source : Double Protocol ERC-4907 GitHub.

Comment cela permet la location de NFT

Avec l'ERC-4907, un propriétaire peut louer un NFT sans confiance (trustless) :

• Le propriétaire définit l'adresse de l'utilisateur et une date d'expiration.
• Le réseau garantit que le rôle d'utilisateur se termine automatiquement à la date d'expiration.
• Les DApps contrôlent l'accès à l'utilité en vérifiant l'utilisateur actuel et la date d'expiration, pas seulement le propriétaire.

Aucun enveloppement (wrapping) ni gestion custodial n'est nécessaire, et les droits sont transparents on-chain pour les places de marché et les indexeurs. Ce modèle réduit la surface d'attaque par rapport aux schémas de délégation sur mesure et prend en charge les marchés secondaires où l'utilité peut être valorisée séparément de la propriété.

Pour les projets utilisant des actifs semi-fongibles (objets de jeu, tickets), une norme parallèle fournit des sémantiques similaires pour l'ERC-1155 : ERC-5006.

Cas d'utilisation clés en 2025

• Jeux Web3 : Les joueurs louent des objets ou des personnages rares pour des tournois sans engagement à long terme. Les studios peuvent créer des expériences de type abonnement nativement on-chain. Voir l'aperçu plus large de l'utilité des NFT sur Ethereum : NFT sur ethereum.org.
• Terrains du métavers : Les propriétaires définissent des droits d'utilisateur limités dans le temps pour les constructeurs ou les annonceurs, réduisant les frictions et les litiges grâce à une logique d'expiration claire.
• Passes d'adhésion : Les marques peuvent séparer la provenance de l'accès. Les locations permettent des campagnes courtes ou des essais, tandis que le propriétaire d'origine conserve l'actif de collection.
• Médias et propriété intellectuelle : La visualisation, la licence ou l'utilisation d'œuvres numériques limitée dans le temps est appliquée par expiration, améliorant la conformité et la monétisation sans plateformes custodial.

Un aperçu éducatif sur la finance et l'utilité des NFT est disponible sur la plateforme de Chainlink : Finance et utilité des NFT.

Notes d'implémentation pour les développeurs

• Support de l'interface : Implémentez supportsInterface pour ERC-4907 et émettez l'événement spécifié lorsque l'état de l'utilisateur change, afin que les indexeurs puissent suivre les locations de manière fiable. Voir : Spécification ERC-4907.
• Comportement de transfert : Effacez l'utilisateur et la date d'expiration lors du transfert pour éviter les droits orphelins ; c'est le schéma attendu dans les implémentations de référence.
• Logique de contrôle d'accès : Les DApps doivent vérifier à la fois l'utilisateur et le propriétaire en fonction de l'action. Par exemple, les fonctions de jeu peuvent exiger que l'appelant soit l'utilisateur actuel ; les actions d'administration doivent rester réservées au propriétaire.
• Redevances et frais : Combinez avec l'ERC-2981 pour les redevances des créateurs, et concevez les flux de frais de location comme des transactions on-chain séparées et transparentes.
• Indexation et analyse : Écoutez l'événement de mise à jour ERC-4907 pour alimenter les listes de locations et les moniteurs d'expiration dans les places de marché.
• Analogue aux ERC-1155 : Si vos actifs sont fongibles ou semi-fongibles, évaluez l'ERC-5006 pour le support du rôle utilisateur dans les jetons batchables.

Considérations de sécurité

• Gestion du temps : Utilisez block.timestamp avec précaution ; évitez les débordements arithmétiques et assurez-vous que les horodatages nuls ou passés invalident immédiatement les droits de l'utilisateur, conformément à la spécification.
• Réentrance et approbations : Traitez les opérations de définition de l'utilisateur comme des transferts en termes d'ordre des événements et de vérifications. Utilisez des garde-fous contre la réentrance autour des changements d'état qui déclenchent des appels externes.
• Front-running : Si les locations sont créées dans le mempool public en attente, envisagez le commit-reveal ou la signature hors chaîne avec des relais protégés pour les opérations sensibles aux prix.
• Conflits propriétaire vs. utilisateur : Définissez explicitement quelles méthodes l'utilisateur peut appeler. Gardez les transitions d'état simples et déterministes.
• Compatibilité avec les places de marché : Effacez l'utilisateur lors du transfert et émettez l'événement de mise à jour pour maintenir un comportement cohérent sur les marchés secondaires.
• Spécificités des L2 : Soyez conscient des sémantiques d'horodatage et des messages de pont lors de la location sur les Layer 2 ; utilisez des sources de temps canoniques et auditez la logique de pont.

Pour un modèle concret et des tests, référez-vous aux implémentations open source : Double Protocol ERC-4907 GitHub.

Pour les utilisateurs : comment louer en toute sécurité

• Vérifiez que le contrat NFT prend en charge l'ERC-4907 via son support d'interface et ses méthodes de visualisation. Confirmez que l'utilisateur et la date d'expiration sont visibles on-chain.
• Utilisez des places de marché réputées avec des listes et des événements on-chain transparents, et confirmez que la date d'expiration correspond à votre accord.
• Gardez le contrôle de vos clés privées et interagissez directement avec les contrats lorsque cela est possible ; évitez l'enveloppement custodial sauf si vous faites confiance à la contrepartie et au code.

Un guide général sur les NFT et les meilleures pratiques est disponible sur : NFT sur ethereum.org.

Perspectives du marché

En 2025, les locations on-chain gagnent du terrain dans les projets de jeux et de métavers, tandis que des normes comme l'ERC-4907 et l'ERC-5006 fournissent aux développeurs des blocs de construction interopérables. L'alignement des locations avec les flux de redevances et de places de marché existants réduit la fragmentation et permet des marchés d'utilité composables où la propriété et l'utilisation peuvent être valorisées indépendamment. Les développeurs bénéficient d'une surface d'attaque réduite et facile à auditer, et les utilisateurs obtiennent des droits transparents avec expiration automatique.

Quand recommander un portefeuille matériel

Si vous possédez des NFT de grande valeur et prévoyez de les louer, le contrôle sécurisé de la clé propriétaire est essentiel. L'ERC-4907 vous permet de déléguer l'utilité sans transférer la propriété, mais l'adresse du propriétaire reste l'autorité ultime. Un portefeuille matériel permet de garantir que les opérations de location, les approbations et les transferts sont signés dans un environnement sécurisé.

OneKey est un portefeuille matériel open source et multi-chain qui conserve vos clés privées hors ligne tout en restant compatible avec les réseaux EVM et les dApps NFT populaires. Pour les propriétaires de NFT et les créateurs utilisant l'ERC-4907, OneKey offre un chemin de signature sécurisé pour les accords de location et les transferts de propriété, réduisant le risque de compromission des clés lors des interactions on-chain.