Privacy on the SOV Network
Version 1.0 — 1 August 2026.
This describes what the network actually holds today, including the parts that are not yet where we want them. Where a protection is designed but not shipped, it says so. The technical detail behind every statement here is in the biometric explainer.
Who is responsible for your data
There is no company behind the SOV Network and no central server. The network is a set of independent nodes, each run by whoever chose to run it, all running the same software. Every node holds a copy of the network's state.
In data-protection terms that means there is no single controller to write to. Each node operator is an independent controller of the copy they hold. We are not going to dress that up: it is an honest description of a decentralised network, and it is also the reason some of the rights described below are harder to exercise here than against an ordinary company. If that matters to you, it should weigh in your decision to enrol.
What the network holds about you
| What | Why it exists |
|---|---|
Your SOV ID (e.g. SOV-XXXXXXXXXXXXXXXX) and public key | Your account. Everything else hangs off it. |
| A nickname derived from that ID | So people see a readable name. It is computed from the ID alone and carries nothing about your body, despite the legacy field name. |
| A protected palm template | The one-human-one-account check. Not a palm image — a list of numbers put through a scrambling transform. |
| A protected face template | The same check, across both hands: a palm template cannot tell that a person's left and right hands belong to one human, so the face captured during the liveness step is the cross-hand anchor. Also scrambled, never an image. |
| Helper data from enrolment | Used to check the palm scan at enrolment. On its own it is indistinguishable from noise. (Wallet recovery today is by your 12 words, backup file or guardians, not by re-scanning.) |
| Your balance, and recent transactions | The ledger. Balances are permanent; the transaction log is pruned after a governed retention period. |
| Message metadata (that a message passed between two IDs, and when — never its content) | Retained for a governed period, then removed. Undelivered messages wait on the sender’s device, never on a node. |
What is never collected at all: your name, address, phone number, email address, date of birth, or any government identifier. The network does not ask for them and has nowhere to put them. No palm photograph or face photograph is ever uploaded — the camera frame is turned into numbers on your own device and discarded there.
The biometric templates, stated precisely
This is the part that matters most, so it gets no euphemism.
The palm and face templates are biometric data used to identify a person. Under the UK GDPR that is special category data (Art.9), and under the EU GDPR the same. Calling them "just numbers" would be a dodge: they are numbers whose entire purpose is to recognise you.
They are stored in a protected form — each is put through a cosine-preserving cancelable transform, so what sits on disk is a scrambled vector rather than the raw measurement, and nothing on any node can be matched against a police, passport or phone-vendor database. Four limits belong next to that, because a protection you have overstated is worse than one you have explained:
- Every node holds a copy. The uniqueness check is network-wide, so the template set replicates to each node rather than living on one server. A node operator holds your protected template.
- The scrambling is reversible by whoever holds the key, and that key is a per-network secret that every approved node holds in full — not in the published source code, but not split across the network either. It defends against someone who steals a node's database; it does not defend against the operator of that node. Splitting it so no single operator holds it is planned work and is not shipped.
- Rotation is not implemented. The reason to use a cancelable transform is that a leak can be remedied by rotating the key and re-scrambling everyone. The design supports it; the code does not do it yet, so we do not offer it as a protection you currently have.
- There is no erasure path. See below — it is significant enough to have its own section.
How long it is kept, and the erasure problem
Balances are permanent by design. Transaction records and message metadata are pruned on a schedule the citizens themselves vote on.
The biometric templates are kept indefinitely, and today there is no mechanism to delete one. Not on request, and not by expiry. We would rather write that sentence plainly than let you discover it.
The reason is structural rather than careless. The template is the one-human-one-account guarantee: it exists to notice that someone enrolling now is someone who already enrolled before. Delete it and that person can enrol again, which is precisely the thing the network is built to prevent — and which, in a network where citizenship carries a vote and a welcome grant, is not a minor abuse. A right to erasure and a guarantee of uniqueness pull in opposite directions here, and we have not yet found the design that honours both.
That is an explanation, not a justification, and we are not claiming it discharges the obligation. It is recorded as an open problem. If you are deciding whether to enrol, decide knowing that the template you create is, for now, permanent.
Your rights, and how far they currently reach
- Access. Everything the network holds under your ID is visible to you in the app: your balance and recent transactions. Your messages were never held by the network. There is no hidden profile.
- Rectification. Nothing held is a factual assertion about you that could be wrong, other than ledger entries, which are corrected by transacting rather than by editing.
- Erasure. You can stop using an account and clear it from your own device. The biometric template cannot presently be erased from the network — see above. We are not going to describe a request path that does not work.
- Portability. Your keys and history are yours and leave with you; the wallet is recoverable on any device.
- Objection and withdrawal of consent. You can leave. Because there is no erasure path, leaving does not remove the template.
Exercising a right against a decentralised network is genuinely harder than against a company, and the route to do it is being worked out rather than settled. If you are reading this because you want to make a request, that is exactly the gap we are describing.
This website
This website counts visits with Cloudflare Web Analytics, so we can see whether anyone is reading it. It sets no cookies, does not keep your IP address, and does not follow you across other sites. What we see is totals: how many visits, which pages, which country, and which site linked here. Nothing on this website is connected to your SOV account, and the SOV app and network do not use it.
Questions to the developers. If you use "Ask the developers" or "Report a problem", we keep what you wrote, the contact you chose to leave (if any), the page you sent it from and your last few lines with the assistant, so a developer can answer. No IP address, cookie or device details are kept. Answers may be published on the Questions page without your contact details, and a message is deleted once it has been dealt with.
"Not installing today?" buttons. On the download page you can tap one reason for not installing. That sends one word (the reason) to the same counter as the download clicks, which keeps only a daily total per reason. No cookie, no IP address, nothing that identifies you.
Download clicks. When you click a download, checksum or torrent link on this website, the page sends one line to our own small counter: which file, and on which page. It keeps only a daily total for each file. No cookie, no IP address, no device details and nothing that could identify you is stored, and it has nothing to do with your SOV account.
The "Ask SOV" box. When you ask a question there, your question (and the last few lines of that chat) is sent to a Cloudflare AI service, which writes the answer from SOV Network's published documents. We do not store your questions or the answers, the box sets no cookies, and the conversation disappears when you leave the page. Please do not type personal information, your 12 words or your PIN into it; the assistant never needs them.
What websites you log into with SOV receive
When you use your SOV identity to sign in to another site, that site receives your SOV ID, your public key and signatures proving the ID is genuine, your ID-derived nickname, a one-way check value for the password you chose for that site, and a list of node addresses so it can reach the network. It receives no biometric data of any kind, and it cannot see your balance, your messages, or anything else you do on the network. It is told that you were verified, never how.
Those sites are separate operations with their own privacy policies, and what they do with your ID once they have it is between you and them.
Changes to this page
The honest version of this document changes when the software changes. The two things most likely to change it are the threshold-key work — after which no single node will hold the scrambling key in full — and any resolution of the erasure problem. Both will be reflected here when they ship, and not before.
SOV NETWORK