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 Sovereign 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 | Lets you recover your wallet by re-scanning instead of keeping a seed phrase. On its own it is indistinguishable from noise. |
| Your balance, and recent transactions | The ledger. Balances are permanent; the transaction log is pruned after a governed retention period. |
| Message metadata and undelivered messages | To deliver messages you are offline for. Retained for a governed period, then removed. |
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 an income, 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, your history, your messages. 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.
What websites you log into with SOV receive
When you use your SOV identity to sign in to another site, that site receives your Sovereign 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 the scrambling key will no longer sit in a constant — and any resolution of the erasure problem. Both will be reflected here when they ship, and not before.
SOV NETWORK