Juneo wallets
2023 - 2025 · Lead developer of the web wallet frontend (the backend is a different team's). Built the Chrome extension alone.
The official web wallet and Chrome extension for Juneo: accounts, transfers, cross-chain transfers, wrap and unwrap, staking and delegation across the JVM, Platform and JUNE chains.
What I delivered
- The web wallet frontend: accounts, transfers, staking and delegation
- Cross-chain transfers, wrap and unwrap between the JVM, Platform and JUNE chains
- The Chrome extension wallet (Manifest V3), built alone, live on the Chrome Web Store
- A standard dApp provider (EIP-1193 / EIP-6963): dApps connect with no custom integration
- An encrypted vault: AES-256-GCM, key held in memory only, automatic lock
- A React Native / Expo rewrite of the mobile wallet with biometric unlock (not released)
In numbers
- wallets created (approximate)
- 4,000
- chains in one wallet: JVM, Platform and JUNE
- 3
- PBKDF2 iterations to derive the vault key
- 100,000
- of inactivity before the vault locks itself
- 30 min
- Chrome Web Store (opens in a new tab)
- Bridge and wallet extension video (opens in a new tab)
- Wallet video (opens in a new tab)
Context
Juneo needed a wallet people could actually run the chain with: staking, delegating, and moving assets across its own JVM, Platform and JUNE chains (what Juneo calls its X, P and C chains), wrapping and unwrapping between them along the way. That need showed up in three different places at once. A web wallet for universal, install-free access. A Chrome extension, the only format that injects into the browser and the standard dApps expect. And a mobile app, for the daily use and retention a desktop tab was never going to deliver.
The problem
Three wallet surfaces need to expose the same staking, delegation and cross-chain logic without three separate implementations drifting apart from each other. Each surface also answers a different constraint on its own: a web wallet cannot talk to a dApp running in another tab, and is a poor fit for a phone screen; only a browser extension can inject itself into a page and speak to a dApp directly; and neither a website nor an extension gives a mobile user the biometric unlock or push notifications a wallet checked every day actually needs.
Constraints
The extension had to behave like a standard EVM-style wallet to any dApp that expected one, which meant implementing the EIP-1193 and EIP-6963 provider conventions inside Chrome's Manifest V3 model, where the background script is a service worker rather than a persistent process. The web wallet frontend had to work against a backend built and owned by the explorer team, not by me. And a wallet extension holds private keys, so the vault protecting them could not depend on a password ever touching disk.
What I built, in detail
The web wallet frontend: accounts, transfers, cross-chain transfers, wrap and unwrap, staking and delegation, on top of a backend the explorer team owns. The Chrome extension (Manifest V3): a background service worker running the vault, account and signing services, a content script bridging the page to that background, and an inpage provider implementing EIP-1193 and EIP-6963 so any dApp can detect and connect to it exactly like it would any other EVM wallet. The vault encrypts wallet data with AES-256-GCM, derives its key with PBKDF2, keeps that key in memory only, and locks itself again after a period spent idle. Separately, a React Native and Expo rewrite of the mobile wallet, biometric unlock included, that reached feature completeness and was never released.
Decisions
- Three wallets, one job each
- A web wallet, a browser extension and a mobile app were never going to converge into one interface without compromising all three. Building three distinct products, each shaped by what its surface is actually good at, meant none of them had to be the worst version of the other two.
- Impact Two wallets live, the web wallet and the Chrome extension, and around 4,000 wallets created.
- A standard EIP-1193 / EIP-6963 provider in the extension
- Implementing the same provider interface as any other EVM wallet meant existing dApps could detect and connect to the Juneo extension without a custom integration on their side.
- Impact No integration work on the dApp side: it finds the Juneo extension the same way it finds any other EVM wallet.
- One SDK behind every surface
- The web wallet, the extension and the unreleased mobile rewrite all built their transactions and account logic on JuneoJS, so a fix to a staking or cross-chain edge case only had to be made once, and every surface picked it up.
- Impact A staking or cross-chain fix is written once, in JuneoJS, and reaches every wallet with a version bump.
- A vault key that is never written to disk
- The extension derives its vault key with PBKDF2 and keeps it in memory only, clearing it on auto-lock. A stolen or seized device still leaves the encrypted vault useless without the password: there is no key file to recover it from.
- Impact A stolen laptop only holds ciphertext, and every password guess costs 100,000 PBKDF2 iterations.
Result
The web wallet and the Chrome extension are the wallets people actually use to stake, delegate and move assets on Juneo. The mobile rewrite reached feature completeness, biometric unlock included, but was never shipped: the app live in the stores today comes from a different team's repository entirely.
Around 4,000 wallets created. Lead developer of the web wallet frontend; sole author of the Chrome extension.
Stack
- React
- TypeScript
- JuneoJS
- Manifest V3
- EIP-1193 / EIP-6963
- React Native / Expo
Credits
Web wallet backend: Juneo's explorer team. Wallet logic across all three surfaces runs on JuneoJS, the SDK Aleksander maintains for the ecosystem.