Comment utiliser les adresses furtives sur Ethereum (EIP-5564)

En avril 2026, la mise à jour de feuille de route « Statelessness, Stealth, and Soul-Bound Tokens » publiée par Vitalik Buterin a remis l'EIP-5564 sous les projecteurs : près de 1,4 million d'adresses Ethereum apparaissent désormais dans au moins un cluster Chainalysis, et l'écart entre « pseudonyme » et « privé » n'a jamais paru aussi béant. L'EIP-5564 est la réponse d'Ethereum à ce fossé — une méthode standardisée pour recevoir des transferts d'ETH, d'ERC-20 ou d'ERC-721 sur une adresse à usage unique fraîchement dérivée, qu'un observateur extérieur ne peut relier ni à votre nom ENS public ni à votre portefeuille principal. L'idée est empruntée presque mot pour mot à Monero, où les adresses furtives sont activées par défaut depuis 2014, mais adaptée à l'univers d'Ethereum, basé sur les comptes et natif de l'EVM. Ce guide explique comment fonctionne le standard, comment l'utiliser avec les outils actuels, comment il se compare à l'implémentation mature de Monero, et où se trouvent les pièges évidents. Si vous souhaitez en fin de course convertir vos ETH privés en XMR pour des garanties plus solides, MoneroSwapper assure le pont sans KYC — mais commençons par comprendre ce que les adresses furtives vous apportent réellement sur Ethereum lui-même.

Pourquoi Ethereum avait besoin d'adresses furtives

Le récit par défaut d'Ethereum en matière de confidentialité a toujours été embarrassant. Chaque transaction relie publiquement un expéditeur, un destinataire et un montant à deux adresses pérennes, et les noms ENS rendent ces adresses lisibles en un clic sur Etherscan. Une fois que vous avez fait un don à une adresse publique, réglé un pourboire, reçu un airdrop ou accepté un salaire en stablecoins, l'adresse réceptrice est définitivement liée à votre historique on-chain. En France, cette transparence pose aussi un problème fiscal concret : depuis la généralisation du formulaire 2086 par la DGFiP, chaque cession imposable doit être documentée transaction par transaction, et un cluster Chainalysis mal renseigné peut transformer un audit de routine en redressement. Tornado Cash comblait une partie de ce vide jusqu'à ce que l'OFAC sanctionne le contrat intelligent en août 2022, et les condamnations de deux de ses développeurs en 2024 ont gelé la majeure partie de son usage légitime.

L'EIP-5564 prend un angle différent. Plutôt que de mutualiser les fonds dans un set d'anonymat partagé, il permet à l'expéditeur de dériver une nouvelle adresse réceptrice à usage unique que seul le véritable destinataire peut dépenser — sans coordination préalable, sans mixeur sous forme de smart contract, et sans jamais partager la clé privée principale du destinataire. Les propriétés offertes sont :

• Non-liabilité : les observateurs extérieurs ne peuvent pas déterminer que deux paiements furtifs appartiennent au même destinataire, même si la méta-adresse de ce dernier est publiée publiquement.
• Non-interactivité : l'expéditeur n'a besoin que de la méta-adresse publiée du destinataire — pas de poignée de main préalable, pas de clé symétrique partagée, pas de pont Tor.
• Accès en lecture seule : une clé de visualisation permet à des services externes (un hot wallet, un serveur watch-only, une appli mobile) de détecter les paiements entrants sans détenir le pouvoir de dépenser.
• Compatibilité ascendante : le standard fonctionne pour les transferts ETH, ERC-20, ERC-721 et ERC-1155 sans modifier le moindre contrat de token de part et d'autre de la chaîne.

La contrepartie est que l'EIP-5564 ne masque pas les montants des transactions, et il ne rompt pas le lien entre une sortie furtive et l'adresse finale où elle sera balayée. Ce n'est pas du RingCT. Mais pour un usage quotidien — payer un freelance, recevoir un drop de NFT, accepter un don, percevoir un salaire — il réduit drastiquement ce qu'un observateur extérieur peut corréler à votre identité publique.

Comment fonctionne réellement l'EIP-5564

L'EIP-5564 — rédigé par Toni Wahrstätter, Matt Solomon, Ben DiFrancesco et Gary Ghayrat, puis finalisé en tant qu'ERC Standards Track en mars 2024 — définit deux artefacts : un schéma canonique pour dériver les adresses furtives à partir d'une méta-adresse publiée par le destinataire, et un contrat singleton « Announcer » qui publie les clés publiques éphémères afin que les destinataires retrouvent leurs paiements sans avoir à scanner la chaîne entière.

