Une offre d’achat à 12,5 ETH tombe sur votre objet alors que la collection change de mains autour de 0,5 ETH. Le nombre est réel au sens où quelqu’un l’a bien signé dans un ordre. Ce que le nombre ne vous dit pas, c’est dans quel jeton il est compté, et ce seul champ suffit à transformer la transaction que vous croyez accepter en une tout autre transaction.
Ce qu’est réellement une offre d’achat
Une offre d’achat, aussi appelée enchère, est le côté acheteur de la même conception à ordres signés qui porte, du côté vendeur, les annonces falsifiées. Celui qui enchérit n’envoie d’argent nulle part. Il signe un message qui nomme un objet, un montant, un contrat de monnaie et une échéance, et la place de marché conserve cette signature et l’affiche comme une ligne sur votre page.
À cet instant, rien n’a bougé sur la chaîne. Le transfert a lieu quand vous acceptez, parce que votre acceptation est la transaction qui exécute l’ordre, sort le NFT de votre portefeuille et fait entrer les jetons de l’enchérisseur. C’est vous qui la soumettez, ce qui fait de la lecture de l’ordre votre travail et non le sien.
EIP-712, la norme Ethereum pour le hachage et la signature de données structurées typées, est ce qui donne à ces messages une forme lisible. Elle a été écrite contre la situation qu’elle décrit : les messages signés sont une chaîne hexadécimale opaque affichée à l’utilisateur avec très peu de contexte sur les éléments qui composent le message. La signature structurée a rendu une offre lisible. Elle ne l’a pas rendue honnête.
La ligne de la monnaie décide de ce que vaut une offre
Une offre porte un montant et l’adresse du jeton dans lequel ce montant est compté. La page compose le montant en gros et l’adresse nulle part. Toute l’ouverture tient dans cette mise en page, car un montant n’est jamais qu’une quantité de ce vers quoi pointe le second champ.
Les symboles de jetons n’identifient rien. Sous ERC-20, name comme symbol sont facultatifs, et la norme énonce que la méthode peut servir à améliorer l’utilisabilité, mais que les interfaces et les autres contrats ne doivent pas s’attendre à ce que ces valeurs soient présentes. Celui qui déploie choisit ces chaînes librement : un contrat dont le symbole se lit exactement comme celui d’un contrat d’ether wrappé coûte un seul déploiement et peut être frappé dans la quantité que son auteur veut.
Une offre libellée dans un tel jeton n’est pas un faux, et elle se dénouerait exactement comme elle est écrite : vous cédez l’objet et recevez le nombre indiqué d’unités d’un jeton derrière lequel il n’y a aucun acheteur. La vérification est donc une comparaison d’adresses, et ERC-721 dit la même chose du côté de l’objet lorsqu’elle appelle le couple formé par l’adresse du contrat et le token ID un identifiant globalement unique et pleinement qualifié d’un actif précis sur une chaîne Ethereum. L’identité habite l’adresse. Les symboles sont des étiquettes dessinées par-dessus.
Pourquoi la taille d’une offre ne prouve rien
Une offre 25 fois au-dessus du niveau auquel une collection s’échange se lit comme une aubaine et affirme quelque chose de bien plus faible : ce qu’une adresse dit qu’elle paierait. Le dire ne coûte rien. L’offre peut être annulée avant que vous n’y arriviez, et elle s’arrête à l’échéance inscrite en elle.
Les offres peuvent aussi être produites exprès pour être regardées. Des offres placées entre des adresses relevant d’un même opérateur créent une apparence de demande comme le wash trading crée une apparence de volume, et ni la page de la place de marché ni la chaîne n’enregistrent qui contrôle quelle adresse.
La forme pratique de cela est une offre construite pour être vue plutôt que pour être exécutée. Elle ancre un vendeur sur un nombre, ou elle attire l’attention sur une collection pendant que d’autres objets de cette collection sont vendus dans cette attention. Traitez une offre comme une adresse qui parle d’elle-même, et gardez le niveau auquel la collection s’échange réellement comme la question distincte qu’il est.
L’offre qui est en réalité une demande d’approbation
Certaines notifications d’offre ne sont pas des offres. La page existe pour placer devant vous une demande de signature, et ce qu’elle réclame est une permission durable sur votre collection plutôt qu’une vente. ERC-721 définit setApprovalForAll comme le fait d’activer ou de désactiver l’approbation donnée à un tiers, appelé opérateur, de gérer l’ensemble des actifs de l’appelant, et un opérateur détenant cette permission peut déplacer chaque objet de la collection sans redemander : c’est le mécanisme derrière un drainer de portefeuille.
Le côté monnaie a sa propre version. ERC-2612 ajoute une fonction permit pour qu’une autorisation puisse être fixée depuis un message signé plutôt que depuis une transaction envoyée par le détenteur, les données signées étant structurées selon EIP-712. Une approbation de jetons qui arrive par ce chemin ne laisse aucune transaction à remarquer au moment où vous signez, et ERC-20 avertit déjà qu’un nouvel appel à approve écrase l’autorisation courante par la nouvelle valeur.
EIP-712 vous donne aussi le champ qui sépare une vraie demande de sa copie. Son séparateur de domaine nomme le contrat pour lequel une signature est valable, et la justification explique que le séparateur empêche la collision de structures par ailleurs identiques, puisque deux applications peuvent aboutir à une structure identique qui ne devrait pas être compatible. La spécification prévoit que les agents utilisateurs puissent mener sur cette base une protection antihameçonnage propre à un contrat. En pratique, cela veut dire lire le contrat vérificateur à l’intérieur de la demande décodée avant de lire quoi que ce soit que la page a écrit autour.
Les offres qui arrivent hors de la place de marché
Une offre qui vous parvient par message privé, par courriel ou par un lien inséré dans un objet que quelqu’un a largué dans votre portefeuille a sauté la seule partie du processus qui était vérifiable : l’interface de la place de marché que vous avez ouverte. Un message peut reproduire cette mise en page au détail près, parce que la mise en page est publique.
L’habitude qui referme cela consiste à rejoindre la place de marché par une adresse que vous avez enregistrée vous-même et à y chercher l’offre. Une offre qui existe sera sur la page de votre objet. Celle qui n’existe que dans le message n’est pas une offre, et ce qui attend au bout du lien est la demande de signature.
Ce qu’une ligne d’offre peut promettre et ce qu’elle ne peut pas
| Ce que montre la ligne | Ce que c’est | Ce que cela règle |
|---|---|---|
| Le montant | Un champ de l’ordre signé | Rien à lui seul |
| Le symbole de la monnaie | Texte libre choisi par celui qui déploie le jeton | Rien |
| L’adresse du contrat de la monnaie | L’identité de l’actif proposé | Ce que vous recevriez réellement |
| L’échéance | Un champ de l’ordre signé | Le moment le plus tardif d’exécution, pas le plus précoce de retrait |
| Les avoirs de l’enchérisseur | Pas du tout un élément de l’ordre | Rien, même si un solde insuffisant fait échouer l’exécution |
Parcourez la colonne du milieu et le motif apparaît : chaque ligne sauf une est une affirmation, alors que la ligne de l’adresse est une identité. C’est la ligne qui mérite votre attention, et c’est la ligne que l’interface compose en plus petit.
Ce qu’il faut vérifier avant d’accepter
| Ce qu’il faut vérifier | Ce à quoi le comparer | Ce qu’un écart signifie |
|---|---|---|
| Adresse du contrat de la monnaie | À l’adresse que l’émetteur publie lui-même | On vous paie dans un autre actif |
| Contrat de l’objet et token ID | À l’objet que vous croyez vendre | L’ordre pointe vers autre chose |
| Ce que la demande autorise | À l’action que vous visiez | Vous accordez un accès au lieu de vendre |
| Le contrat vérificateur dans la demande | À la place de marché que vous avez ouverte vous-même | La signature vise le contrat de quelqu’un d’autre |
| Les approbations en cours sur la collection | Aux opérateurs que vous vouliez autoriser | Une permission accordée plus tôt est toujours ouverte |
L’ordre compte ici. L’adresse de la monnaie vient en premier parce qu’elle décide s’il y a transaction, et la vérification de la signature vient avant celle du prix, parce qu’une demande qui accorde un accès se moque du prix affiché sur la page.
En résumé
Une offre d’achat est un message signé comportant plusieurs champs, et une place de marché en compose un seul en grand. Le montant est le champ qui convainc, l’adresse de la monnaie est le champ qui décide, et les deux ne sont jamais montrés à la même taille. Lire le second constitue toute la défense contre une offre libellée dans un jeton qui a copié un symbole.
L’autre moitié est la demande de signature. Accepter une offre est une vente qui déplace un objet et vous paie pour lui, tandis qu’une demande de droits d’opérateur sur votre collection n’est pas une vente du tout : elle ne coûte rien au moment de la signature et accorde tout ensuite. Vérifiez l’adresse de la monnaie, vérifiez ce que la signature autorise, et rejoignez la place de marché par une adresse que vous avez tapée vous-même. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Manipulation du prix plancher sur les marketplaces de jetons non fongibles
- Sécurité de connexion en crypto : comment protéger votre compte
- Arnaques aux airdrops et liste de contrôle de sécurité avant toute réclamation
- On-ramp et off-ramp en crypto : quelle différence ?
- Jetons de culte et reprises par la communauté (CTO)
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] Propositions d’amélioration d’Ethereum (EIP), EIP-712: Typed structured data hashing and signing eips.ethereum.org
[2] Propositions d’amélioration d’Ethereum (EIP), ERC-20: Token Standard eips.ethereum.org
[3] Propositions d’amélioration d’Ethereum (EIP), ERC-721: Non-Fungible Token Standard eips.ethereum.org
[4] Propositions d’amélioration d’Ethereum (EIP), ERC-2612: Permit Extension for EIP-20 Signed Approvals eips.ethereum.org
