Sui Wallet, l'ancien nom de Slush

2026-08-24

Sui Wallet est l'ancien nom de produit de Mysten ; Mysten a annoncé le 2025-04-24 que Sui Wallet et Stashed étaient regroupés sous le nom Slush. Ce profil neutre sépare le système documenté, sa dénomination actuelle et le rôle annoncé de SUI.

Ce profil répond d'abord à la question de l'identité et du mécanisme, puis maintient séparés le nom du projet, ses composants documentés et l'état changeant de son service. Les requêtes « sui wallet extension » ; « sui wallet security » ; « sui wallet setup » peuvent décrire l'intention de recherche d'un lecteur, mais elles ne prouvent ni une fonctionnalité du produit, ni un droit actuel, ni une conclusion financière. L'article emploie donc une formulation bornée au périmètre des sources et ne traite ni un ticker ni une interface utilisateur comme un raccourci pour l'ensemble du système.

Qu'est-ce que Sui Wallet and Slush

Sui Wallet et Slush doivent se lire dans le périmètre de leurs sources primaires en vigueur. Le sujet exact est donc une frontière de conservation et de dénomination de produit : l'ancien libellé du produit, le produit Slush actuel et la catégorie plus large des portefeuilles compatibles avec Sui ne sont pas des choses identiques. Ce cadrage évite une erreur courante dans les profils de projet : employer une seule étiquette pour une organisation, un protocole, une interface, un actif et tout service qui peut leur être associé. Une description soigneuse nomme la couche dont il est question et ne suppose pas qu'un énoncé portant sur une couche prouve automatiquement un énoncé portant sur une autre.

La difficulté pratique tient ici à l'interprétation, pas au vocabulaire, et l'historique des noms la rend concrète. Sui Wallet est un ancien nom de produit de Mysten, Slush est le produit actuel, Sui est le réseau et SUI est l'actif du réseau : quatre sujets différents se partagent trois noms qui se recouvrent. Un contenu publié avant le 2025-04-24 peut être exact au sujet de l'extension qu'il décrivait et décrire malgré tout de travers ce qui s'installe aujourd'hui. C'est le fait d'attacher le nom, la date et la couche à chaque énoncé qui permet de lire les sources anciennes et récentes côte à côte sans les confondre.

Le changement de nom a une date, et il a été plus qu'un changement de nom. Mysten Labs a publié le 2025-04-24 un billet intitulé Sui Wallet and Stashed are Now Slush, décrivant une fusion de l'extension Sui Wallet avec Stashed et non un simple changement d'étiquette ; le billet précise que la modification est arrivée sous forme de mise à jour ordinaire, qu'aucune réinstallation ni migration n'était nécessaire et que les comptes, les phrases de récupération et les adresses de portefeuille sont restés inchangés. Stashed Links est devenu Slush Links et la capacité zkLogin a été intégrée. L'application web se trouve à my.slush.app et le pied de page du site mentionne Mysten Labs, Inc.

Quel périmètre documentaire aide à l’expliquer

Au niveau du mécanisme, un portefeuille auto-conservé se comprend au mieux comme un logiciel qui gère du matériel d'autorisation pour une activité en chaîne, tandis que les actifs et les enregistrements publics demeurent sur le réseau et non dans l'application. Le point important n'est pas une promesse de performance ; c'est la relation que les documents décrivent entre les composants. Ces composants peuvent avoir des calendriers de mise à jour, des permissions, des dépendances techniques et des conditions d'exploitation différents. Expliquer cette relation montre pourquoi une étiquette de produit ne suffit pas à déterminer ce qu'un enregistrement, une fonctionnalité ou un actif représente réellement.

Le mécanisme documenté a lui aussi besoin d'une frontière probatoire. Une documentation publique a en général un éditeur, une date, une version de produit et un objet limité. Elle peut être modifiée ou remplacée. Un profil précis peut dire qu'une page décrit une architecture annoncée, mais il ne doit pas élargir tacitement cette page en une affirmation selon laquelle toute application liée serait en service, toute intégration à jour et tout élément de feuille de route déjà livré. Ce sont là des affirmations distinctes, qui exigent chacune leur propre source en vigueur.

Comment distinguer composants et limites

