THE GUIDE.

Why use a vault?

Your everyday wallet handles payments and app connections. Vaultum gives the SOL you set aside a separate approval requirement: a vault signing key that you unlock for protected withdrawals.

This separates access to your wallet from permission to spend from your vault. Set the daily allowance to zero and every withdrawal needs your vault key under the current program’s rules. With phone mode, you also review and approve on a separate device.

Vaultum is an authorization layer for deposited SOL. To use it well, save the vault’s recovery phrase offline, review each request, and keep one active signing device per vault. Assets in your regular wallet continue to use that wallet’s security.

Why post-quantum signatures?

Post-quantum cryptography develops alternatives to public-key schemes that future quantum computers could break. NIST’s post-quantum standards describe this motivation.

Vaultum adds hash-based signatures to the protected withdrawal path. A one-time signing key approves each distinct action, and a Merkle tree lets the Solana program verify that key against the vault’s stored root. The technical reference explains Vaultum’s custom construction and its review status.

How protection works

Your vault is an account controlled by the Vaultum program on Solana. The program stores public verification data and checks withdrawal rules. The secret vault key is kept encrypted on your chosen signing device.

1. 01
   Review

   The dashboard prepares the amount and recipient.

2. 02
   Approve

   Your signing device displays the request and unlocks your vault key.

3. 03
   Verify

   The program verifies the signature before moving SOL.

A protected withdrawal binds the vault, recipient, amount, asset, one-time key, program, and network into its signature. Changing those fields invalidates the approval. The program also checks the next key number, available balance, and whether the vault is frozen.

Owner wallet

Pays transaction fees in this dashboard, deposits SOL, and spends any daily allowance. The protocol also lets it freeze the vault and change the deposit cap.

Vault signing key

Approves protected withdrawals. Changing the allowance, unfreezing, and rotating the key tree also require this key at the protocol level.

Daily allowance

An explicit exception: the owner wallet can spend this amount from the vault without a post-quantum signature, every UTC day.

The protocol does not require the original owner wallet’s signature for a protected withdrawal. However, this dashboard currently discovers and operates vaults through the signed-in owner. An owner-independent recovery interface is not available here yet.

Choose where you approve

A supported passkey or a strong passphrase encrypts the local key. Biometrics help unlock it; Face ID itself is not the post-quantum signature. The app briefly uses the decrypted key to sign, then clears its working seed.

The signing location is chosen during creation and recorded by the apps, not enforced as a physical-device rule on chain. This dashboard does not offer a mode switch. To change modes, create a new vault and transfer its balance.

Create your first vault

Create vaultDashboard preview

0102

1. Sign in and check the owner wallet. Use email, Google, a passkey, or an existing Solana wallet. If you have several wallets, select the intended owner. A vault’s owner address cannot be changed later.
2. Get test SOL. Use the dashboard’s devnet faucet link. The owner wallet needs SOL for account storage and transaction fees before it can create a vault. Only native SOL is supported in this release.
3. Choose phone or browser. In Create vault, select where you will approve protected actions. Phone mode pairs through a QR code; browser mode uses the key set up under Browser key in the dashboard.
4. Review the allowance and deposit cap. The creation form starts with a 0.1 SOL daily allowance. Set it to 0 if every withdrawal should need a post-quantum approval. The deposit cap limits deposits through Vaultum’s deposit instruction; it is not a withdrawal limit.
5. Create and back up your vault key on that device. In phone mode, scan the pairing QR and complete key setup on the phone. In browser mode, use Browser key in the dashboard. Protect the key with a supported passkey or a strong, unique passphrase. Save its 24-word Vaultum recovery phrase offline and complete the backup check. This is separate from your login and owner wallet; never paste an existing wallet’s phrase into Vaultum.
6. Confirm creation, then try a small test deposit and withdrawal. Check the network, vault address, and signing location. Keep the recovery phrase until you have verified the complete flow, and for as long as you use its vaults.

Phone setup requires the signer, relay, and RPC to be reachable from the phone. A computer’s localhost URL points to the phone itself when opened there. A real phone needs a reachable HTTPS signer and relay.

Treat pairing links as private. They contain the channel secret used to authenticate requests. They do not contain your recovery phrase, but sharing them gives someone access to that pairing channel.

