Privacy & trust

Trust model

Six questions, asked the way an adversary would ask them.

Question	Answer
Can Veilo move a user's funds?	No. Spending requires the user's secret, which we never hold.
Can a relayer steal or redirect?	No. Destination and amount are bound into the proof; a relayer can only submit or decline.
Can Veilo freeze a balance?	No. There is no administrative path over pool funds.
Does Veilo take custody?	No. Funds are held by the program, not by us.
Does Veilo know who users are?	We operate no identity verification and collect none.
What if Veilo disappears?	The program keeps running, and the user's secret remains sufficient to spend.

Why the answers hold

These are not policy commitments. They are consequences of the architecture, which is the only kind of commitment worth much. All on-chain logic runs inside a single program with no external dependencies and no upgradeable proxy. There is no privileged instruction to call, so there is nothing for an administrator, an attacker who compromises us, or a party who compels us, to use.

The test to apply to any such claim

Ask what would have to be true for the answer to become “yes”. Here it would take a different program, not a different policy, a different key holder, or a different company. See Architecture.

What we do hold

Being non-custodial is not the same as holding nothing. Veilo's servers hold encrypted notes indexed by wallet public key, and anonymised crash diagnostics. The notes are ciphertext we cannot read; the diagnostics are never linked to a wallet address. Both can be deleted on request. See Delete your account.

Data	Where it lives
Recovery phrase and private keys	Your device only, encrypted. Never transmitted.
Deposit secrets	Your device, plus an encrypted backup only you can decrypt.
Proof generation	Your device, or a dedicated service for constrained environments, which never receives your secrets.
Encrypted notes	Indexed off-chain so your client can find them. Only you hold the key that decrypts them.
Balances and performance	Computed on-device from your own notes. Never derived from a server-side balance.

Where trust does still sit

An honest trust model names its residual assumptions rather than claiming none:

You are trusting	For what	If it fails
The proof system and the program	Correctness of verification and spend protection	The core guarantees would not hold. This is the irreducible assumption of any ZK system.
The client you installed	That it generates proofs correctly and does not exfiltrate secrets	Verify you installed it from an official source. See best practices.
Relayer availability	That some relayer will submit for you	You wait, or use another. Funds are never at risk.
Your own device	Keeping your secrets secret	Every guarantee fails. This is the most likely real-world failure by a wide margin.

The weakest link is usually not the cryptography

In practice, privacy is lost to a reused address, a phishing signature, or a compromised device, not to a broken proof. Best practices is therefore not an appendix to this page; it is the operative part of it.

Compliance

Veilo operates no identity verification and collects none. Optional compliance features for regulated use cases are planned: optional, meaning a user or an integrator could choose to prove something about their own funds, not a capability that would let anyone else compel disclosure.