Comment vérifier si un NFT a déjà été vendu ?

Vérification de l'historique des transactions en chaîne

1. Chaque NFT émis sur Ethereum ou sur des blockchains compatibles porte un identifiant de jeton unique lié à son adresse contractuelle. Ce couplage forme l'identifiant immuable utilisé pour retracer toutes les activités sur le réseau.

2. Les utilisateurs peuvent saisir l'adresse du contrat et l'ID du jeton du NFT dans des explorateurs comme Etherscan, Polygonscan ou Solscan pour récupérer son journal de transactions complet. Chaque événement de transfert, de vente ou de gravure apparaît sous la forme d'une entrée distincte avec un horodatage, un numéro de bloc et les adresses de portefeuille impliquées.

3. La première transaction monétaire marque le point d'origine. Tout événement de transfert ultérieur avec une valeur non nulle dans le champ « valeur », en particulier lorsqu'il est associé à un appel de procuration connu du marché, indique une vente confirmée.

4. Les listings sur des plateformes telles que OpenSea ou Blur génèrent des transactions proxy visibles en chaîne avant même leur finalisation. Celles-ci apparaissent sous le contrat de routeur ou de port maritime de la place de marché, permettant de détecter les ventes en cours mais non exécutées.

5. L'absence d'événements de transfert ne garantit pas la propriété originale. Certains portefeuilles contiennent des NFT sans les déplacer, tandis que d'autres peuvent les avoir acquis via airdrop ou mint, les deux ne laissant aucune empreinte de vente secondaire.

Analyse des métadonnées des listes de marché

1. Les marchés intègrent des métadonnées dans la liste des événements stockés en chaîne. Par exemple, Seaport v1.4 d'OpenSea enregistre les événements OrderFulfilled contenant les détails de l'offrant, de la zone et de la contrepartie, y compris les montants ETH ou ERC-20 payés.

2. Les listes basées sur les enchères de Blur enregistrent séparément les soumissions d'offres et les appels de règlement. Une enchère exécutée déclenche un événement d'exécution faisant référence à l'enchérisseur gagnant et au prix final, visible sans recourir aux caches d'API hors chaîne.

3. Des plateformes comme LooksRare stockent les confirmations commerciales directement dans leurs propres contrats à l'aide des événements RewardDistributed et TradeExecuted. Ceux-ci contiennent l'acheteur, le vendeur, l'identifiant du jeton et le prix en unités wei.

4. Les API hors chaîne de ces plates-formes sont souvent en retard ou omettent des éléments supprimés de la liste. S'appuyer uniquement sur l'affichage frontal peut manquer les transactions historiques qui ont eu lieu avant le statut actuel de la cotation.

5. Certains NFT sont négociés exclusivement via des messages signés peer-to-peer (par exemple, les commandes privées Wyvern ou Seaport). Ceux-ci ne laissent des traces qu'après l'exécution, ce qui signifie que les ordres pré-signés mais non exécutés n'apparaîtront pas dans l'historique jusqu'au règlement.

Décodage des événements de contrat intelligent

1. Les normes ERC-721 et ERC-1155 imposent des événements de transfert pour chaque changement de propriétaire. Ceux-ci émettent trois paramètres indexés : _from, _to et _tokenId. Leur analyse révèle un mouvement quelle que soit l’implication de la plateforme.

2. Les contrats mettant en œuvre le support ERC-165Les vérifications d'interface permettent de demander si les événements de transfert sont émis. L'absence de supportsInterface(0x80ac58cd) suggère un comportement non standard, masquant potentiellement les transferts via une logique personnalisée.

3. Certains contrats malveillants ou expérimentaux remplacent l'émission de Transfer ou l'acheminent via des fonctions internes. Dans de tels cas, le traçage des appels internes via debug_traceTransaction devient nécessaire pour reconstruire les chemins de mouvement.

4. Les contrats sujets à la réentrée peuvent émettre un transfert en cours d'exécution pendant les séquences de rappel, comme lors de la gestion de onERC721Received. Cela crée des enregistrements de transfert imbriqués qui doivent être corrélés par bloc et index de transaction.

5. Les journaux d'événements sont moins chers que les écritures de stockage, de sorte que les projets légitimes suppriment rarement le transfert. Cependant, certains NFT axés sur la confidentialité utilisent des preuves sans connaissance pour dissimuler les adresses des destinataires, ce qui rend la vérification impossible sans relais de confiance.

Corrélation entre rareté et provenance

1. Les caractéristiques de grande rareté sont souvent en corrélation avec les premières activités commerciales. Les outils de rareté agrégés comme Rarity Sniper ou Trait Sniper calculent la rareté statistique en fonction de la distribution des attributs en chaîne et non de la perception subjective.

2. Un NFT avec des caractéristiques de premier plan mais aucun événement de transfert peut indiquer soit une frappe récente, soit une thésaurisation délibérée. À l’inverse, les transferts fréquents entre jetons de faible rareté suggèrent un retournement spéculatif plutôt qu’une détention à long terme.

3. Les collections avec des scripts de frappe vérifiés permettent de croiser l'ordre de génération des ID de jeton. Un identifiant de jeton de numéro 37 sur 10 000 émis dans le bloc 12 345 678 est statistiquement plus susceptible d'avoir été vendu avant le numéro 9999 émis dans le bloc 12 345 702, si les deux affichent des nombres de transferts identiques.

4. Les mesures de concentration de la propriété, telles que le coefficient de Gini appliqué aux avoirs du portefeuille par collection, mettent en évidence si les premiers utilisateurs ont conservé leurs actifs ou les ont dispersés. Une faible concentration implique une circulation plus large sur le marché secondaire.

5. Les identifiants de jeton attribués via les racines de l'arbre Merkle ou le caractère aléatoire du VRF brisent les hypothèses séquentielles. Dans ces cas-là, la provenance doit s’appuyer entièrement sur les journaux d’événements, et non sur des heuristiques d’ordre minutieux.

Foire aux questions

Q1 : Puis-je vérifier les ventes passées si le NFT a été négocié sur une bourse décentralisée comme Sudoswap ? Oui. Sudoswap utilise des contrats de paire directe dans lesquels chaque swap émet un événement Swap contenant l'acheteur, le vendeur, l'ID du jeton et le montant reçu. Ceux-ci sont entièrement indexés sur Etherscan et ne dépendent pas de carnets de commandes centralisés.

Q2 : Un NFT emballé sur Wormhole conserve-t-il son historique de vente d'origine ? Non. Le wrapping crée un nouveau jeton sur la chaîne de destination sans journal des événements hérité. Seule la transaction relais est enregistrée ; les ventes antérieures restent limitées à l'explorateur de la chaîne d'approvisionnement.

Q3 : Qu'est-ce que cela signifie si un NFT affiche plusieurs événements de transfert mais aucune entrée de champ de valeur ? Il indique des transferts sans échange monétaire, tels que des cadeaux, une consolidation de portefeuille ou une migration entre comptes de garde. Celles-ci ne constituent pas des ventes sauf si elles sont accompagnées d'un justificatif de paiement externe.

Q4 : Comment puis-je détecter les transactions fictives à l'aide de données en chaîne ? Recherchez des transferts aller-retour rapides entre deux portefeuilles avec des frais de gaz identiques, des fenêtres horaires qui se chevauchent et aucun contrat de marché intermédiaire. Vérifiez par recoupement avec les clusters de portefeuilles de robots connus publiés par Chainalysis ou Nansen.