What we store, and what we can never touch

Your wallet set is a complete picture of your financial life on-chain. That is exactly why the product is built so that holding it gives us no power over it.

What we hold

Your email, and passkeys if you add them
Wallet addresses you declare — public information you choose to associate
CSV exports you upload — the transactions themselves, never a credential that could fetch more
The raw source data behind your computations, so recomputation never re-queries and your evidence never changes under you

What we never hold

Private keys or seed phrases — the product has no field to paste them into
Funds. We custody nothing and can initiate no transaction of any kind
Exchange API keys of any kind — this build does not accept them at all, so there is none to leak
Your addresses shared with any third party without your explicit consent
Deletion is deletionDeleting your account removes wallets, keys, raw data and computations, completing within 30 days. We offer a full export first.
DeterminismSame inputs, same outputs, byte for byte. Your figures cannot drift between runs, and every figure traces to source rows.

We do not take exchange API keys at all

Exchanges are handled by uploading their CSV export. You download your own transaction history and give us the file. There is no credential to store, nothing that could be used to fetch more than you handed over, and nothing to leak.

This was a deliberate cut. A read-only key still exposes a complete trading history, and holding one would be worth doing only if the key bought something the file does not. It does not: an imported row is pooled exactly as a fetched one is, because the same asset is the same Section 104 pool whatever route it arrived by. What a key would save is one download.

The instructions for getting the file out of each exchange are in the product, on the screen where you upload it — including the one thing that actually matters, which is asking for your full history rather than a single tax year. A year-filtered export leaves out the purchases that carry your cost basis, and that does not produce an error. It produces a gain that is too high.

Sign-in does not use your wallet

Email link or passkey. Never a wallet signature — it proves control of a key, not who you are, and it is the wrong instrument for a tax product.

The site and the product are separate origins

Marketing runs on one host and the product on another. The product host carries a strict content-security policy, runs no third-party scripts at all, and is closed to crawlers. A compromised vendor script on the marketing site cannot reach product session state, because it is a different origin with a different cookie jar.

How the encryption works, and what it is not

Nothing is encrypted here today, because there are no exchange credentials to encrypt. The machinery exists and is described anyway, so that the day anything is sealed the limits are already on the record rather than written afterwards to flatter.

What it does when it is used: a data key unique to your account, wrapped by a key the database never holds, sealed with AES-GCM— the standard, reviewed cipher, which replaced a hand-rolled construction. What is not right yet is the wrapping key. It is a file on the same server, not a managed key service, so anyone able to read that filesystem could unwrap whatever it protects. No hardware boundary, no audit trail of decrypt calls, no rotation.

We would rather say this than let “encrypted” do work it has not earned. It is also why this build takes no exchange API keys: the honest response to storage we would not stake a trading account on is not to hold the credential at all.

What we do not yet have

No third-party assurance report yet

We do not hold a SOC 2 Type II report or ISO/IEC 27001 certification. When we do, they will be named here with their scope and date. Until then this page is the whole of our security position, and we would rather state that plainly than imply otherwise.