Envoyer et recevoir de l'Ethereum avec SSP

Faire entrer et sortir de l'ETH d'un portefeuille en autoconservation est l'une des premières choses que vous ferez après avoir configuré SSP pour Ethereum. C'est simple une fois que vous comprenez le modèle de compte et la façon dont le multisig 2 sur 2 de SSP s'insère dans une transaction Ethereum classique. Ce guide détaille la réception d'ETH, son envoi, et ce qui se passe réellement en coulisses quand vous signez avec deux appareils.

Si l'ETH dans SSP est tout nouveau pour vous, commencez par Ethereum dans SSP pour la vue d'ensemble, puis revenez ici pour le flux pratique d'envoi et de réception.

Un rappel rapide du modèle de compte

Sous le capot, Ethereum ne fonctionne pas comme Bitcoin. Sur Bitcoin, votre portefeuille jongle avec de nombreuses sorties non dépensées et génère de nouvelles adresses de monnaie rendue à chaque dépense. Sur Ethereum, votre compte est une adresse unique qui détient simplement un solde. Quand vous recevez de l'ETH, votre solde augmente. Quand vous envoyez, il diminue. Il n'y a ni adresses de monnaie rendue ni sélection de sorties à gérer.

Cela compte pour l'autoconservation de deux façons concrètes. D'abord, vous réutilisez la même adresse indéfiniment, il n'y a donc qu'une seule adresse à sauvegarder, vérifier et partager. Ensuite, chaque transaction doit être ordonnée, ce qu'Ethereum gère avec un compteur appelé nonce — nous y revenons plus bas.

Dans SSP, cette adresse unique est votre compte multisig 2 sur 2. Sur les chaînes EVM, c'est un compte à contrat intelligent ERC-4337, de sorte que les deux clés contrôlent toujours chaque dépense même si cela ressemble à une adresse normale sur la chaîne.

Recevoir de l'ETH

La réception est la moitié la plus sûre, car rien ne quitte votre portefeuille. Vous donnez votre adresse à l'expéditeur et attendez que le réseau confirme.

Votre adresse 0x

Votre adresse de réception Ethereum commence par 0x suivi de 40 caractères hexadécimaux. SSP l'affiche sous forme de texte et de code à scanner pour que l'expéditeur la copie exactement. Comme Ethereum réutilise une seule adresse, vous n'en avez pas besoin d'une nouvelle à chaque paiement.

Vérifiez l'adresse sur les deux appareils

L'autoconservation met la vérification de l'adresse entre vos mains. Un logiciel malveillant qui remplace une adresse copiée par celle d'un attaquant est un risque réel dans tout le secteur, alors confirmez que l'adresse que vous allez partager est bien la vôtre. SSP affiche le compte à la fois sur l'extension et sur SSP Key, alors regardez les premiers et derniers caractères sur chaque appareil et assurez-vous qu'ils correspondent. La même habitude s'applique lors de la réception de Bitcoin dans SSP : vérifiez sur du matériel que vous contrôlez, pas seulement sur une page web qu'on vous a envoyée.

Une seule adresse pour l'ETH et les tokens ERC-20

La même adresse 0x reçoit aussi bien l'ETH que les tokens ERC-20, car les tokens vivent dans des contrats qui créditent votre adresse. Vous n'avez pas besoin d'une adresse distincte par token. Ce dont vous avez besoin, c'est de vous assurer que l'expéditeur utilise le bon réseau.

Choisir le bon réseau

C'est la manière la plus courante de perdre des fonds sur les chaînes EVM. Une adresse qui existe sur le réseau principal d'Ethereum existe aussi sur Polygon, Base et d'autres chaînes EVM, mais un solde sur une chaîne n'est pas un solde sur une autre. Si quelqu'un envoie de l'ETH sur le mauvais réseau, il n'arrive pas sur celui que vous surveillez. Avant de partager votre adresse, convenez du réseau exact avec l'expéditeur et confirmez que SSP est réglé sur cette même chaîne. L'article 3 détaille comment utiliser SSP sur Polygon, Base et d'autres chaînes EVM.

Envoyer de l'ETH : le flux de co-signature 2 sur 2

C'est à l'envoi que la conception multisig de SSP se manifeste. Un portefeuille à clé unique signe une fois et diffuse. SSP exige vos deux clés, le flux comporte donc une étape d'approbation supplémentaire — et cette étape est tout l'intérêt du modèle de sécurité.

Voici la forme d'un envoi, présentée de manière générale car les libellés exacts peuvent changer :

1. Dans l'extension SSP Wallet, choisissez d'envoyer, saisissez l'adresse du destinataire et le montant, puis vérifiez les frais.
2. L'extension construit la transaction et applique la première signature avec la clé 1.
3. SSP Key sur votre téléphone reçoit une notification push. Vous y vérifiez les mêmes détails et co-signez avec la clé 2.
4. Les deux signatures combinées, la transaction est diffusée sur le réseau.

Comme aucun appareil seul ne peut déplacer des fonds, un attaquant qui ne compromet que votre navigateur ne peut toujours pas envoyer. Il lui faudrait aussi votre téléphone pour approuver. Sur les chaînes EVM, SSP combine les deux signatures en une seule via l'agrégation Schnorr, de sorte que ce qui arrive sur la chaîne est une unique opération d'abstraction de compte plutôt que deux signatures distinctes. La mécanique plus profonde est traitée dans le multisig EVM façon abstraction de compte.

