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

1

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.

2

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.

3

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

Each encrypted record includes Additional Authenticated Data (AAD) that binds context to prevent tampering or transplanting ciphertext.

Encrypted Queries

We can query encrypted wallet addresses without decrypting them using deterministic HMAC-SHA256 indices (per-user salted).

Key Versioning

All encrypted data includes version information for future key 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 and Exchange API Keys

Server-side encrypted for automatic fetching

What the system can access: Wallet addresses 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 even when you're offline, the system needs to decrypt your wallet addresses 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: Per-account salted HMAC indices allow scheduling without decrypting values 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 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 and Exchange API Keys

  • Encryption: AES-256-GCM with key version tags and per-record AAD for tamper detection.

  • Key custody: Server-managed secrets hold the encryption material with defined rotation procedures.

  • Deterministic lookups: A dedicated HMAC key (salted per account) powers scheduling without decrypting values.

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, .