Jetons SPL et comptes de jetons dans SSP

Si vous avez utilisé des jetons ERC-20 sur Ethereum, le modèle de jetons de Solana vous semblera familier pendant une trentaine de secondes, puis cessera d'avoir du sens. Sur Ethereum, un contrat de jeton tient un registre de qui possède quoi, et votre adresse y figure comme une ligne. Sur Solana, votre adresse n'apparaît pas du tout dans les enregistrements du jeton. À la place, un compte distinct est créé pour détenir votre solde de ce jeton précis, vous appartenant mais distinct de votre adresse principale.

Cette seule décision de conception explique presque toutes les surprises que réservent les jetons SPL : pourquoi envoyer un jeton à quelqu'un de nouveau coûte plus cher qu'à quelqu'un qui en détient déjà, pourquoi un portefeuille peut afficher un solde nul pour une adresse qui n'a jamais touché ce jeton, et pourquoi les décimales comptent ici plus qu'ailleurs. Cet article parcourt le modèle tel que SSP l'implémente.

Pourquoi Solana a besoin d'un compte distinct par jeton

La règle fondamentale de Solana est que tout est un compte, et que chaque compte a un propriétaire, une taille et un dépôt de loyer proportionnel à cette taille. Il n'existe pas de contrat qui ferait discrètement grandir une table interne à mesure que les utilisateurs arrivent : le stockage doit vivre dans un compte quelque part, et quelqu'un doit le payer.

Le programme SPL Token répartit donc le travail. Le compte de mint conserve les faits relatifs au jeton lui-même : offre totale, décimales et qui peut en émettre davantage. Chaque détenteur obtient son propre compte de jeton, un petit compte de taille fixe qui enregistre un solde pour un mint et nomme un propriétaire. Votre solde en SOL vit à votre adresse ; votre solde en USDC vit dans un compte de jeton que votre adresse contrôle.

L'avantage de cette conception est la prévisibilité : chaque solde de jeton a la même forme et coûte la même chose à stocker. La contrepartie, c'est que détenir un nouveau jeton exige de faire naître un nouveau compte. La documentation sur les jetons de Solana est la source primaire si vous voulez la spécification plutôt que le résumé.

Le compte de jeton associé, et qui le paie

Si chaque détenteur a besoin d'un compte de jeton et que n'importe qui peut créer des comptes, vous vous retrouveriez avec plusieurs comptes de jeton par personne et par mint, sans moyen de savoir auquel envoyer. Le compte de jeton associé — ATA — est la convention qui règle cela : pour un propriétaire donné et un mint donné, il existe une adresse canonique unique, dérivée de façon déterministe des deux. Les portefeuilles peuvent la calculer, personne n'a donc à la publier.

Le hic, c'est le loyer. Un compte de jeton pèse environ 165 octets, ce qui représente à peu près 0,002 SOL immobilisés en dépôt de loyer tant que le compte existe. Ce dépôt est récupérable à la fermeture du compte, mais il doit être versé d'avance, et par quelqu'un qui possède du SOL — ce que le destinataire de son tout premier transfert de jetons, par définition, ne possède peut-être pas.

SSP traite cela comme n'importe quel autre frais Solana. Lorsque vous envoyez un jeton SPL à quelqu'un dont l'ATA n'existe pas, la transaction inclut une instruction idempotente pour le créer, et le paymaster de SSP paie le loyer. Votre coffre rembourse le paymaster à l'intérieur de la même transaction, et c'est pourquoi ce premier transfert vers un nouveau destinataire coûte environ 0,0025 SOL de plus qu'un transfert répété vers la même personne. « Idempotente » est le mot important : si le compte existe déjà, l'instruction réussit sans rien faire, au lieu de faire échouer tout le transfert.

Notez que cette instruction de création se situe en dehors de la proposition multisig. Créer le compte de jeton de quelqu'un ne déplace pas vos fonds et ne requiert aucune autorisation de votre coffre : elle n'a donc pas sa place dans la partie que signent vos deux appareils. Le remboursement, qui lui déplace vos fonds, est à l'intérieur de la proposition.

Ce que SSP prend en charge d'origine

SSP est livré avec le SOL natif, le mint USDC officiel de Circle et FLUX sur Solana. Tout autre jeton SPL apparaissant dans votre coffre est résolu et affiché à leurs côtés.

Une limite délibérée mérite d'être dite clairement : les transferts Solana de SSP sont construits sur le programme SPL Token classique. Les jetons émis sous Token-2022, le programme plus récent doté de transfer hooks, de transferts confidentiels et d'autres extensions, ne font pas partie du chemin d'envoi aujourd'hui. C'est un choix de périmètre et non un oubli : les extensions de Token-2022 peuvent modifier ce que fait un transfert, et les prendre en charge suppose d'auditer chacune d'elles au regard des garanties de décodage sur l'appareil décrites plus bas.

Comment un transfert de jetons est réellement construit

Quand vous envoyez un jeton SPL depuis SSP, la transaction signée contient, dans l'ordre :

