Une sauvegarde, de nombreux comptes
Les premiers portefeuilles crypto gardaient un sac en vrac de clés privées aléatoires — fichier perdu, monnaies perdues, et chaque nouvelle adresse exigeait une nouvelle sauvegarde. Les portefeuilles modernes ont résolu cela avec une idée d'une simplicité trompeuse : générer chaque clé dont vous aurez besoin à partir d'un unique secret maître, de façon déterministe. C'est le portefeuille HD — hiérarchique déterministe — et c'est pourquoi une seule seed phrase écrite sur papier peut restaurer des dizaines de comptes sur plusieurs blockchains, des années plus tard, dans un logiciel qui ne les avait jamais vus.
Des mots à la seed maîtresse : BIP-39
La seed phrase elle-même provient d'un standard appelé BIP-39. Le portefeuille tire de l'entropie aléatoire, la projette sur une liste de mots fixe et vous remet 12 ou 24 mots avec une somme de contrôle intégrée. Passés dans une fonction d'étirement de clé, ces mots deviennent une grande seed maîtresse binaire. Deux propriétés comptent : les mots ne sont pas les clés — ils en sont la recette — et le processus est à sens unique et reproductible. N'importe quel portefeuille BIP-39, nourri des mêmes mots, calcule la même seed maîtresse, pour toujours. C'est ce qui fait de la phrase une sauvegarde complète, et pourquoi nous traitons sa protection comme l'habitude centrale de l'auto-conservation dans notre guide de la seed phrase.
L'arbre de dérivation : BIP-32
À partir de cette seed maîtresse, BIP-32 définit comment faire pousser un arbre de clés. La clé maîtresse dérive des clés enfants de façon déterministe, les enfants dérivent des petits-enfants, et chaque branche est reproductible depuis la racine. C'est la hiérarchie qui permet à un seul secret de servir une structure illimitée : des comptes séparés pour épargner et dépenser, une adresse de réception neuve pour chaque paiement, des chaînes entières sur leurs propres branches — le tout récupérable depuis les mêmes 12 ou 24 mots, sans jamais rien de nouveau à sauvegarder.
Chemins de dérivation : l'adresse d'une adresse
Un chemin de dérivation — la chaîne cryptique du type m/44'/60'/0'/0/0 aperçue peut-être dans les réglages avancés — n'est qu'un itinéraire dans cet arbre : quel usage, quelle monnaie, quel compte, quel index. BIP-44 a standardisé la disposition, attribuant à chaque blockchain son propre numéro de monnaie pour qu'une branche Ethereum et une branche Solana n'entrent jamais en collision. Les écosystèmes utilisent aussi des schémas de signature différents sous le capot (les clés de Solana, par exemple, viennent d'une autre courbe que celles d'Ethereum), mais le principe tient partout : seed plus chemin égale clé, à chaque fois.
Ce qu'un xpub révèle
L'arbre a encore un tour dans son sac : les clés publiques étendues. Un xpub permet à un logiciel de dériver toutes les adresses publiques d'une branche — mais aucune des clés privées. Cela permet des vues de portefeuille en lecture seule et des adresses de réception générées au nom d'un appareil hors ligne. La réserve concerne la confidentialité, pas la sécurité : quiconque détient votre xpub peut voir chaque adresse de cette branche et les relier entre elles. Partagez-le comme vous partageriez un relevé complet de ce compte, car c'en est fonctionnellement un.
Même seed, adresses différentes ?
Un grand classique du support : vous importez votre seed dans un autre portefeuille et le solde paraît vide. Presque toujours, rien n'est perdu — le second portefeuille emprunte un chemin différent dans le même arbre, ou dérive par défaut pour une autre chaîne. Les fonds sont exactement là où ils ont toujours été, sur la branche que le portefeuille d'origine utilisait. C'est aussi la réserve honnête sur les sauvegardes « universelles » : le standard de la seed est partagé, mais les conventions de chemin varient d'un portefeuille à l'autre, si bien que la restauration marche le mieux dans la famille de portefeuilles qui a créé la seed — ou dans un portefeuille qui balaie les chemins courants pour vous.
Comment WATS l'utilise
Le design HD est ce qui rend possible un vrai portefeuille multichain, et WATS s'y appuie pleinement : une sauvegarde, une identité, avec les comptes EVM, Solana et TON dérivés sur leurs branches propres — l'expérience décrite dans gérer Ethereum, Solana et TON dans un seul portefeuille. WATS est non-custodial de bout en bout : la seed et chaque clé qui en dérive n'existent que de votre côté, et WATS ne détient jamais de clé. La couche de frais est unifiée à l'avenant : chaque action — transferts, échanges, staking — est facturée dans un seul token, l'ATS, au lieu du gas natif de chaque chaîne, via un paymaster ERC-4337 sur EVM et un fee-payer/relayer équivalent sur Solana et TON. L'ATS est un OFT LayerZero, donc un seul solde couvre les trois écosystèmes, et l'ATS collecté est brûlé, de 100M vers un plancher de 30M. WATS est le premier et le seul portefeuille à combiner les frais en token unique ERC-4337 + OFT avec ce burn — la mécanique est sur la page des frais ATS.
Foire aux questions
Une seule seed phrase peut-elle vraiment sauvegarder toutes mes chaînes et tous mes comptes ?
Oui — c'est tout l'intérêt du design HD. La seed génère de façon déterministe un arbre de clés, avec des branches séparées par blockchain et par compte, si bien que chaque adresse qu'un portefeuille crée pour vous est récupérable depuis les mêmes 12 ou 24 mots. Le revers, c'est la concentration du risque : quiconque détient la phrase peut reconstruire l'arbre entier — la seed mérite donc votre protection la plus forte.
Pourquoi ma seed affiche-t-elle des adresses différentes dans un autre portefeuille ?
Parce que le second portefeuille dérive le long d'un chemin différent ou pour d'autres chaînes par défaut, pas parce que vos fonds ont bougé. Seed plus chemin de dérivation déterminent la clé ; les portefeuilles s'accordent sur le standard de la seed (BIP-39) mais divergent sur les conventions de chemin. Vos actifs restent aux adresses dérivées par le portefeuille d'origine — restaurer dans ce portefeuille, ou dans un qui balaie les chemins courants, les fait réapparaître.
Partager un xpub est-il dangereux ?
Cela ne peut pas vous faire perdre de fonds — une clé publique étendue ne dérive que des adresses, jamais des clés privées, et ne permet donc au mieux que des vues en lecture seule. Ce qu'il en coûte, c'est de la confidentialité : son détenteur peut énumérer chaque adresse de cette branche et relier vos activités. Traitez un xpub comme un relevé complet et vivant de ce compte, à ne partager qu'avec des services à qui vous confieriez cette information.