How Solidus Wallet Handles Your Keys
The unlinkability implementation described here is unaudited.
Solidus Wallet is a non-custodial wallet by design, not by audit. That distinction matters more on this page than anywhere else on this site, so it comes first: keys are generated and used to sign entirely on your own device, and that boundary is never crossed, but "by design" is an architectural claim, a statement about how the software is built, not a claim that anyone outside Solidus has independently verified it. Everything below describes the architecture; none of it should be read as an audit result.
What crosses the boundary, and what never does
Picture a single line dividing your device from the network. Everything that matters to key custody happens on your side of that line.
A key generates and is used to sign entirely on the user's device. It is derived and held in the wallet's client-side code, following the standard HD wallet (BIP-32/44) derivation path from a seed phrase (BIP-39), infrastructure Solidus didn't invent and doesn't modify. When the wallet needs to prove something, authorize a transaction, respond to a login challenge, present a credential, it signs locally, using that key, without sending the key anywhere.
That boundary is never crossed, by design, not by audit. This is not a policy promise ("we choose not to see your key"): it is a statement about what the client-side code does and does not send over the wire. Solidus never holds your key, which also means Solidus cannot lose it, freeze it, or hand it to anyone else. There is no support desk that can reset it for you, either, more on that below.
Only the signed result, never the key, leaves the device. A login response, a transaction signature, a credential presentation: each is the output of signing, not the key that produced it. The network side, including Solidus's own infrastructure, only ever sees that output.
What this claim is, and isn't
This is an architectural invariant, stated in the product's own engineering documentation, not an independently audited one. The two are different strengths of fact, and it's worth being precise about why. An audited claim means an outside party read the source, tried to break the boundary, and published what they found. An architectural claim means the people who built it are telling you how it works. Both can be true. Only one of them has been checked by someone with no reason to be generous.
Right now, this is the second kind. The Solidus Wallet frontend is not in a public repository today, so a stranger cannot independently grep the source to confirm any of the description above. That's stated plainly rather than glossed over: there's no repo link to hand you, no "verify it yourself" line that would actually resolve to something checkable this week.
What does carry weight in the meantime is precision. The description above is specific enough to be falsifiable (it says exactly what crosses the boundary (a signed output) and what doesn't (the key itself)) so when an audit does happen, there's a concrete claim to check it against, not a vague assurance. That precision is the actual artifact this page offers. It is not a substitute for the audit.
The one public, runnable artifact for that specific claim, presentation, not key custody, which this demo doesn't touch, is:
npm i @solidus-network/auth @solidus-network/bbs
node node_modules/@solidus-network/auth/demo/unlinkability-demo.mjs
If you're thinking about recovery
Key handling and key recovery are adjacent questions, so it's worth naming the second one here without re-explaining it: what happens if you lose access to the device holding your key. Solidus Wallet supports guardian recovery. A k-of-n threshold of guardians you choose can co-sign a transaction that rotates your identity to a new key, enforced by the chain itself, not by a company or support desk. For the full mechanism, what a guardian actually is, how the threshold is enforced, what a completed recovery changes, see Social Recovery vs. Seed Phrases rather than a repeat of it here.
Where this stands today
For the full, up-to-date ledger of what's shipped versus what's still roadmap, see What's Live in Solidus Wallet Today. This page describes the architecture as it stands now; it will be updated, not quietly superseded, if that changes.