Privacy and control
by design.
A technical breakdown of Cryptween's local-first architecture: what stays on your device, what reaches our servers, and the threat model behind those decisions.
Threat model
Our architecture minimizes server-side exposure, but no server design can protect a compromised client device.
- -If your machine has malware, local secrets can be stolen before any network boundary applies.
- -Device hardening, OS updates, endpoint security, and key hygiene remain user responsibilities.
Key management
API keys are stored locally using Electron secure storage in beta. Later, keys will be encoded in a local SQLite database.
Keys are never transmitted over the network.
Data aggregation specification
The local tracker computes cross-exchange summaries first, then shares only the selected outputs.
- →When you choose to share: total portfolio values and cross-exchange summary metrics.
- →Optional: position-level details — you control what gets shared.
- →Shared records are wallet-linked for aggregation purposes and therefore not anonymous.
Server-side data
Cryptween servers store only what is required to produce collective metrics.
- User wallet identifiers
- Timestamps for submitted updates
- User-shared aggregate summaries and optional shared position values
- Derived collective aggregates generated from submitted data
What leaves your device vs what stays local
✓ Leaves device
- Cross-exchange total portfolio values
- Summary exposure metrics used for collective analytics
- Wallet-linked identity context
- Optional position value sharing (if user enables it)
✗ Stays local
- Exchange API keys and secret material
- Full raw exchange account payloads
- Unshared position-level data
- Device-local key storage artifacts
Verifiability roadmap
Open source by Q3 2026, so anyone can inspect exactly how exchange data is processed before sharing.
We also plan to introduce cryptographic proof mechanisms so users and auditors can verify that collective aggregates were computed from declared inputs.