What Vex can’t protect

Self-custody is a trade. In exchange for no custodian, no server-side signing and no cloud key storage, some failures land entirely on you, with no support line that can undo them. This page states those plainly, because a security model that only lists its strengths is not a security model.

For what is defended, and how, see the security model.

A lost master password

Your master password derives the key to the secret vault and the per-wallet keystores. It is held in memory only and is never written to disk, by anyone, anywhere. There is no reset, no recovery question and no escrowed copy.

Lose it and you lose the vault and the keystores with it. SECURITY.md puts this out of scope explicitly: it is not a vulnerability in Vex, it is the arrangement working as designed.

A deleted config directory

Backups stay encrypted wherever you copy them, which also means a copy is only as useful as the master password that opens it: keep the password somewhere separate, and an unusable password makes the backup unusable too. The exact per-OS paths are on Configuration, and the safe clean-slate order is on Troubleshooting.

Transactions you approved

The approval gate exists so nothing moves without you. Its flip side is that once you approve, the transaction is yours: a bad token, a rug, a drainer contract, a swap into something worthless. Vex screens what it can. TokenChecklooks for honeypots and fee-on-transfer tax before an EVM swap, the runtime blocks a confirmed honeypot at quote time, tokens are resolved through a read tool rather than a pasted address, and a destination address can only come from your own message or the session’s own wallets. But a user-approved malicious transaction is out of scope.

Granting full permission narrows the gate further: it bypasses the generic session approval gate, while per-tool policy and the Safety Contract still apply. Read Approvals & the Safety Contract before you use it, and prefer bounded missions with a capital ceiling for anything unattended.

Phishing and unofficial builds

A build you downloaded from somewhere other than an official channel is not the software this documentation describes, and nothing in the security model applies to it. Phishing, impersonation and software from unofficial sources are out of scope.

• Official channels are only projectvex.ai, @ProjectVEXai and GitHub Releases.
• The team will never DM you first.
• Nobody from Vex will ever ask for your seed phrase or master password. There is no support case in which that is a reasonable request.

Check what you downloaded before you run it. Verify a build covers per-OS signing and what to do on the platform that has none.

Reporting a vulnerability

If you have found something inside the scope on the security model, meaning key handling, approval gating, the Electron trust boundary, updater or release and signing integrity, or secret leakage, report it privately.

1. Email security@projectvex.ai

   Write to security@projectvex.ai with the issue and its impact, steps to reproduce, the affected version or commit and platform, and any suggested remediation. Do not open a public issue. If you need to share sensitive details, ask for the PGP key in your first message.

2. Expect an acknowledgement within 3 business days

   That is the target for a first reply and updates as the report is investigated, not for a fix. Please allow reasonable time to ship one before disclosing publicly.

3. Good-faith research has safe harbor

   Research that respects this policy, avoids privacy violations and data destruction, and does not degrade the service for others will not be met with legal action. Test against your own installation and your own funds, never against anyone else’s.