Les wallets Juneo
2023 - 2025 · Développeur principal du wallet web (le backend est celui d'une autre équipe). Extension Chrome construite seul.
Le wallet web officiel et l'extension Chrome de Juneo : comptes, transferts (y compris entre chaînes), wrap et unwrap, staking et délégation sur les chaînes JVM, Platform et JUNE.
Ce que j'ai livré
- Le frontend du wallet web : comptes, transferts, staking et délégation
- Les transferts entre les chaînes JVM, Platform et JUNE, wrap et unwrap compris
- L'extension Chrome (Manifest V3), construite seul, disponible sur le Chrome Web Store
- Un provider standard (EIP-1193 / EIP-6963) : les applications décentralisées (dApps) s'y connectent sans intégration spécifique
- Un coffre chiffré : AES-256-GCM, clé gardée en mémoire uniquement, verrouillage automatique
- Une réécriture mobile en React Native / Expo avec déverrouillage biométrique (jamais publiée)
En chiffres
- wallets créés, environ
- 4 000
- chaînes dans un même wallet : JVM, Platform et JUNE
- 3
- itérations PBKDF2 pour dériver la clé du coffre
- 100 000
- d'inactivité avant que le coffre se verrouille
- 30 min
- Chrome Web Store (s'ouvre dans un nouvel onglet)
- Vidéo du bridge et de l'extension wallet (s'ouvre dans un nouvel onglet)
- Vidéo du wallet (s'ouvre dans un nouvel onglet)
Contexte
Juneo avait besoin d'un wallet permettant vraiment d'utiliser la chaîne : staker, déléguer, et déplacer des actifs entre ses propres chaînes JVM, Platform et JUNE (ce que Juneo appelle ses chaînes X, P et C), avec le wrap et l'unwrap entre elles au passage. Ce besoin s'est présenté à trois endroits différents en même temps. Un wallet web, pour un accès universel sans installation. Une extension Chrome, le seul format qui s'injecte dans le navigateur et que les dApps attendent comme standard. Et une app mobile, pour l'usage quotidien et la rétention qu'un onglet de bureau n'apporte jamais.
Le problème
Trois surfaces de wallet doivent exposer la même logique de staking, de délégation et de cross-chain sans que trois implémentations séparées ne finissent par diverger. Chaque surface répond aussi à une contrainte propre : un wallet web ne peut pas parler à une dApp ouverte dans un autre onglet, et convient mal à un écran de téléphone ; seule une extension de navigateur peut s'injecter dans une page et s'adresser directement à une dApp ; et ni un site ni une extension ne donnent à un utilisateur mobile le déverrouillage biométrique ou les notifications push dont un wallet consulté tous les jours a réellement besoin.
Contraintes
L'extension devait se comporter comme un wallet EVM standard pour n'importe quelle dApp, ce qui impliquait d'implémenter les conventions de provider EIP-1193 et EIP-6963 dans le modèle Manifest V3 de Chrome, où le script d'arrière-plan est un service worker plutôt qu'un processus persistant. Le wallet web devait fonctionner avec un backend construit et détenu par l'équipe de l'explorer, pas par moi. Et une extension de wallet détient des clés privées : le coffre qui les protège ne pouvait pas dépendre d'un mot de passe qui touche un jour le disque.
Ce que j'ai construit, en détail
Le wallet web : comptes, transferts, transferts cross-chain, wrap et unwrap, staking et délégation, au-dessus d'un backend détenu par l'équipe de l'explorer. L'extension Chrome (Manifest V3) : un service worker d'arrière-plan qui fait tourner le coffre, les comptes et la signature, un content script qui fait le pont entre la page et cet arrière-plan, et un provider injecté implémentant EIP-1193 et EIP-6963 pour que n'importe quelle dApp puisse détecter et se connecter à l'extension exactement comme à n'importe quel autre wallet EVM. Le coffre chiffre les données du wallet en AES-256-GCM, dérive sa clé avec PBKDF2, garde cette clé en mémoire uniquement, et se reverrouille après une période d'inactivité. Séparément, une réécriture React Native et Expo du wallet mobile, déverrouillage biométrique inclus, qui a atteint la complétude fonctionnelle sans jamais être publiée.
Décisions
- Trois wallets, un rôle chacun
- Un wallet web, une extension de navigateur et une app mobile n'allaient jamais converger vers une seule interface sans faire de compromis sur les trois. Construire trois produits distincts, chacun façonné par ce que sa surface fait réellement bien, évitait que l'un ne devienne la pire version des deux autres.
- Impact Deux wallets en ligne, le wallet web et l'extension Chrome, et environ 4 000 wallets créés.
- Un provider standard EIP-1193 / EIP-6963 dans l'extension
- Implémenter la même interface de provider que n'importe quel autre wallet EVM a permis aux dApps existantes de détecter et de se connecter à l'extension Juneo sans intégration sur mesure de leur côté.
- Impact Aucun travail d'intégration côté dApp : elle détecte l'extension Juneo comme n'importe quel autre wallet EVM.
- Un seul SDK derrière chaque surface
- Le wallet web, l'extension et la réécriture mobile jamais publiée construisaient toutes leurs transactions et leur logique de comptes sur JuneoJS, donc corriger un cas particulier de staking ou de cross-chain ne se faisait qu'une seule fois, et chaque surface en héritait.
- Impact Un correctif de staking ou de cross-chain s'écrit une fois, dans JuneoJS, et arrive dans chaque wallet avec une simple mise à jour de version.
- Une clé de coffre jamais écrite sur disque
- L'extension dérive sa clé de coffre avec PBKDF2 et la garde en mémoire uniquement, effacée au verrouillage automatique. Un appareil volé ou saisi laisse le coffre chiffré inutilisable sans le mot de passe : il n'existe aucun fichier de clé à en récupérer.
- Impact Un ordinateur volé ne contient que des données chiffrées, et chaque mot de passe essayé coûte 100 000 itérations PBKDF2.
Résultat
Le wallet web et l'extension Chrome sont les wallets réellement utilisés pour staker, déléguer et déplacer des actifs sur Juneo. La réécriture mobile a atteint la complétude fonctionnelle, déverrouillage biométrique inclus, mais n'a jamais été publiée : l'application en ligne sur les stores aujourd'hui vient d'un tout autre dépôt, celui d'une autre équipe.
Environ 4 000 wallets créés. Développeur principal du wallet web, seul auteur de l'extension Chrome.
Stack
- React
- TypeScript
- JuneoJS
- Manifest V3
- EIP-1193 / EIP-6963
- React Native / Expo
Crédits
Backend du wallet web : l'équipe de l'explorer chez Juneo. La logique des trois surfaces tourne sur JuneoJS, le SDK maintenu par Aleksander pour l'écosystème.