v1.38.0, shipped on 2026-04-23, lands a feature SSP users have been quietly waiting on for years: wallet recovery via SSP Key. When your browser environment shifts hard enough that the wallet can no longer unlock locally — a monitor swap, a resolution change, a major browser update — you can now approve recovery on the SSP Key mobile app and re-initialize the extension without restoring from your seed. The same release brings a polish pass for Enterprise FluxNode starts, refreshed translations, and a sweep of smaller fixes.
Recovery without the seed
The new flow is straightforward. When the extension detects that its local environment has drifted past the device-fingerprint tolerance window — the same check covered in Firefox support arrives for SSP Wallet (Beta) — it presents two options instead of one. The old option is still there: type your seed phrase and restore the wallet from scratch. The new option is the one most users will reach for first: open SSP Key on your phone, approve the recovery request, and the extension re-initializes on the spot.
What's traveling between the devices is not the seed. It's a recovery authorization signed by your SSP Key — the same multisig peer that already co-signs every transaction. The extension uses that authorization to rebuild its local state from the encrypted material it already holds, salted with the new environment fingerprint. The seed itself stays exactly where you left it last time: out of the room.
Why this is the natural shape
If you stand back, this is the shape 2-of-2 has always implied. A wallet that requires two devices to spend has, by construction, a second device that can authorize anything sensitive — including a re-initialization. The architecture introduced in Introducing SSP Wallet — true 2-of-2 multisig goes live gave us a co-signer for transactions; v1.38.0 just notices that the same co-signer is the right authority for recovery, too.
The alternative — forcing every browser hiccup into a seed-phrase restore — treated the seed as the only available second factor. That made the seed cheap. Cheap seeds get written down in worse places, get unlocked from password managers in worse contexts, get read aloud on phone calls. The point of cold storage is to keep that material rare. v1.38.0 keeps it rare.
When you'll use it
The trigger condition is the device-fingerprint-mismatch detection introduced in v1.17.0. In practice that means: you swap an external monitor and the resolution changes, you update macOS or Windows and the GPU profile changes, you bump the browser to a new major version and the JS engine reports a new identifier, you turn on hardware acceleration that you had off (or vice versa). Each of these used to be a recovery moment. Each is now a phone tap.
The flow also helps users who simply re-installed the extension on a clean profile or on a new laptop they want to pair with the same SSP Key. As long as the SSP Key is reachable, the seed stays in the drawer.
When you still need the seed
The seed is not gone — it's still the ultimate fallback, and it has to be. If you lose the SSP Key, or both devices are compromised at the same time, or you want to import the wallet into a different SSP installation on a host that has never been paired, the seed phrase remains the only path. v1.38.0 narrows the set of moments that demand the seed; it does not eliminate them. Keep your backup current.
Closing the loop
This is the 27th and last of the release-time articles in this program — the arc that began with v1.0.0 and 2-of-2 multisig. The architecture set there held through every release we have covered: through ETH and Schnorr, through WalletConnect, through Enterprise and 1-of-1 vault signing, and now through recovery itself. The second device was always going to do this work. It just took a few years to find the seam where it was needed most.