ERC-20 est le standard qui définit comment un token fonctionne sur Ethereum. Si tu as un token — qu’il soit USDC, USDT, DAI ou n’importe quel autre — il suit probablement ERC-20. Ce standard garantit que ton wallet peut le reconnaître, que tu peux l’envoyer à quelqu’un d’autre, et que chaque DEX et exchange sait comment le traiter. C’est ça qui rend les tokens interopérables.
Que défini vraiment ERC-20 ?
ERC-20 est une interface : une liste de fonctions que tout token ERC-20 doit avoir. Les principales :
balanceOf(address) : affiche la balance de quelqu’un
transfer(address to, uint amount) : envoie ton token à quelqu’un
approve(address spender, uint amount) : autorise quelqu’un à dépenser tes tokens
transferFrom(address from, address to, uint amount) : transfère depuis une adresse (que tu as autorisée)
Ces quatre fonctions forment la base. Tous les exchanges, wallets et dApps les reconnaissent. Si un nouveau token les implémente correctement, il est immédiatement compatible avec l’écosystème.
Le mécanisme approve/transferFrom
C’est un point clé à comprendre. Quand tu swaps sur Uniswap :
1. Tu signes une approba : « Uniswap, je t’autorise à dépenser 1000 USDC de ma part »
2. Uniswap appelle transferFrom(ton_adresse, adresse_uniswap, 1000)
3. Le token transfère 1000 USDC de toi vers Uniswap
L’approval est un contrat de confiance : tu dis « cette adresse peut dépenser jusqu’à X tokens de moi ». Tu peux révoquer l’approval à tout moment en la mettre à 0.
Attention : une approval n’est pas négligeable. Certains contrats malveillants demandent une approval très élevée ou illimitée pour te voler. Toujours vérifier what tu approuves avant de signer.
Les événements : balancer la transparence
Chaque fois qu’un transfer se passe, le token émet un événement Transfer(from, to, amount). Les exploreurs comme Etherscan lisent ces événements pour afficher ton historique. Les événements ne changent pas l’état du contrat, mais ils permettent à tout le monde de voir ce qui s’est passé.
Créer ton propre token ERC-20
C’est plus simple que tu ne le penses. OpenZeppelin fournit une template :
`pragma solidity ^0.8.0;
import « @openzeppelin/contracts/token/ERC20/ERC20.sol »;
contract MyToken is ERC20 {
constructor() ERC20(« MonToken », « MYT ») {
_mint(msg.sender, 1000000 * 10 ** 18);
}
}`
Tu déploies ça avec Remix, et boom, tu as un token ERC-20 fonctionnel. Bien sûr, les vrais projets ajoutent de la mécanique (vesting, burn, governance), mais la base est là.
Risques : tokens malveillants et « rug pulls »
Le problème avec ERC-20 : n’importe qui peut créer un token et le nommer « Ethereum » ou « Bitcoin ». Les rug pulls courants :
— Tokens avec fees cachés à la vente (tu reçois moins que prévu)
— Tokens « non transfertable » (tu achètes, tu es piégé)
— Owner qui peut mint un supply infini (dilution)
— Honeypots : tu peux acheter mais pas vendre
Comment te protéger : vérifie l’adresse du token sur Etherscan, regarde le code du contrat, et teste avec un petit montant d’abord.
ERC-20 vs autres standards
ERC-20 est simple et fongible (tous les tokens sont identiques). Mais il existe des variantes :
ERC-721 : pour les NFTs (chaque token est unique)
ERC-1155 : pour les multi-tokens (fongibles et non fongibles dans un contrat)
Pour la plupart des cas (stablecoins, gouvernance, utilitaires), ERC-20 est le bon choix.
Conclusion
ERC-20 est le standard qui rend les tokens interopérables. En comprenant balanceOf, transfer, approve et transferFrom, tu comprends 90% de comment les tokens fonctionnent en DeFi. Le reste, c’est du détail. Si tu veux créer un token, OpenZeppelin le rend trivial. La vraie complexité, c’est la tokenomics et l’adoption, pas le smart contract.
—
