Wallets & custody

Vex is multi-wallet and dual-family: it holds both EVM and Solana keys, generated or imported on your machine, and it never sends a secret anywhere. There is no custodian and no server-side signing. The app decrypts and signs locally, in its own privileged process, after you approve.

Generating and importing

Wallets are step two of the first-run wizard. Each family (EVM and Solana) offers three actions: generate a fresh key, import one you already hold (hex for EVM; base58 or the JSON byte array for Solana), or restore from a backup archive. You can add more later, up to three wallets per family. See First run.

Which wallet a given session or mission spends from is a per-session choice, one per family, not a global one. See Agent sessions.

How keys are stored

Secrets live in encrypted keystore files inside your config directory, sealed with AES-256-GCM under a key derived from your master password with scrypt N=2¹⁷ (r=8, p=1), written atomically and, on Unix, with owner-only permissions. Wallet addresses, labels and ids, and only those, are kept in plaintext config.jsonas an inventory, so the app can show you what it has without unlocking anything. A keystore’s path is derived from its inventory id and never stored in config.

Your master password itself is never written to disk or into the process environment; it is held in memory by the privileged process while the vault is unlocked, and scrubbed when it relocks. The full cryptographic detail, including the vault envelope and unlock throttling, is in Keys & encryption, and the per-OS paths are in Configuration.

Backup, retention and restore

Vex snapshots the wallet surface into backups/ at the moments that matter: after a wallet is added, before a restore, when onboarding finalises, and on a vault reset. A snapshot captures the keystore files, the encrypted secret vault, config.json and a copy of the environment file with every managed secret stripped out. The key material inside stays encrypted under your master password, so a copied backup directory is not a copied key.

Retention keeps the twenty most recent ordinary snapshots and prunes the oldest beyond that; a snapshot taken immediately before a restore is protected from eviction, and vault-reset archives are kept outside the count. Restoring stages, verifies and then commits the archive, and takes its own snapshot of what you had first.

Exporting a private key

Self-custody means the key is genuinely yours, so Vex will hand it to you. Export is sudo-style: you re-type your master password even though the app is already unlocked, and the vault is verified before anything is decrypted. Wrong attempts back off further each time, and the fifth consecutive failure relocks the vault so you start again from scratch. The decrypted key is checked to derive the address on record before it goes anywhere; a key that fails that check never reaches your clipboard.

What you get is the key on your clipboard under an auto-clear lease: after ten seconds Vex clears it again, and only if the clipboard still holds exactly what it wrote, so it cannot wipe something you copied in the meantime. The secret is created and dropped inside the privileged process and never crosses into the interface.

Paste it where you meant to, promptly, and never into anything that asked you to.

Tracking tokens Vex doesn’t see

On Robinhood Chain, balance scans cover a pinned token set. Swaps and bridges pin their own tokens automatically, so a token that arrived by airdrop or plain transfer can be in your wallet and absent from the Book. Tell the agent to track it with WalletTrackToken, a local bookmark that sends no transaction, and it joins your balances from then on. This is expected behaviour, not a missing balance.

Wrapping and sending

Fund-moving wallet operations are two-step by construction. A prepare call signs nothing and spends nothing: it records one durable intent and hands back its id. A confirm call is the irreversible one, and in a restricted session it stops for your approval before it signs.

• Send. WalletSendPrepare then WalletSendConfirm, covering native coin, ERC-20 and ERC-721 on EVM chains and SOL plus SPL tokens on Solana. The intent expires ten minutes after it is prepared, is scoped to the session that raised it, and binds the wallet selected at that moment: if the selection changed, confirm refuses rather than sending from a different address, and the intent is consumed atomically so one prepared transfer can be broadcast at most once. Destinations may only come from your own message or the session’s own wallets.
• Wrap and unwrap. WalletWrapPrepare then WalletWrapConfirm, for moving between a native token and its wrapped form on a verified chain set (ethereum, optimism, bsc, polygon, robinhood, base, arbitrum and avalanche). The conversion is 1:1 with no route and no price, and Vex charges nothing on this path.
• Arbitrary transactions. The EVM and Solana transaction prepare/confirm pairs, for calls outside the built-in flows. Decoding is fail-closed: a prepare that cannot decode the calldata against the known set is refused by name before an intent exists. Fee caps are required arguments rather than something Vex derives from a network estimate, so calling without them refuses and hands back the current estimate as a hint.

Every one of these lands as an approval card carrying its action kind and risk level. See Approvals & the Safety Contract, and Fees for what Vex charges on which path.