[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"blog-content-fr-erc-20-vs-spl-vs-jetton":3},{"slug":4,"title":5,"excerpt":6,"description":7,"bodyHtml":8,"faqItems":9},"erc-20-vs-spl-vs-jetton","ERC-20 vs SPL vs Jetton : pourquoi le « même » token fonctionne différemment sur chaque chaîne","ERC-20, SPL et Jetton décrivent tous « un token », mais ils stockent les soldes à des endroits complètement différents. Voici ce qui se passe réellement sous le capot sur Ethereum, Solana et TON, et pourquoi cela change la façon dont les transferts réussissent ou échouent.","En quoi ERC-20, SPL et Jetton diffèrent : où vivent les soldes de tokens sur Ethereum, Solana et TON, et pourquoi le même ticker est un token différent sur chaque chaîne.","\u003Cblockquote>ERC-20, SPL et Jetton répondent de trois façons à une seule question : où est stocké le nombre qui enregistre votre solde. Ethereum garde le solde de chaque détenteur dans un unique contrat de token partagé, Solana dans un token account distinct par détenteur, et TON dans un contrat distinct par détenteur. Cette différence explique les approbations, les frais et la plupart des modes de défaillance, ainsi que le fait que le même ticker soit un token différent sur chaque chaîne. Les wallets qui couvrent les trois, comme WATS — qui prend en charge l'EVM, Solana et TON, mais pas Bitcoin nativement —, doivent parler ces trois grammaires.\u003C\u002Fblockquote>\u003Ch2>Ce qu'est réellement un « standard de token »\u003C\u002Fh2>\u003Cp>Un standard de token est une interface convenue : noms de fonctions, formats de messages et événements sur lesquels s'appuient les wallets et les exchanges. En dessous, il n'y a que du code ordinaire, et la manière dont chaque chaîne exécute ce code façonne ce qu'un token peut être.\u003C\u002Fp>\u003Cp>\u003Cstrong>ERC-20, SPL et Jettons ne sont pas trois dialectes d'une même chose.\u003C\u002Fstrong> Ils répondent de trois façons à une seule question : \u003Cem>où vit le nombre qui dit « vous possédez 500 tokens » ?\u003C\u002Fem> Ethereum le garde dans un unique contrat partagé, Solana dans un compte distinct par détenteur, TON dans un contrat distinct par détenteur — des modèles de stockage qui expliquent presque toutes les bizarreries pratiques, par-dessus l'architecture comparée dans \u003Ca href=\"\u002Fblog\u002Fevm-vs-solana-vs-ton\">EVM, Solana et TON\u003C\u002Fa>.\u003C\u002Fp>\u003Ch2>ERC-20 sur Ethereum : un seul contrat détient les soldes de tout le monde\u003C\u002Fh2>\u003Cp>Un token ERC-20 est un seul smart contract à une seule adresse, qui tient un registre associant des adresses à des nombres. Vous ne « détenez » pas le token ; le contrat détient une écriture indiquant qu'un montant est dû à votre adresse.\u003C\u002Fp>\u003Cp>Un transfert est un appel \u003Cem>au contrat du token\u003C\u002Fem>, qui diminue une ligne et en augmente une autre. Votre adresse n'a besoin d'aucune préparation : vous pouvez recevoir n'importe quel ERC-20 sur une adresse qui n'a jamais touché ce token.\u003C\u002Fp>\u003Cp>Cela explique pourquoi vous pouvez détenir une fortune en tokens sans pouvoir la déplacer : appeler un contrat coûte du gas, réglé par défaut dans le token natif de la chaîne. En 2026, ce défaut n'est plus absolu — un paymaster ERC-4337 permet à quelqu'un d'autre que le propriétaire du compte de payer, et EIP-7702 permet à un tiers de soumettre et de payer la transaction de type 4 qui définit la délégation d'un compte, même si le sponsoring au-delà dépend de ce que le code délégué implémente. Le réseau facture toujours le travail effectué ; seul le payeur change.\u003C\u002Fp>\u003Ch2>SPL sur Solana : token accounts, rent et mint\u003C\u002Fh2>\u003Cp>Solana répartit le travail en deux. Un \u003Cstrong>compte mint\u003C\u002Fstrong> définit le token — l'offre, les décimales, et quelle autorité peut émettre ou geler. Les soldes vivent dans des \u003Cstrong>token accounts\u003C\u002Fstrong> séparés. Le Token Program est propriétaire des données de ce compte, tandis que le compte désigne un détenteur comme owner et autorité de dépense ; rien ne vous limite à un seul compte par mint.\u003C\u002Fp>\u003Cp>Les wallets se sont donc standardisés sur l'associated token account, dérivé de votre adresse de wallet, du mint et de l'id du token program. Il doit exister et être financé : l'exemption de rent bloque un petit montant de SOL, récupérable, dans le compte pour le maintenir en vie.\u003C\u002Fp>\u003Cp>Recevoir un nouveau token SPL est donc un événement on-chain, même si la plupart des transferts intègrent la création du compte. En 2026, Token-2022 ajoute des frais de transfert optionnels, des soldes confidentiels et des transfer hooks ; comme son program id sert de seed de dérivation, ses mints dérivent un associated token account différent de celui des mints classiques.\u003C\u002Fp>\u003Ch2>Jettons sur TON : chaque détenteur reçoit son propre contrat\u003C\u002Fh2>\u003Cp>TON pousse la séparation le plus loin. Un jetton possède un \u003Cstrong>contrat master\u003C\u002Fstrong> qui détient les métadonnées et l'offre, et chaque détenteur obtient son propre \u003Cstrong>contrat jetton wallet\u003C\u002Fstrong> ne stockant que son solde pour ce token précis.\u003C\u002Fp>\u003Cp>Les transferts sont des messages asynchrones, pas des appels dans un registre partagé : votre contrat jetton wallet envoie un message à celui du destinataire, qui crédite le solde. Comme TON est shardé, cela se résout sur des blocs successifs plutôt qu'en une étape atomique.\u003C\u002Fp>\u003Cp>Chaque message doit transporter assez de TON pour la computation qu'il déclenche en aval, y compris le déploiement du jetton wallet du destinataire si nécessaire ; en attacher trop peu et il peut rebondir (bounce) ou rester bloqué. Cette orientation (TEP-74, en 2026) permet à TON de passer à l'échelle horizontalement, et fait trébucher le code de transfert naïf écrit pour l'EVM.\u003C\u002Fp>\u003Ch2>Approbations, frais et modes de défaillance : là où les trois divergent\u003C\u002Fh2>\u003Cp>Les approbations sont la divergence la plus nette. ERC-20 dispose du modèle d'allowance : vous accordez à un contrat la permission de déplacer jusqu'à un certain montant de vos tokens, et elle persiste jusqu'à révocation — c'est pourquoi une signature négligente peut vider un wallet des mois plus tard ; voir \u003Ca href=\"\u002Fblog\u002Ftoken-approvals-and-permit-explained\">les approbations de tokens et permit expliqués\u003C\u002Fa> et \u003Ca href=\"\u002Fblog\u002Fhow-to-revoke-token-approvals\">comment révoquer les approbations de tokens\u003C\u002Fa>.\u003C\u002Fp>\u003Cp>Solana n'est pas l'antidote : un approve SPL définit un delegate sur votre token account qui survit à la transaction, et setAuthority peut réassigner le compte purement et simplement — deux vecteurs de drainer connus. Une transaction Solana liste tous les comptes qu'elle va toucher, mais cela ne contraint que la transaction signée, pas les permissions permanentes. TON n'a pas d'allowance à la manière d'ERC-20.\u003C\u002Fp>\u003Cp>Les frais divergent aussi : l'EVM tarifie le gas par unité de computation, Solana applique un frais de base fixe par signature plus un frais de priorité optionnel, TON facture par message. Les modes de défaillance également : sur EVM, des tokens échoués dans un contrat incapable de les gérer ; sur Solana, un token account manquant ; sur TON, trop peu de valeur attachée.\u003C\u002Fp>\u003Ch2>Pourquoi le même ticker n'est pas le même token d'une chaîne à l'autre\u003C\u002Fh2>\u003Cp>Deux actifs qui partagent un ticker ne partagent rien techniquement. L'USDC sur Ethereum est une adresse de contrat, sur Solana une adresse de mint ; sur TON, un stablecoin émis nativement comme l'USDT repose sur son propre jetton master. Chacun est un objet on-chain distinct avec sa propre offre, et une version bridgée est encore une autre créance.\u003C\u002Fp>\u003Cp>Envoyer d'un écosystème à l'autre — un token EVM vers une adresse Solana ou TON — est généralement irrécupérable ; \u003Ca href=\"\u002Fblog\u002Fsent-crypto-to-wrong-network-how-to-recover\">crypto envoyée sur le mauvais réseau, comment récupérer\u003C\u002Fa> expose ce qui peut être sauvé. D'EVM à EVM, c'est souvent plus indulgent : un externally owned account, y compris délégué via EIP-7702, est contrôlé par la même clé à l'adresse identique sur chaque chaîne, et un smart account de type ERC-4337 non déployé sur la chaîne de destination peut normalement y être redéployé avec la même factory et le même init code. Les formats d'adresse sont un indice, traités dans \u003Ca href=\"\u002Fblog\u002Fcrypto-address-formats-explained\">les formats d'adresses crypto expliqués\u003C\u002Fa> ; savoir si une offre canonique unique se déplace ou si une nouvelle créance est émise fait toute la différence entre \u003Ca href=\"\u002Fblog\u002Fomnichain-vs-wrapped-bridged-tokens\">les tokens omnichain et les tokens wrappés ou bridgés\u003C\u002Fa>.\u003C\u002Fp>\u003Ch2>Ce que cela signifie pour votre wallet (et comment WATS le gère)\u003C\u002Fh2>\u003Cp>Un wallet multi-chaînes doit parler ces trois grammaires, et vous ne devriez jamais voir la différence — mais les frais transparaissent, car chaque chaîne attend son propre token de gas natif. En 2026, cette attente est négociable, à condition que le wallet soit conçu pour cela.\u003C\u002Fp>\u003Cp>Le WATS Hot Wallet fait exactement cela : chaque action — transferts, swaps, staking — est facturée dans un seul token, ATS, à la place du gas natif de la chaîne, via un paymaster ERC-4337 sur l'EVM et un équivalent fee-payer et relayer sur Solana et TON, puisque ERC-4337 est réservé à l'EVM. ATS est un OFT LayerZero, si bien qu'un seul solde fonctionne sur EVM, Solana et TON. Cela ne change pas ce que le réseau facture — les \u003Ca href=\"\u002Fats-fee\">frais ATS\u003C\u002Fa> suivent le coût réseau en direct — cela change le token dans lequel ce coût est réglé. Les ATS collectés sont brûlés, de 100 millions vers un plancher de 30 millions. Cela reste non-custodial : vous détenez vos clés et WATS ne détient jamais de clé. WATS est le premier et le seul wallet à combiner ERC-4337 et des frais en un seul token via OFT, facturés à la place du gas natif, avec ce burn.\u003C\u002Fp>",[10,13,16],{"q":11,"a":12},"Pourquoi recevoir un token SPL coûte-t-il quelque chose sur Solana mais pas sur Ethereum ?","Sur Ethereum, votre solde n'est qu'une ligne à l'intérieur du contrat du token lui-même : la réception est donc gratuite pour le destinataire et ne demande aucune préparation. Sur Solana, la première fois que vous recevez un mint donné, un token account doit exister pour lui, et maintenir ce compte on-chain exige un petit dépôt d'exemption de rent en SOL, récupérable à la fermeture du compte. En pratique, la transaction de l'expéditeur crée et finance généralement ce compte dans la même étape, si bien que le coût retombe sur l'expéditeur et que le destinataire ne le voit jamais.",{"q":14,"a":15},"Qu'est-ce qui différencie un transfert de jetton TON d'un transfert ERC-20 ?","Un jetton donne à chaque détenteur son propre smart contract, qui ne stocke que son solde. Un transfert est un message asynchrone de votre contrat jetton wallet vers celui du destinataire, qui se résout sur des blocs successifs plutôt qu'en un seul appel atomique. Chaque message doit transporter assez de TON pour payer le travail qu'il déclenche, sinon il peut rebondir.",{"q":17,"a":18},"L'USDC sur Ethereum est-il le même token que l'USDC sur Solana ?","Non. Ce sont des objets on-chain distincts, avec des adresses, des offres et des standards distincts, même s'ils partagent un ticker et un émetteur. Envoyer l'un vers une adresse de l'autre chaîne est normalement irrécupérable, et les versions bridgées d'un ticker sont distinctes de celles émises nativement.",1786059329623]