Sending SOL & understanding fees

Review a sendDashboard preview

0102

1. Open Send. Select the vault, enter the amount, and paste the recipient’s full Solana address.
2. Review on the signing device. Check the full address, amount, vault, network, and key number for every request. The signer flags new recipients to help you spot a first-time transfer.
3. Unlock and approve. Phone mode sends the request to the paired signer. Browser mode asks for an unlock here. The signer checks fresh chain state and records the key use before producing a signature.
4. Wait for on-chain confirmation. The dashboard verifies the signature, uploads it, and submits the withdrawal. The final receipt and transaction link confirm when the transfer has completed.

Why are there several transactions?

The post-quantum signature is uploaded in chunks before the program verifies it. Your wallet may therefore approve several transactions. An external wallet still shows its own prompts; an embedded wallet may omit extra prompts for fee-only steps after the Vaultum review.

Network fees

Paid by the owner wallet in this dashboard, separately from the vault withdrawal. Fees for processed transactions are not returned just because a later step fails.

Vault storage reserve

A minimum balance stays in the vault account to store its data. The spendable balance excludes it. See Solana’s account documentation.

Temporary upload deposit

Locks SOL in a signature-upload account. It returns when that account closes after completion, or when an abandoned upload is reclaimed.

If a transfer is interrupted, use Resume or View receipt on the same vault and check its transaction before creating another send. Reclaiming an upload returns its storage deposit. Network fees remain separate, and confirmed withdrawals are final.

Choose your daily allowance

The allowance gives your owner wallet a spending limit per UTC day without unlocking the vault signer. You choose the balance between convenient wallet-only sends and vault-key approval. Both paths spend from the same vault balance.

The reset is at 00:00 UTC, not 24 hours after your last send. The limit applies to the total spent that day, not to each transfer. Unused allowance does not accumulate. Sends just before and after midnight can use two days’ limits in a short time.

Set the allowance to zero at creation for approval on every withdrawal. Increasing or decreasing it later requires a post-quantum signature. That setting is supported by the protocol, but its dashboard control has not shipped yet.

The allowance path uses your wallet’s ordinary signature. The landing-page counter shows total SOL in vaults, including amounts accessible through this allowance.

256 keys. 254 protected actions.

A vault uses a tree of one-time signing keys. Each key must only approve one distinct action. The device saves what it signed, and the program accepts only the next expected key.

1

Key 0 proves you control the key during setup.

254

Keys 1–254 approve withdrawals and other protected actions.

1

Key 255 is reserved for replacing the tree.

A confirmed protected action consumes a key. Deposits and wallet-only allowance sends do not. If an action was signed but never submitted, that device’s key is already committed to it: resume the exact action instead of asking that key to sign different details.

What rotation does

Rotation replaces the verification tree and restores 254 available approvals. The protocol requires authorization from the old tree and proof that you hold the new key. The last key remains available for rotation even when ordinary approvals are exhausted.

Dashboard availability: the remaining-key indicator is available; the rotation control is still in development. Plan your test use around the available approvals.

New trees derive from the same recovery phrase, so your backup also covers future rotations. For an exposed phrase, follow the recovery procedure for creating a vault with a new phrase.

Back up and restore your vault key

Your 24-word Vaultum phrase restores the signing keys for vaults created from it, including future rotations. Save it offline in a place you can access without the original device. Keep it private: it authorizes protected withdrawals, so it belongs in your backup, never in chat, email, screenshots, or a support request.

Restore a browser keyDashboard preview

0102

Replace your phone

Restore your phrase in the phone signer and re-pair the existing vault. Retire the old signer before approving from the replacement. If the old device was compromised, use the exposed-phrase procedure below.

Browser data cleared or a new computer

Use Browser key to restore the original phrase, then recover access to the existing browser vault. Sign in with the original owner wallet to find it in this dashboard. A login alone does not recreate locally stored vault keys.

Replace your local unlock method

If a passphrase is forgotten or a passkey is unavailable, restore with your Vaultum phrase and choose a new unlock method. Your login password and local unlock method are separate from the recovery phrase.

Respond to an exposed phrase