La méta-adresse : deux clés, pas une

Chaque destinataire EIP-5564 publie une méta-adresse furtive de la forme st:eth:0x.... Elle encode deux clés publiques secp256k1 compressées concaténées :

• Clé publique de dépense (P) : dérivée d'une clé privée de dépense pérenne que le destinataire conserve hors ligne, idéalement sur un portefeuille matériel.
• Clé publique de visualisation (V) : dérivée d'une clé privée de visualisation que le destinataire peut confier à un logiciel watch-only sans exposer la capacité de dépense.

Cette séparation est exactement la même que la dissociation clé de Vue / clé de Dépense adoptée par Monero depuis CryptoNote en 2014. La clé de dépense signe les transferts sortants ; la clé de visualisation permet à un portefeuille de détecter les paiements entrants sans pouvoir les déplacer. C'est cette séparation qui autorise un Ledger ou un Trezor à conserver la clé de dépense pendant qu'un hot wallet sur votre ordinateur fait tourner le scanner en arrière-plan.

Dérivation d'une adresse à usage unique

Pour envoyer à une méta-adresse furtive, l'expéditeur exécute le protocole suivant côté client, sans aucune interaction on-chain jusqu'à l'étape finale :

1. Générer une clé privée éphémère aléatoire r et calculer sa clé publique R = r·G, où G est le générateur de secp256k1.
2. Calculer un secret partagé S = r·V via un ECDH standard contre la clé publique de visualisation du destinataire.
3. Hacher le secret partagé : s = keccak256(S).
4. Dériver la clé publique furtive P_stealth = P + s·G.
5. Prendre l'adresse Ethereum de P_stealth. C'est l'adresse réceptrice à usage unique.
6. Envoyer les fonds vers cette adresse et appeler le contrat Announcer avec la clé publique éphémère R, l'octet de view-tag et un identifiant de schéma.

Le destinataire — ou plus précisément un service de scan détenant la clé de visualisation — voit l'annonce, recalcule s = keccak256(v·R) (où v est la clé privée de visualisation), dérive le même P_stealth et retrouve les fonds garés à l'adresse Ethereum correspondante. Seul le détenteur de la clé privée de dépense peut ensuite signer une transaction depuis cette adresse : la clé privée de dépense propre à chaque sortie vaut p_stealth = p_spend + s.

L'optimisation par view-tag

Naïvement, chaque destinataire devrait dériver P_stealth pour chaque annonce sur la chaîne — des millions d'opérations par jour à grande échelle. L'EIP-5564 inclut un view-tag d'un seul octet dans chaque annonce : le premier octet de keccak256(S). Les scanners peuvent écarter 255 annonces sur 256 après une simple comparaison d'octet, si bien qu'un destinataire typique ne traite intégralement qu'environ 0,4 % des annonces. Cela place le coût de scan de l'EIP-5564 dans la même fourchette que le scan par clé de visualisation de Monero après l'ajout du view-tag optionnel dans Monero 0.18 en 2022. L'astuce elle-même a été documentée à l'origine par les chercheurs de Zcash en 2021 et est devenue depuis un schéma standard dans les conceptions d'adresses furtives.

EIP-5564 vs adresses furtives Monero

Comme les utilisateurs d'Ethereum demandent fréquemment si l'EIP-5564 rend Monero redondant, il vaut la peine d'aligner explicitement les deux conceptions. Elles partagent le même cœur mathématique mais diffèrent énormément quant à ce que le protocole global masque — et quant à savoir si la confidentialité est une option ou une garantie de base.

Propriété	EIP-5564 (Ethereum)	Monero (CryptoNote + RingCT)
Adresse réceptrice à usage unique	Oui (par paiement)	Oui (par sortie)
Anonymat de l'expéditeur	Non — l'adresse d'envoi est publique	Oui — masqué par signature en cercle CLSAG
Masquage des montants	Non — visible dans les logs de transfert	Oui — engagements de Pedersen + Bulletproofs
Usage par défaut	Optionnel par transaction	Obligatoire pour chaque sortie
Scan par clé de visualisation	Oui (viewing key EIP-5564)	Oui (clé de Vue Monero)
Confidentialité au niveau réseau	Aucune standardisée	Diffusion Dandelion++
Hard-forks futurs prévus	Aucun planifié	FCMP++ / Seraphis Jamtis (en cours)
Taille du set d'anonymat	Toutes les annonces EIP-5564 (~centaines/jour)	Ensemble du jeu d'UTXO (post-FCMP++)

