Threat model
Security boundaries and assumptions.
Experimental. Available on Mainnet. This describes the implementation; it is not an independent audit.
Sign-in and the owner wallet
Privy handles sign-in with email, Google, a passkey or an existing wallet. The owner wallet uses an ordinary Solana key. Privy does not provide the vault’s post-quantum protection; the separate signing key does.
The wallet can deposit, change the deposit cap, freeze the vault and spend the daily allowance. Allowance withdrawals are not quantum protected.
Protected withdrawals, changing the allowance and unfreezing require a post-quantum signature from the chosen signing device. A freeze blocks all withdrawals, including the allowance, but cannot reverse completed transactions.
Dashboard and phone
The phone rebuilds each request and checks the vault on chain. Withdrawal signatures bind the vault, amount, recipient, key, program and network.
Losing access to the owner wallet does not lock vault funds: the post-quantum key can authorize a protected withdrawal without the owner’s signature.
A malicious dashboard can request a harmful approval. Check the full address and amount on your phone. A compromised phone or signer is outside this protection.
This browser (same-device mode)
The browser stores the key encrypted under a supported passkey or passphrase. Every signature requires a fresh unlock; the seed is wiped immediately afterward.
This protects against quantum attackers and stolen wallets. It does not protect against malware on this computer, a malicious extension or a compromised dashboard, which can alter the approval view or access the unlocked key.
Privy’s SDK runs in the dashboard’s origin alongside the browser signing code. A compromised dependency, including this SDK, could capture the seed at the next unlock. Pinned dependencies, a nonce-based script policy and per-action unlocks reduce risk; they cannot make a compromised dashboard safe.
The signing location is chosen at creation. To move, create a new vault and transfer the funds. When recovering, keep only one device signing: two devices could reuse a one-time key for different actions.
Emergency withdrawal
An attacker with the owner wallet can keep freezing a vault. The protocol supports unfreezing and withdrawing in one transaction so no re-freeze can land between them. This consumes two consecutive one-time keys.
Relay
A shared pairing secret authenticates requests and responses. The relay sees request details and public signatures, but receives neither the secret nor the recovery seed. Requests expire after five minutes.
The relay can delay or withhold messages, but cannot forge a signature. Relay or RPC outages can prevent signing.
One-time keys
The signing device records key use before signing. The program accepts only the next expected key. A used key cannot approve a different on-chain request.
Security depends on SHA-256, correct implementation, secure key storage and accurate chain state. Protecting the signing key does not make Solana itself quantum secure.
Recovery
A supported passkey or passphrase encrypts the seed. Anyone with the recovery phrase can derive the keys. Keep it private and offline.
If a phrase is stolen, move funds to a new vault under a new recovery phrase immediately. The stolen phrase derives future rotation keys too. Rotation does not help.
If a phone is lost while locked, freeze from the owner wallet and restore on a new phone. If it may have been unlocked, treat the phrase as exposed. Short passphrases remain vulnerable to offline guessing if encrypted storage is stolen.
Losing both signer access and the phrase leaves no key-reset path. Rotation uses the same seed; it does not fix a leaked phrase.
Program and network
A malicious RPC cannot change the signed recipient or amount, but false chain state can waste one-time keys and prevent signing. Use a trusted RPC.
The program is unaudited and upgradeable by an ordinary wallet. A compromised upgrade authority could replace it and take every vault. Before real-value use, an independent audit and an immutable deployment are required. Protecting the vault key does not protect Solana’s validators or other accounts from quantum attacks.
The public counter reports RPC balances above rent. It includes wallet-only allowances, so not every displayed lamport requires a post-quantum signature.