Security documentation

How UpdraftFi protects your data

This page explains which data uses user-controlled encryption, which data must remain available to automated systems, and what is stored locally in your browser.

DataKey controlAccess
Stored financial history
Your encryption keyYou only
Cross-device portfolio data
Your encryption keyYou only
Wallet addresses
UpdraftFi server keyAutomated system
Exchange credentials
UpdraftFi server keyAutomated system
Local portfolio cache
Not encryptedThis device
User-controlled encryption
Server-managed encryption
Local IndexedDB storage
Documented limitations

The privacy model

Different data. Different boundaries.

“Encrypted” is not a complete answer. What matters is who holds the key and why access exists.

Only you can unlock

Your stored financial records and backups

UpdraftFi cannot decrypt the encrypted copies it stores.

What is protected

Your portfolio and transaction history, manual assets, funds, ownership records, cash flows, projections, preferences, cloud backups, and data synced between your devices.

How your keys work

Your passphrase creates the encryption key in your browser. The key is not sent to UpdraftFi. A trusted device can use a non-exportable browser key to unlock your data without exposing that key.

Automated snapshots

Our servers fetch wallet and exchange balances and encrypt stored snapshots to your public key, so daily snapshots can run even when your device is off. Only you can decrypt the stored snapshots.

Encrypted for automation

Wallet addresses and exchange API keys

UpdraftFi can decrypt these limited records so scheduled updates work while you are offline.

What is accessible

The wallet addresses and read-only exchange API credentials you connect to UpdraftFi.

Why access is needed

Scheduled portfolio updates must send a wallet address or authenticate with an exchange while you are offline. That is not possible with user-only encryption.

How it is stored

These records are encrypted with server-managed keys rather than stored as plaintext. Keyed indices also let scheduled jobs find a wallet without decrypting every address in the database.

Stays on this device

The local copy in your browser

Protected by your device lock and browser profile, not by a separate UpdraftFi passphrase.

What is stored locally

Your browser keeps a working copy of portfolio data in IndexedDB so the app remains fast and responsive.

Why it is not encrypted

Encrypting the local working copy would require another unlock step whenever you return to the browser. Your device lock and browser sandbox are the primary protection instead.

Keys and recovery

A non-exportable browser key can unlock encrypted cloud data on a trusted device. Your passphrase or recovery code remains the recovery path on another device.

Defense in depth

One encrypted layer is not enough.

Each boundary reinforces the one beneath it. The most private records keep their user-controlled encryption even if another layer is exposed.

Foundation

Infrastructure encryption

Supabase and AWS encrypt physical database storage at rest.

Application

Application encryption

UpdraftFi adds authenticated encryption before sensitive values are stored.

Private core

User-controlled encryption

Your most sensitive history is sealed with keys only you can recover.

Infrastructureencrypted at rest
Applicationauthenticated ciphertext

User-controlled core

Your private financial history

UpdraftFi cannot decrypt

data/sealed

Authenticated payloads

Encrypted records bind their context so copied or modified ciphertext fails verification.

Private scheduling

HMAC indices locate encrypted wallets for scheduled jobs without exposing every address.

Versioned keys

Encrypted formats carry version metadata so algorithms and keys can rotate safely.

Verified cross-device sync

Portfolio data synced between your devices is end-to-end encrypted and paired with device authentication signatures.

Honest limitations

What this model does not protect against.

Good security documentation should describe the remaining risk, not hide it behind broad claims.

Database and server-key compromise

Wallet addresses and read-only API keys could be exposed and used to fetch balances again. The encrypted stored copies of financial history, backups, and device sync data remain protected by your keys.

Server access during fetching

Our servers process plaintext balances before encrypting snapshots. A compromised or modified server could capture or retain that data. Encryption of stored snapshots does not protect this processing step.

Unlocked device or browser access

Local portfolio data is stored in IndexedDB for performance. Your device lock and browser profile are the primary protection for this local copy.

Technical reference

Implementation details.

The concrete primitives behind each part of the privacy model.

Your stored financial records and backups

Argon2id key derivation with a per-account salt

X25519 with XChaCha20-Poly1305 response sealing

Zero-knowledge backup blobs with service-side reads denied

Wallet addresses and exchange API keys

AES-256-GCM application-layer encryption

User, chain, and format metadata bound to wallet ciphertext

Dedicated HMAC keys for wallet scheduling lookups

The local copy in your browser

Versioned IndexedDB records

Non-exportable WebCrypto device keys

Passphrase or recovery-code key recovery

Questions, answered

Security FAQ

Infrastructure encryption protects physical storage, while application-layer encryption means sensitive values are not stored as readable plaintext in the application database.

Balance snapshots, backups, and portfolio data synced between your devices retain an additional boundary: they are encrypted with your keys and remain unreadable even if the database is exposed. Limited metadata such as timestamps and record sizes can remain visible.

We cannot decrypt your stored balance snapshots, encrypted backups, or portfolio data synced between your devices.

Our servers can decrypt connected wallet addresses and read-only API keys, and process current balances when fetching updates. The limitations section explains what this means for server access during fetching.

A fully zero-knowledge wallet address would prevent scheduled snapshots while you are offline. Every refresh would require an active, unlocked browser session.

We chose application-layer encryption for operational wallet data and zero-knowledge encryption for private financial history. The boundary keeps automation useful without making your stored financial history readable to us.

Use the recovery code saved during setup. UpdraftFi cannot reset or bypass the encryption protecting zero-knowledge data.

That is the trade-off of having no backdoor: without your passphrase or recovery code, nobody—including UpdraftFi—can recover that encrypted history.

Local IndexedDB portfolio data is not encrypted. Encrypting it would require another unlock flow whenever you return to the browser.

Your device lock screen and browser sandbox protect the local copy. Encrypted cloud backups use your passphrase-derived key and follow a separate, zero-knowledge model.

Security contact

Questions or security concerns?

Ask about the security model or report a potential issue directly to the UpdraftFi team.

What UpdraftFi can and cannot decrypt

Why automation requires access to limited operational data

Which threats the model covers—and which it does not

The algorithms and key boundaries used in each flow