SUI figure dans ce profil au titre d'un rôle d'actif documenté, non comme un verdict sur la propriété ou la valeur. SUI est l'actif natif du réseau, employé pour les fonctions du réseau Sui. Ce n'est pas un jeton émis par l'ancien produit Sui Wallet ni par Slush. Un ticker est une preuve particulièrement faible lorsqu'il existe des actifs de nom voisin, plusieurs réseaux, des jetons de reçu, des contrats d'implémentation ou des déploiements historiques. Le contrôle du jour de publication doit comparer l'identifiant officiel en vigueur avec l'enregistrement officiel pertinent, conserver le contexte réseau et ne pas tenir un symbole recopié pour une preuve définitive.

Une bonne façon de lire la section consacrée à l'actif consiste à demander ce qu'il fait dans le système documenté, ce qu'il n'établit pas et quelles affirmations restent sensibles au temps. Un rôle décrit de coordination, d'accès, de sécurité ou de participation ne confère pas automatiquement à chaque détenteur un droit sur le produit, un résultat de gouvernance, un droit à distribution ou une garantie de service. La source peut employer une formulation conditionnelle, et un profil neutre doit préserver cette condition au lieu de la remplacer par un énoncé plus fort.

Ce que SUI fait dans le système

L'écosystème du projet doit lui aussi s'interpréter étroitement. Un pôle de documentation peut présenter des composants, du code, des environnements, des fournisseurs ou des catégories d'interface, mais il ne constitue pas automatiquement une liste permanente de partenaires actifs ou de services pris en charge. Le mot écosystème n'est utile que s'il renvoie à un périmètre de source défini. Il ne doit pas servir à laisser entendre qu'une organisation contrôle toutes les applications liées ou que chaque intégration citée se poursuit sans interruption.

Le produit actuel et ses conditions doivent être attribués à Slush, tandis que les affirmations historiques sur Sui Wallet doivent conserver leur date et leur périmètre de source. Cette distinction compte parce que les noms de produit et de protocole persistent souvent alors que leurs interfaces, permissions, contrats, politiques et disponibilité changent. Un profil qui identifie la source en vigueur et son affirmation exacte donne au lecteur le moyen de réexaminer les éléments plus tard. Un profil qui transforme une page datée en assertion permanente donne un faux sentiment de certitude.

L’écosystème de Sui Wallet and Slush et le périmètre documentaire

zkLogin est une primitive d'authentification de Sui qui peut apparaître dans des expériences applicatives ; elle ne doit pas être comprimée en une affirmation selon laquelle chaque portefeuille, type de compte ou dispositif de récupération aurait les mêmes propriétés. C'est pourquoi les libellés de réseau, les contrats, les enregistrements de mint ou les URL d'application sont des faits à vérifier le jour de la publication, non une prose intemporelle. Un article neutre peut expliquer les catégories en jeu sans demander au lecteur d'agir. Il doit consigner la différence entre un identifiant officiel et une instruction opérationnelle, et ne pas convertir un principe de vérification en tutoriel de dépôt, réclamation, pont, staking ou gestion de compte.

Sui Wallet, l'ancien nom de Slush documentation overview

Aux limites de dénomination s'ajoutent des limites techniques. Un logiciel repose sur des hypothèses d'implémentation, les services dépendent d'une infrastructure, les contrats peuvent exposer des contrôles administratifs, et les enregistrements hors chaîne peuvent avoir des propriétés de conservation, de confidentialité et de mise à jour différentes de celles des enregistrements en chaîne. Une description d'architecture n'est pas un audit, et une mention d'audit n'est pas une garantie de sécurité générale. Ces distinctions pèsent davantage lorsqu'un projet met en jeu des données, une identité, une exécution déléguée, du matériel d'autorisation ou une structure de jeton évolutive.

Le plus utile à connaître au sujet de l'extension est son identifiant. La fiche du Chrome Web Store est publiée par Mysten Labs sous l'identifiant d'extension opcgpfmipidbgpenhmajoajpbobppdil, affiche le nom Slush et, au 2026-08-15, faisait état d'environ 800 000 utilisateurs et d'une dernière mise à jour à cette même date. L'ancienne adresse de la boutique contenant sui-wallet se résout toujours et redirige vers l'adresse canonique actuelle, ce qui constitue en soi la preuve la plus nette qu'une fiche a été renommée et non remplacée. Les versions mobiles officielles pour iOS et Android sont liées depuis slush.app/download, et les canaux officiels cités dans le pied de page du site sont Discord, X, Instagram, YouTube et support.slush.app ; il n'existe pas de Telegram officiel.

