Know what is protected
Understand encryption, account authorization, and the current release boundaries.
Local vault encryption
Qozmo uses WebCrypto PBKDF2-SHA-256 with 600,000 iterations and a fresh salt, then AES-256-GCM with a fresh IV. Saved secret material is encrypted. The quantum vault also authenticates its identity, chain, genesis commitments, salt, and read-only policy.
Unlocking keeps secrets in JavaScript memory for the active session. JavaScript cannot guarantee erasure of every runtime copy. Encryption while locked does not protect against a compromised device or malicious code while unlocked.
Authorization belongs to an account
The everyday EVM account uses ECDSA. Qozmo Quantum uses WOTS authorization for its separate smart account. The optional SLH-DSA signature lab produces a separate local proof; it does not authorize either account or upgrade an ECDSA account.
Current release boundaries
| Capability | Status |
|---|---|
| Everyday mainnet balances | Available through configured RPCs |
| Everyday mainnet signing | Disabled |
| Everyday native testnet transfers | Implemented |
| Quantum ETH/ERC-20 signing | Robinhood Testnet only |
| Imported quantum spending | Blocked; read-only |
| Swaps, approvals, bridge and staking execution | Not enabled in the Qozmo UI |
| Independent audit / production certification | Not claimed |
Keep your recovery material private
- Record phrases offline and identify which account/network they belong to.
- Keep encrypted files and passwords separately.
- For Quantum, keep one original signing device and preserve its journal.
- Do not clear an unresolved signed operation just because its relay timed out.
- Use the selected chain’s explorer to inspect account or transaction details.