Zero-Knowledge Architecture
Your Financial Privacy, Protected by Design
Multiple layers of encryption keep your portfolio private without sacrificing the automation you expect.
Multiple Independent Layers
Layer 1: Infrastructure (Supabase/AWS)
All database storage is encrypted at rest by default via enterprise-grade Supabase/AWS infrastructure. Protects against physical disk theft and hardware disposal.
Layer 2: Application-Layer Encryption (UpdraftFi)
On top of infrastructure encryption, we add our own encryption using industry-standard algorithms (AES-256-GCM, XChaCha20-Poly1305). Data is not stored in plaintext in our application database.
Layer 3: Zero-Knowledge Encryption (User Keys)
Your most sensitive data (balance snapshots, backups) is encrypted with keys derived from your passphrase. These keys never touch our servers - we physically cannot decrypt this data.
Security Features
Authenticated Encryption
Wallet addresses, admin notes, snapshots, backups, and sync payloads bind context as authenticated data so tampering is detected.
Encrypted Queries
We can query encrypted wallet addresses without decrypting them using deterministic HMAC-SHA256 indices.
Key Versioning
Encrypted formats include version metadata where needed for future rotation and cryptographic agility.
Multi-Device Sync
Securely sync your data across devices using end-to-end encryption with device authentication signatures.
How We Protect Your Data
Backups and Sync Data
We physically cannot decrypt your most sensitive data
We physically cannot decrypt: Your exchange balance snapshots, encrypted cloud backups, and device sync data.
Keys derive from your passphrase or stay sealed to your device keys, so your secrets never touch our servers.
Passphrase flows run through Argon2id key derivation with per-account salts before encrypting payload keys.
In flows such as balance retrieval we encrypt responses to your public key and discard plaintext immediately.
Wallet Addresses, Provider History, and Exchange API Keys
Server-side encrypted for automatic fetching
What the system can access: Wallet addresses, shared on-chain provider history, and exchange API credentials are encrypted with server-side keys, meaning our automated system CAN decrypt them to fetch your portfolio automatically.
Why not zero-knowledge: To run daily auto-snapshots and avoid refetching public chain history even when you're offline, the system needs to decrypt operational provider data and call blockchain APIs on your behalf.
Security layer: Still protected with AES-256-GCM encryption. An attacker would need database access, encryption key access, and bespoke decryption code.
Query protection: Keyed HMAC indices allow scheduling without decrypting wallet addresses during lookups.
All Your Local Data
Performance-focused local storage
Local storage is not encrypted so you are not prompted for a passphrase every browser session.
Protection: Your device lock screen and browser sandboxing block other websites and remote attackers. For device loss scenarios, turn on encrypted cloud backups.
If you enable wrapped keys we cache a device-bound, non-extractable browser key to reduce passphrase prompts while preserving recovery with your passphrase or recovery code.
Frequently Asked Questions
What This Does Not Protect Against
Our encryption protects against database breaches, SQL injection, and unauthorized database access. It does not protect against:
Compromise of our infrastructure with database and encryption key access
This would expose crypto wallet addresses, shared public-chain provider history, and (read-only) API keys, but NOT your balance snapshots or backups - those remain zero-knowledge encrypted.
Physical or remote access to your unlocked device or browser profile
Local data is stored in browser IndexedDB (not as visible files) for performance. Someone would need to specifically know to look for IndexedDB data using browser DevTools - not something a casual user would stumble upon. Your device lock screen is your primary protection.
Implementation Deep Dive
Backups and Sync Data
Key derivation: Argon2id (t=3, m=64 MB, salt per account) feeding 256-bit encryption keys.
Transport: X25519 key exchange with XChaCha20-Poly1305 to seal responses before they leave our edge.
Backups: Zero-knowledge blobs in Supabase Storage with bucket policies that deny service-side reads.
Wallet Addresses, Provider History, and Exchange API Keys
Encryption: AES-256-GCM for wallet addresses, shared on-chain provider history, and exchange API credentials; wallet addresses are bound to user, chain, and format metadata.
Key custody: Server-managed secrets hold the encryption material needed for automated portfolio fetching and provider-history reuse.
Deterministic lookups: A dedicated HMAC key powers wallet scheduling without decrypting addresses.
All Your Local Data
Local persistence: IndexedDB stores structured snapshots alongside version metadata.
Device keys: WebCrypto non-exportable keys wrap encrypted payload keys for faster unlocks.
Recovery model: Passphrase or recovery code re-derives master keys without server assistance.
Trust Through Transparency
We believe in being honest about our security model rather than making exaggerated claims. This page provides complete technical disclosure of:
What we can and cannot decrypt
Why we made specific security trade-offs
What threats we protect against (and what we don't)
Technical implementation details
For questions about our security practices or to report security concerns, .