L'habitude de co-signature est, dans l'esprit, identique à celle de l'envoi de Bitcoin avec SSP ; seul le format de transaction sous-jacent diffère.

Le cycle de vie de la transaction

Il est utile de se représenter un envoi comme une courte séquence :

• Construire — l'extension assemble la transaction : destinataire, montant, réglages de gas et le prochain nonce.
• Signer — la clé 1 signe dans l'extension.
• Co-signer — la clé 2 signe dans SSP Key après que vous avez approuvé la push.
• Soumise / en attente — la transaction combinée est diffusée et patiente dans le mempool en attendant d'être incluse dans un bloc.
• Confirmée — un validateur l'inclut dans un bloc. Chaque bloc suivant ajoute des confirmations et rend l'annulation plus difficile.

Une transaction n'est définitive qu'une fois confirmée sur la chaîne. Jusque-là elle est en attente et peut, dans certains cas, être remplacée. Vous pouvez suivre la progression de n'importe quelle transaction sur un explorateur de blocs public comme Etherscan en y collant le hash de la transaction.

Comprendre le nonce

Le nonce est un compteur par compte qui ordonne vos transactions. Votre première transaction utilise le nonce 0, la suivante le 1, et ainsi de suite. Le réseau les traite strictement dans l'ordre.

Cela a une conséquence pratique. Si une transaction reste en attente — généralement parce que son prix du gas était trop bas pour les conditions du moment — toute transaction ultérieure est bloquée derrière elle, car le réseau ne saute pas à un nonce supérieur. La solution consiste à remplacer la transaction bloquée : vous en renvoyez une avec le même nonce mais des frais plus élevés, ce qui permet aux validateurs de choisir la nouvelle version. Les portefeuilles présentent souvent cela comme une action « accélérer » ou « remplacer ». SSP exige toujours la co-signature 2 sur 2 pour un remplacement, car c'est une nouvelle transaction.

Vous touchez rarement le nonce à la main — SSP le renseigne — mais savoir qu'il existe explique pourquoi une transaction en attente peut bloquer celles qui la suivent.

Le gas, en bref

Toute transaction Ethereum coûte du gas, payé en ETH. C'est vrai même lorsque vous déplacez un token ERC-20 : le token voyage sur une transaction Ethereum, et cette transaction a besoin d'ETH pour le calcul. La règle pratique est de conserver un petit solde d'ETH pour couvrir le gas, faute de quoi un envoi peut échouer par manque de gas même si votre solde de tokens est suffisant.

La tarification du gas sous EIP-1559 se divise en des frais de base fixés par le réseau et un pourboire de priorité que vous ajoutez pour être inclus plus vite. Nous restons brefs ici ; pour la vue complète — frais de base, pourboires, pourquoi les frais s'envolent et comment les choisir en autoconservation — lisez les frais de gas sur Ethereum, expliqués aux utilisateurs en autoconservation.

L'ETH face aux tokens ERC-20

L'ETH est l'actif natif d'Ethereum et c'est lui qui paie le gas. Les tokens ERC-20 sont des actifs distincts définis par des contrats intelligents qui suivent les soldes rattachés à votre adresse. Envoyer un token est techniquement une interaction avec un contrat plutôt qu'un simple transfert de valeur, mais dans SSP cela suit le même flux : construire, signer, co-signer, diffuser.

Certaines actions sur les tokens exigent une approbation unique avant qu'un autre contrat puisse déplacer des tokens en votre nom — fréquent dans les swaps et la DeFi. Les approbations sont un sujet à part et hors de portée ici ; sachez simplement qu'une invite demandant d'approuver une dépense fait normalement partie des interactions avec les tokens, et la même co-signature 2 sur 2 la protège.

Précautions pratiques avant d'envoyer

• Bon réseau. Confirmez que la chaîne correspond à ce qu'attend le destinataire. De l'ETH sur Base n'est pas de l'ETH sur le réseau principal d'Ethereum.
• Format de l'adresse. Les adresses Ethereum sont 0x plus 40 caractères hexadécimaux. Collez, ne ressaisissez jamais, et vérifiez le début et la fin sur les deux appareils.
• Noms ENS. Certains portefeuilles permettent d'envoyer vers un nom lisible comme name.eth au lieu d'une adresse brute. Traitez-le comme n'importe quelle adresse : confirmez qu'il pointe vers le destinataire attendu avant d'approuver.
• Gardez de l'ETH pour le gas. Un solde uniquement en tokens ne peut pas payer son propre gas. Conservez un peu d'ETH.

Pour les détails au niveau du protocole sur la structure des transactions Ethereum, la documentation officielle des transactions Ethereum est une référence solide.

Pour conclure

Recevoir de l'ETH dans SSP, c'est partager votre adresse 0x vérifiée sur le bon réseau. Envoyer ajoute une étape délibérée — la co-signature SSP Key — qui transforme un point de défaillance unique en deux. Gardez un peu d'ETH sous la main pour le gas, surveillez le nonce quand une transaction cale et confirmez le réseau à chaque fois, et le mouvement quotidien d'ETH dans SSP devient une routine. À partir d'ici, l'article sur les frais de gas est la suite naturelle.