Most privacy policies are written to be defensible rather than informative. They tell you data is processed for legitimate purposes, which is true of every system that has ever existed and tells you nothing.
Here is the concrete version: what is in the database, what is not, and what someone with a complete copy of it could do to you.
What is stored
- Your email address, from signing in
- Your handle, the human-readable name, which is public by design
- Your public receiving addresses for each chain, cached so the profile page can render without your device present
- Profile personalization: bio, avatar, chosen template and palette, badges
- Ownership records linking your account to the identities it controls
That is the inventory. Everything on that list is either something you typed in order to be found, or something that is public on a blockchain anyway.
What is not stored
Your wallet secret is not on that list, and its absence is structural rather than a policy we could change our minds about.
The mnemonic is generated in your browser from 32 bytes of operating-system randomness. It is encrypted there, with a key the browser refuses to let any page read back. The encrypted form stays in your browser's storage. There is no request that carries it to us, which means there is no configuration change that would start collecting it and no legal instrument that could compel us to produce it.
The recovery card is the same story from a different angle. It is encrypted on your device with a key derived from your PIN, and the PDF is generated in your browser. We never see the PIN, and we never see the card.
The breach scenario, concretely
Assume the worst case: someone has full read access to the production database. What can they do?
They can build a mapping from email addresses to handles to blockchain addresses. That is a real privacy harm and worth being clear about. It links an identity you may have kept separate from an on-chain history that is already public. If you are relying on the gap between your email and your addresses staying closed, a breach closes it.
They cannot move funds. Not slowly, not with more compute, not with a clever attack on the schema. The material required to sign a transaction is not in the database in any form, encrypted or otherwise. There is nothing there to attack.
The honest privacy caveat: nimimo is designed so a breach cannot cost you funds. It is not designed to make your addresses unlinkable from your account. If unlinkability is your threat model, a nimimo handle is the wrong tool. The entire point of a public profile is to be found.
Why the addresses are cached at all
There is a purist version of this design where the server stores nothing but a handle, and every lookup requires the owner's device to be online to derive an answer. It would be a worse product and no more secure.
Worse, because a payment page that only works when you are awake is not a payment page. The whole proposition is that someone can send to you at three in the morning while your phone is off.
No more secure, because a receiving address is public information. It is printed on the blockchain the first time anyone sends to it. Withholding it from our own database protects nothing; it only makes the product stop working.
So the addresses are cached, deliberately, as the public data they are. The line is not drawn at what is convenient. It is drawn at capability: anything that could move your funds stays on your device, and everything else is treated as the public record it already is.
How to check
Do not take this post's word for it. Open your browser's network tab, create an identity, and watch what leaves. You will see the handle and the addresses go out. You will not see the mnemonic, because it does not go.
The code that decides this is in nimimo-core and readable. A claim you can falsify in five minutes with tools already on your machine is worth more than a paragraph in a privacy policy, which is why we keep pointing at the network tab instead of the policy.