From a trusted device, promptly move the remaining balance to a new vault created with a new phrase. Anyone holding the old phrase can still sign until the funds are moved. Rotation under the same phrase does not revoke that access.

Device access and phrase both lost

There is no administrator reset for the post-quantum key. Protected funds may become permanently inaccessible. Any surviving wallet allowance does not restore that key.

Security model & release status

Vaultum’s protection comes from separate authorization, review of the exact request, and signature verification on chain. This section collects the assumptions, dependencies, and release details behind those protections.

Program and deployment

This release is for test SOL on devnet and localnet. It is unaudited, and the recorded program is upgradeable by an ordinary wallet. Program bugs or a malicious upgrade could bypass withdrawal rules and put vault funds at risk. Independent review and an immutable deployment are required milestones before real-value use.

Signing device and backup

The phone or browser signer, your recovery phrase, and the request you approve form the authorization boundary. A stolen phrase or compromised signer can authorize transfers. Browser mode also trusts dashboard scripts, dependencies, and extensions while the key is unlocked; phone mode separates that approval environment from the dashboard. A valid signature approves what you reviewed, including an incorrect recipient.

Allowance and protection scope

Wallet-only allowance sends use ordinary Solana signatures. A compromised owner wallet can spend a nonzero allowance each day until it is changed or the balance is moved. Hash-based authorization applies to the protected path; it does not make Solana’s consensus, the owner wallet, or the upgrade authority quantum secure. Vaultum does not provide yield or reverse confirmed transfers.

Solana and the RPC

Vaultum still depends on Solana’s consensus, ordinary transaction signatures, and network availability. The RPC supplies chain state. False state can prevent signing or commit a local one-time key to an unusable action even though it cannot change a correctly signed recipient or amount.

The relay and privacy

The relay carries authenticated phone requests and signatures. It does not receive the recovery seed or pairing secret, but it sees request details such as vaults, amounts, and recipients. It can delay or drop messages. Transactions are public on Solana; Vaultum is not a private-transfer system.

Current dashboard capabilities

The dashboard supports sign-in, phone/browser vault creation, deposits, protected sends, allowance sends, signer recovery, and resuming interrupted uploads.

Dashboard controls for freeze/unfreeze, allowance changes, deposit-cap changes, key rotation, emergency withdrawal, and full transaction history are still in development. The protocol supports the security operations. Its emergency withdrawal can unfreeze and withdraw atomically using two keys, preventing re-freezing between those actions.

Review milestones

Independent cryptographic review, an immutable deployment, and dedicated passkey validation on physical iOS and Android devices remain outstanding. The review scope includes key derivation, recovery coordination, and implementation assumptions. Automated test coverage is described in the technical reference.

Read the full threat model

When something does not complete

Technical reference & evidence

What the tests cover

The automated suites exercise vault creation, deposits, protected and allowance sends, signature validation, encrypted storage, and resuming interrupted transactions. Shared TypeScript and Rust vectors check protocol encoding. Browser tests use controlled accounts and mocked services; these checks are separate from an independent security audit.

Vaultum uses a custom stateful WOTS/Merkle construction with SHA-256, 256 leaves, and 2,404-byte signatures. It is not SLH-DSA and this project does not claim NIST certification or FIPS 205 compliance. FIPS 205 specifies a different, stateless hash-based signature algorithm.

Encrypted key storage uses AES-256-GCM. The encryption key comes from a supported WebAuthn PRF or a passphrase processed with scrypt. The 24-word phrase is the recovery root; the local unlock method is not a substitute for that backup.

Inspect the implementation

The implementation is available in the project workspace at the paths below. A public source repository is not linked in this preview.

• programs/vaultumOn-chain permissions, withdrawals, allowance, freeze, and rotation.
• crates/vaultum-pqRust signature verification used by the program.
• packages/pqKey derivation, signatures, and cross-language test vectors.
• packages/signer-coreEncrypted storage, recovery, and checks before signing.
• AUDIT_NOTES.mdKnown issues, assumptions, and review priorities.

pnpm install
pnpm build:packages

pnpm dev:relay
pnpm dev:signer
pnpm dev:web

Read alongside the Vaultum threat model, Solana network guide, and the source for the exact release you are evaluating.