Aller au contenu

Autorisation de portefeuille

L'autorisation de portefeuille est une permission on-chain permettant à un dépensier nommé d'appeler transferFrom pour les jetons de l'utilisateur. Elle explique la différence avec les signatures, la persistance des montants illimités et les méthodes de vérification et révocation.

Mis à jour

À des fins éducatives uniquement ; ne constitue pas un conseil en investissement. Investir peut entraîner des pertes.

Réponse directe

L’autorisation de portefeuille, généralement une approbation de jeton, est une allowance on-chain du propriétaire vers une seule adresse dépensière. Pour ERC-20, approve(spender, amount) l’enregistre puis le dépensier peut appeler transferFrom dans la limite restante. Il n’obtient ni clé privée ni droits sur d’autres jetons. L’approbation modifie l’état, tandis qu’une signature de connexion est généralement off-chain. Un permit typé comme ERC-2612 est une donnée signée qu’un contrat peut soumettre sans que le propriétaire paie ce gas, mais c’est toujours une autorisation. ETH n’utilise pas d’allowance ERC-20. Vérifie jeton, dépensier, montant, durée et chaîne ; connecter le site n’est pas le droit de dépenser.

Autorisation de portefeuille
0 / 5
0 articles examinés; 5 points toujours non résolus

La réalisation de cet examen ne prouve pas qu'un actif, une transaction ou un système est sûr.

Fonctionnement

  1. L’utilisateur envoie approve au contrat. 0 signifie aucun reste et une valeur énorme est souvent affichée comme illimitée.
  2. Le dépensier utilise transferFrom ensuite. Le contrat vérifie solde et allowance, transfère puis la réduit normalement.
  3. Modifier l’allowance est une transition on-chain. Remplacer une valeur positive peut créer une course dans le mempool ; utilise zéro d’abord après confirmation si nécessaire.
  4. ERC-2612 permit est un message signé. Vérifie jeton, chain ID, nonce, échéance, dépensier et montant ; un tiers peut l’envoyer.
  5. Approuve seulement le dépensier vérifié et le montant nécessaire, simule l’appel et contrôle receipt, événements Approval/Transfer, solde et allowance. Révoque par 0 sur la bonne chaîne ; les transferts confirmés restent.

Exemple

Alice possède 100 USDC et approuve un routeur vérifié pour 40. Il peut dépenser 40 USDC au plus, pas son ETH ni un autre jeton. Après 15, il reste normalement 25. Une approbation illimitée couvre aussi les dépôts futurs ; elle doit vérifier le contrat, choisir un montant fini et envoyer approve(router, 0) ensuite.

Risques

  • Un dépensier malveillant ou mis à niveau peut utiliser tous les jetons de l’allowance active.
  • Une approbation illimitée expose les dépôts futurs.
  • Mauvaise chaîne, adresse, décimales ou calldata peuvent masquer une demande dangereuse.
  • Modification ou révocation en attente peut entrer en course avec transferFrom ; le zéro n’annule pas un transfert exécuté.
  • Les signatures permit peuvent être soumises plus tard ; déconnecter le site ne les invalide pas.
  • Les jetons non standards, à frais, rebasés, suspendus ou à callbacks peuvent différer ; vérifie contrat et état.

Idées reçues

  • « Connecter le portefeuille donne le droit de dépenser ». L’autorité vient d’une approbation, d’un permit ou d’une transaction confirmée.
  • « Une signature sans gas est inoffensive ». Un relayer peut l’envoyer plus tard.
  • « Déconnecter le site révoque l’approbation ». Connexion et allowance on-chain sont distinctes.
  • « Illimité signifie retrait immédiat de tout ». Il faut encore appel, solde et implémentation compatibles, mais sans plafond.
  • « Une simulation réussie prouve la sécurité ». Elle dépend de l’état ; vérifie chaîne, calldata, destinataire, code, receipt et soldes.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...