En résumé : l'EIP-5564 masque qui est payé, tandis que Monero masque en plus qui paye et combien il paye. Si votre modèle de menace est « surveillance on-chain de routine » et que vous vivez déjà dans l'écosystème Ethereum, l'EIP-5564 est une amélioration significative du statu quo. Si votre modèle de menace inclut l'analyse de chaîne professionnelle avec clustering de graphe complet — ou si vous avez besoin de fongibilité côté réception — Monero reste structurellement plus solide, parce que chaque sortie est identique au niveau du protocole.

Pas à pas : recevoir et dépenser des paiements furtifs

Cette procédure suppose que vous utilisez Umbra (umbra.cash) ou le portefeuille Fluidkey, les deux implémentations EIP-5564 de qualité production sur le mainnet Ethereum à la mi-2026. Le flux est essentiellement identique sur Base, Optimism et Arbitrum, qui déploient toutes le même Announcer singleton à l'adresse canonique. Si vous testez le protocole, faites-le d'abord sur Sepolia — le gaz est gratuit et le même SDK fonctionne.

1. Générer votre méta-adresse furtive. Connectez un portefeuille qui détient votre clé de signature principale. Umbra et Fluidkey dérivent tous deux vos clés privées de dépense et de visualisation de manière déterministe à partir d'une signature sur un message fixe — vous n'avez donc jamais besoin d'une seed mnémonique séparée et pouvez retrouver l'accès depuis n'importe quel appareil qui détient votre clé principale.
2. Publier ou partager la méta-adresse. La chaîne en sortie ressemble à st:eth:0x03ab...c1de. Vous pouvez l'enregistrer face à votre nom ENS (le champ de resolver stealth-meta-address est standardisé dans l'ERC-5564 et supporté par le resolver ENS public) ou simplement partager la chaîne hors-canal via Signal, par e-mail ou sur une page de demande de paiement. Une fois publiée, n'importe qui peut vous payer sans coordination supplémentaire.
3. Recevoir un paiement. L'expéditeur dérive une adresse à usage unique côté client et poste une annonce au contrat Announcer. Votre portefeuille scanne les nouvelles annonces grosso modo à chaque bloc, les filtre par view-tag et fait remonter les dépôts correspondants dans son interface en ~12 secondes après confirmation sur le mainnet (ou ~2 secondes sur la plupart des L2).
4. Approvisionner le gaz à l'adresse furtive. Comme chaque sortie furtive se trouve à une adresse unique sans solde ETH préexistant, la dépense exige du gaz. Les portefeuilles gèrent cela de trois manières : une méta-transaction sponsorisée via Gelato ou Pimlico, un schéma « pull » où le destinataire brûle une petite fraction du montant entrant en guise de gaz, ou un relayeur que le portefeuille intègre nativement. Quoi que vous fassiez, n'approvisionnez jamais le gaz depuis un portefeuille doxxé — cela lie immédiatement la sortie à votre identité.
5. Dépenser ou balayer. Signez la dépense avec votre clé de dépense dérivée. Si vous balayez plusieurs sorties furtives vers une même adresse consolidée, vous les liez immédiatement entre elles : ne consolidez donc que lorsque cette liaison est acceptable. Sinon, routez via Railgun, vers une nouvelle adresse de dépôt CEX, ou — pour une fongibilité complète — convertissez en XMR via MoneroSwapper et recevez sur une nouvelle sous-adresse Monero.

Règle empirique : une sortie furtive n'est privée qu'à hauteur de l'adresse vers laquelle vous la balayez en fin de course. Traitez la destination du balayage comme la véritable décision de confidentialité, et non l'adresse furtive elle-même.

Portefeuilles et outils en 2026

Le paysage des implémentations EIP-5564 s'est consolidé au cours des dix-huit mois écoulés depuis la finalisation du standard. À la mi-2026, les options de qualité production sont :