Une limite de conception précise

La frontière des sources est aussi une frontière de sécurité pour le lectorat, et pour une extension de navigateur cette frontière est un identifiant plutôt qu'une adresse. La fiche du Chrome Web Store est publiée par Mysten Labs sous l'identifiant d'extension opcgpfmipidbgpenhmajoajpbobppdil et affiche le nom Slush ; l'ancienne adresse de boutique contenant sui-wallet se résout encore et redirige vers elle, ce qui constitue en soi la preuve qu'une fiche a été renommée et non remplacée. Une imitation peut copier le nom, l'icône et les captures d'écran, mais elle ne peut pas occuper cet identifiant. L'application web s'atteint de préférence en saisissant my.slush.app plutôt qu'en suivant un lien.

La perte d'identifiants, l'hameçonnage, les liens trompeurs, les invites d'application malveillantes, les effets irréversibles en chaîne et l'évolution des conditions du produit restent des risques, même lorsque le logiciel propose des fonctions de sécurité. Ces risques ne signifient pas que la conception documentée serait invalide ; ils signifient qu'un profil bref ne doit pas affirmer plus qu'il n'établit. La conclusion appropriée est conditionnelle : la documentation soutient le mécanisme qu'elle décrit effectivement, sous réserve de l'implémentation, de la gouvernance, de la fraîcheur de la source et du contexte technique et juridique environnant. Pour les affirmations relatives à l'accès, à la performance, aux détentions, aux allocations, au périmètre d'audit ou au traitement régional, il faut des éléments plus récents.

Risques et limites

Le risque naît aussi de la fusion de termes distincts. Un réseau n'est pas automatiquement un portefeuille, une preuve n'est pas automatiquement la donnée brute, un jeton de reçu n'est pas automatiquement l'actif du protocole, et un identifiant public n'est pas automatiquement le seul déploiement valide. Garder ces distinctions visibles aide à repérer les fausses équivalences, les prétentions de droits non étayées et les affirmations sensibles au temps. Cela rend aussi l'article utile sans le transformer en comparatif, en recommandation ou en guide opérationnel.

Une vérification neutre commence par le domaine officiel du projet et sa hiérarchie de documentation. Il faut contrôler le nom exact employé par l'éditeur, le rôle qui y est attribué à SUI et le périmètre de tout avis technique ou juridique en vigueur. Si une page officielle fournit une adresse de contrat ou un identifiant équivalent, il est possible de comparer la date, le réseau et le libellé avec l'enregistrement correspondant de l'explorateur de blocs officiel. Il ne faut pas déduire une relation d'un symbole identique, d'une adresse recopiée ou d'une page dont le périmètre n'a rien à voir avec l'affirmation examinée.

Deux limites méritent d'être énoncées avec précision. Premièrement, la page de sécurité décrit une gestion non dépositaire des clés, une liste de blocage anti-hameçonnage open source entretenue par la communauté, l'intégration de portefeuilles matériels et la détection d'arnaques, mais elle ne divulgue aucune extension contrefaite ni aucun site d'hameçonnage précis ; le présent article n'en nomme donc aucun, car inventer un exemple serait pire que décrire la vérification. La règle pratique est que les points d'entrée officiels énumérés ci-dessus forment l'ensemble complet et que rien en dehors de cet ensemble ne devrait être installé. Deuxièmement, la portée est plus étroite que ne le suggère le mot portefeuille, car Slush ne prend en charge que Sui et n'est pas un portefeuille multichaîne.

Comment vérifier les informations sur Sui Wallet and Slush