1. Créer l'ATA du destinataire si nécessaire — idempotent, payé par le paymaster, hors de la proposition.
2. TransferChecked — déplace le solde du compte de jeton de votre coffre vers celui du destinataire, autorisé par le coffre.
3. Rembourser le paymaster — un simple transfert de SOL depuis votre coffre, à l'intérieur de la proposition.

Le tout atterrit en une seule transaction atomique. Pas d'étape d'approbation séparée, pas de proposition en attente traînant on-chain, et aucun état où le compte du destinataire aurait été créé sans que le transfert ait eu lieu. Soit l'ensemble s'exécute, soit rien.

Le compte source est l'ATA du coffre lui-même — dérivé de la même manière déterministe, avec l'adresse de programme du coffre comme propriétaire. Comme le coffre est une adresse dérivée de programme et non une paire de clés, la dérivation autorise explicitement un propriétaire situé hors de la courbe ed25519. Si vous voulez le détail sous-jacent expliquant pourquoi l'adresse du coffre fonctionne ainsi, le multisig Solana auto-initié le couvre.

Les décimales font partie de la signature

C'est le passage où il vaut la peine de ralentir, car c'est là qu'un jeton peut vous mentir.

Un mint déclare le nombre de décimales qu'utilise son jeton. USDC en utilise six ; beaucoup de jetons en utilisent neuf ; il n'y a pas de règle. Si un portefeuille affiche « 100 USDC » mais construit un transfert portant sur un nombre d'unités brutes fondé sur de mauvaises décimales, vous pouvez envoyer mille fois trop sans rien voir d'anormal à l'écran.

SSP utilise TransferChecked plutôt que l'instruction de transfert simple. La différence tient à ce que TransferChecked intègre l'adresse du mint et l'octet des décimales directement dans les données de l'instruction signée. Trois vérifications distinctes en découlent :

• Votre extension décode les octets et les compare à ce qu'elle affiche.
• SSP Key décode les mêmes octets indépendamment sur votre téléphone et les compare aux métadonnées du jeton fournies par l'extension.
• Le programme SPL Token on-chain compare les décimales de l'instruction aux décimales réelles du mint et rejette la transaction si elles diffèrent.

La troisième vérification est celle qu'on ne contourne pas par le discours. Un mint qui annonce d'autres décimales que les siennes ne produit pas un mauvais transfert : il produit une transaction échouée.

Recevoir des jetons

Recevoir est plus simple, avec une subtilité. Donnez à l'expéditeur votre adresse de portefeuille — celle que SSP affiche sur l'écran de réception — et non une adresse de compte de jeton. Quoi qu'il envoie, le bon ATA est dérivé de votre adresse et du mint, et le portefeuille de l'expéditeur le crée si nécessaire.

Si votre coffre n'a jamais détenu ce jeton, le compte n'existera pas tant que le premier transfert n'arrivera pas, et son loyer est payé par celui qui vous envoie. C'est normal et ne demande rien de votre part. Cela signifie en revanche qu'un explorateur de blocs n'affichera aucun compte de jeton pour un jeton qu'on vous a promis mais que vous n'avez pas encore reçu — c'est le compte qui n'existe pas encore, pas un transfert perdu.

Pièges courants

Envoyer à une adresse de compte de jeton au lieu d'une adresse de portefeuille. Certains explorateurs mettent l'ATA bien en évidence. Envoyer un jeton à un compte de jeton plutôt qu'à son propriétaire est une manière bien connue de perdre des fonds sur Solana. SSP attend l'adresse de portefeuille du propriétaire et dérive le reste.

Supposer qu'un jeton inconnu est sûr parce qu'il apparaît dans votre portefeuille. N'importe qui peut créer un mint et vous l'envoyer, et les mints peuvent porter des noms imitant de vrais jetons. Qu'un jeton apparaisse dans votre coffre n'est pas une caution. Vérifiez l'adresse du mint auprès d'une source officielle avant de traiter un solde comme une valeur réelle.

Attendre des approbations à la manière d'Ethereum. Les jetons SPL disposent d'un mécanisme de délégué, mais le schéma d'autorisation permanente qui fait des approbations ERC-20 un risque récurrent n'est pas la façon dont la plupart des applications Solana sont construites. Si vous venez d'Ethereum, les approbations de jetons : ces permissions que vous accordez sans cesse explique l'habitude que vous désapprenez, et Ethereum dans SSP fournit la comparaison.

Oublier la majoration du premier envoi. Les ~0,0025 SOL supplémentaires lors d'un premier transfert vers un nouveau destinataire sont un loyer, pas des frais encaissés par SSP. Ils restent dans le compte de jeton du destinataire et sont récupérables par lui s'il le ferme un jour.

Pour la mécanique pas à pas d'un transfert réel, voyez envoyer du Solana avec SSP. Pour comprendre comment SSP conserve le coffre sous-jacent dans un multisig 2 sur 2 sans créateur, commencez par Solana dans SSP.