• Umbra Protocol : l'implémentation de référence. Frontend open-source, déployé sur le mainnet Ethereum, Optimism, Arbitrum, Polygon PoS, Base et Gnosis Chain. Supporte ETH, n'importe quel ERC-20 et ERC-721. Maintenu par ScopeLift, audité par Trail of Bits en 2023.
• Fluidkey : portefeuille furtif orienté grand public, avec applis iOS et Android, une architecture à base de Safe et un sponsoring de méta-transactions intégré, pour que les destinataires n'aient jamais besoin de pré-approvisionner une adresse furtive en ETH pour le gaz. A levé un seed de 1,8 M$ en novembre 2024, plus de 40 M$ de paiements furtifs traités à fin 2025.
• Labyrinth : combine les adresses furtives EIP-5564 avec un mixeur Ethereum L2 pour masquer aussi montants et expéditeurs. Plus proche d'un stack de confidentialité complet, mais exige une confiance partielle dans l'opérateur du L2 et hérite de sa politique de censure.
• StealthSwap : un frontend façon Uniswap qui permet de swapper directement vers une adresse furtive de façon atomique. Utile pour récupérer le produit d'un trade DEX sans révéler votre portefeuille de destination au relayeur exécutant.
• Daimo Pay (mode Stealth) : le dernier entrant, ajouté en février 2026. Cible les paiements récurrents comme la paye et les abonnements, où la génération automatique d'adresses furtives est le vrai gain.

Pour les développeurs, le contrat Announcer canonique est déployé à 0x55649E01B5Df198D18D95b5cc5051630cfD45564 sur toutes les chaînes EVM qui miroitent l'espace d'adressage Ethereum — notez le suffixe « 5564 » délibéré, qui rappelle le numéro de l'EIP : un petit indice d'auditabilité bien utile. Le SDK de référence @scopelift/stealth-address-sdk gère le parsing des méta-adresses, la génération de clés éphémères, l'encodage des annonces et le filtrage par view-tag côté scanner. L'intégrer dans une dApp existante prend environ un après-midi à une équipe Solidity expérimentée.

Limites du modèle de menace à anticiper

L'EIP-5564 est une réelle amélioration, mais quelques catégories d'attaques subsistent. Aucune n'est un bug du standard — ce sont des conséquences du fait de faire tourner un upgrade de confidentialité par-dessus une base transparente, où le mempool, le bloc et les receipts restent globalement visibles.

• Exposition de l'expéditeur : l'adresse d'envoi reste publique. Si vous envoyez depuis votre adresse ENS principale, seul le destinataire est masqué, et un analyste de chaîne peut quand même construire un graphe du type « qui a payé des adresses furtives, quand et pour combien ».
• Corrélation par montant : un paiement furtif de 4,173 ETH immédiatement suivi d'un transfert de 4,173 ETH ailleurs suggère fortement un lien. Les chiffres ronds et les montants atypiques sont particulièrement fuyants.
• Corrélation temporelle : les annonces furtives sont publiques ; si vous scannez et balayez dans la même minute, les outils de surveillance peuvent restreindre votre annonce par simple corrélation de fenêtre temporelle.
• Métadonnées côté balayage : balayer vers Binance ou Coinbase relie la sortie furtive à une identité KYC chez le prestataire de conformité de l'exchange. Pour les utilisateurs français, l'enregistrement PSAN auprès de l'AMF impose à toute plateforme conforme au cadre MiCA de conserver ces données et de les transmettre à Tracfin sur réquisition. Balayez plutôt vers Railgun, un mixeur L2, ou convertissez en XMR si vous voulez réellement rompre la traçabilité.
• Fuite par approvisionnement du gaz : si vous approvisionnez le gaz d'une adresse furtive depuis un portefeuille doxxé, vous venez d'étiqueter la sortie pour tout observateur. Utilisez toujours un relayeur ou un balayage auto-financé.
• MEV cross-chain : certains relayeurs de pont enregistrent l'adresse furtive côté indexer. Traitez tout pont comme une surface potentielle de déanonymisation et préférez les routes d'atomic swap quand c'est possible.

FAQ

L'EIP-5564 rend-il mes transactions Ethereum totalement privées ?

Non. L'EIP-5564 masque le destinataire d'un paiement — plus précisément, il rompt le lien entre votre adresse publiée (ou nom ENS) et l'adresse qui reçoit effectivement les fonds. Il ne masque pas l'adresse de l'expéditeur, ni le montant transféré, ni l'horodatage. Pour une garantie de fongibilité complète où montants, expéditeurs et destinataires sont tous masqués par le protocole, il vous faut toujours une chaîne comme Monero, où chaque transaction utilise des signatures en cercle et des engagements de montant par défaut. Beaucoup d'utilisateurs traitent l'EIP-5564 comme un « premier saut » pour recevoir, puis convertissent en XMR pour le stockage et les dépenses ultérieures.

Dois-je partager mes clés privées avec un fournisseur de portefeuille pour utiliser les adresses furtives ?