Avant publication, les identifiants et les affirmations datées de cet article méritent d'être relus dans leurs propres sources : la fiche du Chrome Web Store, pour l'identifiant d'extension, le nom de l'éditeur, le nom affiché, le nombre d'utilisateurs indiqué et la date de dernière mise à jour ; les liens de téléchargement des versions mobiles officielles ; et la liste des canaux figurant dans le pied de page, y compris l'affirmation qu'il n'existe pas de Telegram officiel. Le billet de changement de nom et sa date relèvent de la même passe. Cette seconde passe compte, car une description exacte de l'auto-conservation peut rester vraie des années alors qu'une fiche de boutique, une page de téléchargement et une adresse d'assistance se déplacent.

Sui Wallet et Slush peut donc être présenté comme un système documenté à couches distinctes, et non comme un produit unique et indifférencié. SUI doit être décrit uniquement par le rôle que lui attribuent les sources, et toute affirmation plus précise doit conserver son contexte de réseau, de contrat, d'interface ou de produit. Cela explique le projet sans traiter la documentation comme une offre, une garantie ou une instruction.

La vérification de l'identifiant est la seule étape que l'apparence ne peut pas falsifier. La fiche de la boutique peut être ouverte et l'identifiant d'extension comparé caractère par caractère avec opcgpfmipidbgpenhmajoajpbobppdil, l'éditeur étant confirmé comme Mysten Labs ; une fiche sosie peut copier le nom, l'icône et les captures d'écran, mais elle ne peut pas occuper le même identifiant. Le même principe vaut pour l'application web, que l'on atteint mieux en saisissant my.slush.app qu'en suivant un lien, et pour le support, que l'on atteint mieux depuis l'adresse figurant dans le pied de page du site que depuis un message non sollicité.

Conclusion

La règle d'interprétation centrale est la séparation. Le nom d'un projet ne vaut pas pour chaque couche de produit. Un symbole de jeton ne vaut pas pour chaque contrat ni chaque réseau. Une interface en vigueur n'est pas une déclaration de disponibilité intemporelle. Une description technique n'est pas une certification de sécurité. Une fois ces distinctions explicitées, il devient possible de comparer les sources avec plus de soin et d'éviter de transposer une affirmation d'une catégorie à une autre.

Pour une version prête à publier, il faut garder le mécanisme, le rôle de l'actif et la limite documentaire dans des phrases distinctes. N'ajoutez pas d'affirmations sur l'offre, les allocations, les audits, la gouvernance, les partenaires, le statut juridique, la performance ou l'accès, sauf si une source officielle récente couvre précisément l'affirmation. Si la formulation de la source est conditionnelle ou prospective, conservez cette réserve. Cette approche est délibérément prudente parce qu'elle est plus exacte pour des systèmes dont les détails de produit, de réseau et de jeton peuvent changer.

En résumé, la question responsable n'est pas seulement de savoir ce qu'est Sui Wallet et Slush, mais quelle couche exacte une source décrit, ce que SUI est documenté comme faisant, et quels éléments doivent encore être vérifiés le jour de la publication. Cette approche laisse au lectorat la possibilité de consulter les enregistrements officiels tout en gardant l'article pédagogique, neutre et exempt de conclusions financières ou d'instructions d'utilisation.

Pages de marché associées

Pages Bitbase pour les jetons cités dans cet article :

- SUI : Voir le prix · Marché spot · Marché des contrats perpétuels

Articles associés

Autres articles Bitbase sur ce sujet :

- Portefeuilles MPC et à seuil

- Héritage en multisignature et mécanismes de signal absent

- Phrase de récupération et passphrase : la différence et pourquoi elle compte

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il explique ce que fait un projet et quel rôle son jeton joue dans ce système ; il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance, et il ne vaut ni recommandation ni approbation d'un projet ou d'un jeton. Bitbase n'a pas effectué de diligence raisonnable sur le projet décrit ici, et le mentionner ne signifie pas que Bitbase référence ou prend en charge cet actif. Les cryptoactifs comportent un risque important, notamment la volatilité des prix, une liquidité faible, la défaillance des contrats intelligents, l'incertitude réglementaire et la perte possible de toute leur valeur. Rédigé en août 2026 ; le statut d'un projet, sa tokenomics, son équipe et ses contrats peuvent changer à tout moment. Vérifiez tout par vous-même via les canaux officiels, l'adresse du contrat et un explorateur de blocs, et méfiez-vous des sites imitant le projet et des liens d'hameçonnage.