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
What we never hold
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.