Non, mais vous devez partager votre clé privée de visualisation avec le logiciel chargé de scanner les paiements entrants. La clé de visualisation ne donne que la capacité de détecter les paiements, pas celle de les dépenser. La clé privée de dépense — celle qui peut déplacer les fonds — peut rester sur un portefeuille matériel ou en cold storage. C'est la même architecture que Monero : un portefeuille watch-only sur un serveur toujours allumé avec la clé de vue, et un cold wallet pour signer les transactions avec la clé de dépense.

Pourquoi l'EIP-5564 est-il parfois appelé « la proposition furtive de Vitalik » ?

Parce que Vitalik Buterin a publié le brouillon original dans un billet de blog intitulé « An incomplete guide to stealth addresses » en janvier 2023, qui a lancé la standardisation formelle devenue l'EIP-5564. La cryptographie elle-même est bien plus ancienne — le whitepaper CryptoNote de Nicolas van Saberhagen a introduit les adresses à usage unique en 2013, et Monero les a livrées en 2014. Le billet de Vitalik mérite le crédit d'avoir popularisé la conception au sein d'Ethereum et de l'avoir rendue politiquement viable en tant que standard optionnel plutôt qu'un changement par hard-fork.

Puis-je utiliser les adresses furtives sur des Layer 2 comme Base ou Arbitrum ?

Oui. Le contrat Announcer canonique de l'EIP-5564 est déployé à la même adresse sur tous les grands L2 EVM, y compris Base, Optimism, Arbitrum One, Polygon PoS et Gnosis Chain. Umbra et Fluidkey supportent tous deux les paiements furtifs cross-rollup. Les frais sur les paiements furtifs L2 sont typiquement sous les 0,05 $ en 2026, ce qui rend les coûts de scan négligeables pour les utilisateurs finaux et supprime l'un des plus gros points de friction qu'avait le standard sur le mainnet en 2024.

Comment le coût de scan se compare-t-il à celui d'un portefeuille Monero ?

Globalement comparable, grâce à l'optimisation view-tag partagée. Un scanner EIP-5564 typique lit 1 octet de chaque annonce et ne calcule la dérivation complète sur courbe elliptique que pour les ~0,4 % qui passent le filtre de view-tag. Monero a ajouté la même astuce en 2022 ; les deux écosystèmes ont indépendamment emprunté l'idée à des recherches Zcash antérieures. Sur du matériel grand public, une année d'annonces furtives sur le mainnet Ethereum se scanne en quelques secondes, ce qui est plus rapide qu'une synchronisation initiale d'un nouveau portefeuille Monero.

Que se passe-t-il si je perds ma clé de visualisation mais conserve ma clé de dépense ?

Vous perdriez la capacité de trouver facilement vos paiements entrants, mais pas celle de les dépenser une fois trouvés. Vous pourriez forcer le scan par dérivation de chaque adresse furtive possible à partir de chaque annonce avec votre seule clé de dépense, ce qui est extrêmement coûteux mais faisable. En pratique, les deux clés sont dérivées de manière déterministe depuis la signature de votre portefeuille principal dans Umbra et Fluidkey : vous pouvez donc re-dériver la clé de visualisation à tout moment en reconnectant le portefeuille source.

Conclusion

L'EIP-5564 est l'upgrade de confidentialité le plus pragmatique qu'Ethereum ait livré depuis l'ère Tornado Cash — une vraie primitive cryptographique, pas une étiquette marketing, et une qui se calque proprement sur la séparation clé de Vue / clé de Dépense que Monero a prouvée à grande échelle une décennie plus tôt. Pour les paiements, dons, salaires et drops de NFT, il supprime le signal de surveillance le plus dommageable sur Ethereum : l'identité persistante de l'adresse réceptrice. Il ne masque toutefois ni les expéditeurs ni les montants, et dès que vous consolidez des sorties furtives vers une adresse transparente, vous restituez l'essentiel du gain de confidentialité que vous veniez d'obtenir. Le bon modèle mental est : « les adresses furtives sont une primitive de confidentialité, pas un produit de confidentialité ». Si votre objectif est la fongibilité complète — des sorties qui se ressemblent toutes au niveau du protocole, des montants qui ne sont pas visibles, des expéditeurs qui ne sont pas traçables — le flux le plus propre consiste à recevoir sur une adresse furtive, puis à router via MoneroSwapper pour une conversion ETH-vers-XMR sans KYC, livrée sur une nouvelle sous-adresse Monero. À partir de là, les signatures en cercle, les Bulletproofs et la diffusion Dandelion++ se chargent du reste, et votre empreinte on-chain s'arrête là où l'adresse furtive a pris fin.