Overview
Vault is a Solana wallet whose signing key lives inside a hardware enclave that refuses to produce a signature for anything you have not approved in advance. Between approvals it has no authority at all.
This is different from a wallet that warns you. A warning can be dismissed. An enclave that has not been given a matching policy simply cannot sign, and there is no interface through which it can be persuaded otherwise.
The one sentence version
You name an exact transaction, two of your credentials sign that permission, the enclave honours exactly that and nothing else, and the permission expires on its own.
Getting started
Setting up a vault takes about three minutes.
- 1Create your vault. A sub-organisation is created inside the enclave and a Solana wallet is generated in it. The private key is produced inside the enclave and never exists anywhere else.
- 2Register your three credentials: a passkey on your device, an email address for the second factor, and a recovery credential you store offline.
- 3We remove our own key from your root quorum. From this point we cannot authorise anything in your vault, and cannot add ourselves back.
- 4Deposit SOL to your vault address, then set up the destinations you move funds to regularly.
Step three is the one that matters and you can confirm it yourself at any time with the verifier, which prints your root quorum membership straight from the enclave.
Credentials and quorum
Your vault's root quorum holds three credentials and requires any two of them. All three are yours.
| Credential | Type | Notes |
|---|---|---|
| Device | Passkey | Bound by the browser to this domain. A lookalike site cannot invoke it. |
| Second factor | Email code | Sent by the enclave provider, not by us. Carries the destination and amount. |
| Recovery | Offline | Held by you. Turns losing a factor into an inconvenience rather than a loss. |
Two of three rather than two of two, because two of two means losing either factor locks you out of your own funds permanently.
Approvals
An approval is a narrow permission stored inside the enclave. There are two kinds.
Exact
One destination, one exact amount, pinned to a single Solana blockhash. Because a blockhash stops being valid after roughly 151 slots, the approval expires in about ninety seconds regardless of whether anything else happens. This is the default and the one you should use for anyone you do not already trust.
Window
A whitelisted destination, a per-transfer cap, and an expiry you choose from one hour to seven days. Windows exist for the addresses you top up constantly.
Windows are for your own addresses
A window stays open for hours, so the same transfer can occur more than once inside it. Repeated transfers to your own cold wallet are an inconvenience. That is why whitelisting requires you to confirm you control the destination, and why paying anyone else uses an exact approval.
Whitelisted destinations
A whitelist entry names an address you own, a per-transfer cap, and optionally an expiry. Adding one requires two credentials and takes effect after a 24-hour cooldown.
The cooldown is what makes the whitelist safe against a compromised session. An attacker who somehow gained control of your panel still could not add a destination and use it in the same sitting.
Fees
Vault charges 3% of the amount moved, taken inclusively. You name a total and the recipient receives that total minus the fee.
Both legs appear as separate transfer instructions and both are pinned in the policy the enclave holds. There is no way for an amount to leave your vault without appearing on the permission you signed, because the permission is a byte-exact description of the transaction.
Notifications
Every approval, signature, and refusal is delivered on two independent channels.
| Channel | Purpose |
|---|---|
| Carries the second-factor code along with the destination and exact amount, so you can check the panel against something outside it. | |
| Telegram | Runs on infrastructure unrelated to our mail provider, and reports back whether the message was delivered. A confirmation that goes quiet is itself a signal. |
Web push is available as a third channel for desktop. Link Telegram from your account page with a single tap.
The verifier
The verifier is an open-source single file you download and open yourself. It authenticates with a read-only credential generated in your browser, which we never see, and reads the enclave directly.
It reports four things:
- 1Which vault it authenticated against, so nobody can point you at a decoy.
- 2Your root credentials, because a rogue root credential would bypass every policy and make everything else meaningless.
- 3The raw policy conditions, returned verbatim, containing the destination, the exact amount, and the pinned blockhash.
- 4The pending transaction, decoded locally from raw bytes rather than described to you by us.
It is distributed on GitHub with a signed hash for each release, so a copy you already hold cannot be swapped.
Threat model
What Vault is built to stop, and how.
| Attack | Outcome |
|---|---|
| Phishing site requesting a signature | Nothing is signable. There is no standing authority to abuse. |
| Passkey invoked from a lookalike domain | Refused by the browser. WebAuthn credentials are origin-bound. |
| Bundled multi-transfer drain | No approval describes it. Implicit deny. |
| SetAuthority, Assign, or delegate grant | Outside every approval shape. Refused. |
| Durable nonce, non-expiring signature | Refused. Every approval is time-boxed by construction. |
| Address lookup table hiding a destination | Lookup tables are refused outright in every policy. |
| A single stolen credential | Insufficient. Two of three are required. |
Recovery
Losing one credential is recoverable. Present any two of your three and you can register a replacement for the third.
You can also export your wallet at any time and import it into any standard Solana wallet. Your funds are never dependent on Vault continuing to exist, and that is deliberate.
Store your recovery credential offline
A recovery credential kept in the same browser as your passkey is not a third factor. Put it on a hardware key or in a safe.