How it works

Zero standing authority.

Most wallets are permanently able to sign anything and rely on you catching the bad request. Vault inverts that. Between approvals it can do nothing at all. An approval is a narrow, short-lived exception that you create and that dies on its own.

your credentials

Two of three, and we hold none of them.

Your vault is a sub-organisation inside a hardware enclave. Its root quorum contains three credentials, all yours, and any two are required to authorise anything. Our own key was removed from that quorum at setup and cannot be added back.

Device

Passkey

Touch ID, Windows Hello, or a hardware key. Bound by the browser to this domain, so a lookalike site cannot invoke it at all.

Second factor

Email code

Delivered by the enclave provider, not by us. The message carries the destination and amount so you can check this panel against something outside it.

Recovery

Offline

Stored by you, used by nobody. It exists so that losing one factor is an inconvenience rather than the end of your funds.

two kinds of permission

Exact, or a window.

Paying someone new is always exact. A window is for the handful of addresses you own and move funds between constantly.

EXACT~90 seconds

One destination, one exact amount, pinned to a single Solana blockhash. Because a blockhash stops being valid after roughly 151 slots, the approval expires whether or not our systems do anything at all.

what the enclave stores

solana.tx.recent_blockhash == 'EkSnNWid…KN1N' && solana.tx.transfers.count() == 2 && solana.tx.address_table_lookups.count() == 0 && solana.tx.transfers.all(t, t.amount == 12125000000 …)

A leaked approval is worth one destination, one exact number, and ninety seconds.

WINDOW1h · 12h · 24h · 7d

A destination you have already whitelisted, with a per-transfer cap and an expiry you choose. Useful when you are topping up a trading wallet or an exchange deposit address repeatedly.

the rule that makes this safe

A whitelisted destination must be an address you control.

Windows stay open for hours, so the same transfer can happen more than once inside one. Sending repeatedly to your own cold wallet is an inconvenience. Sending repeatedly to a stranger is not, which is why strangers get exact approvals.

Adding a new whitelist entry requires both credentials and a 24-hour cooldown before it can be used.

what never gets through

Deny by default is not a setting.

These are not rules we maintain on a blocklist. They are simply things that no approval has ever described, and anything an approval does not describe is refused.

Bundled multi-transfer
The classic one-signature drain
SystemProgram.assign
Reassigns ownership of your wallet
TokenProgram.setAuthority
Hands your token accounts away
TokenProgram.approve
Grants a delegate that drains later
advanceNonceAccount
Signature that never expires
closeAccount
When the destination is not you
Address lookup tables
Hides the real destination
Anything unlisted
Deny by default, with no exceptions

The fee is on the approval, because it has to be

Vault charges 3% of the amount you move, taken inclusively: you name a total, and the recipient receives that total minus the fee. Both legs appear as separate transfers in the transaction, and both are pinned in the policy the enclave holds.

That is not a disclosure choice. It is structural. The whole product is that you approve exact bytes, so there is no mechanism by which an amount could leave your vault without appearing on the permission you signed.