SOV Network: one human, one account, on a network its users run

Version 1.2 — October 2026, node 1.4.99, app 1.2.35

1. The problem

Most online systems cannot tell whether two accounts belong to one person. That gap explains much of what goes wrong: bot networks that simulate public opinion, sock-puppet accounts that outvote real users, scammers who are banned and return under a new name, and "one person, one vote" systems that are in practice "one email address, one vote".

The usual remedies create a second problem. Proving uniqueness normally means handing a passport, a phone number or a selfie to a company that then holds a central database of real identities. Payments add a third: most digital money moves through intermediaries that see every transaction and can freeze an account. And platforms can remove a user or a whole community with one decision.

SOV Network's approach: a person proves uniqueness once, with biometrics captured on their own phone; their identity is a key they hold; their money, messages and votes are handled by nodes that anyone can run and that check each other's work. How far each of those checks reaches in the current release is the subject of the rest of this paper.

2. Threat model

Four adversaries, and what each can and cannot do against the current release (node 1.4.99, app 1.2.35). The network today has a small set of operators who run its three servers, and in the places listed below the protocol relies on those servers being honest. Removing each of those dependencies is the open work in section 10.

2.1 A dishonest citizen

• Cannot spend another citizen's SOV: every node verifies a spend against the signing key recorded at enrolment. Cannot spend the same SOV twice: each spend needs a majority-granted slot (section 4). Cannot create SOV: every operation must conserve value and the total is capped.
• Cannot enrol twice with the same palm or face: nodes refuse a template that matches an enrolled one (palm cosine ≥ 0.92, face ≥ 0.70).
• Can, with a modified app, submit templates that did not come from a live capture. The liveness challenge runs in the app; a node checks only that submitted templates are well formed and match no one enrolled. It cannot prove they came from a living person. This is open.
• A jury is drawn at random from all enrolled citizens, so capturing one requires controlling many enrolled identities. The defence against that is the enrolment check above, not anything in the justice system itself.

2.2 A dishonest node operator

Two kinds of node matter here. The network's servers are three nodes whose identity keys are built into every node and every app (a fixed trusted list, section 6.2). Any other node — a citizen's desktop node, or anyone running the published source — is admitted, serves citizens and relays what they sign, but is not trusted with anything a citizen did not sign.

• Cannot read message content (it is end-to-end encrypted), forge a citizen's signature, or get a non-conserving operation accepted by honest nodes.
• Can reverse the transform on the biometric templates its node holds. Every full node holds the network transform secret and a copy of every enrolled citizen's palm and face templates. What it gets is numeric feature vectors — 128 numbers per palm and 192 per face — not photos. They are encrypted at rest, so a stolen database file alone yields nothing usable; the running node and its operator hold the key. Splitting the secret so that no single node holds it is open.
• An operator outside the server list cannot get any other node to accept state no citizen signed — replicated records, a system money operation, or a vote on a payment slot. It cannot invent or alter a vote, a petition or a juror's vote (each carries the citizen's signed request, checked by every node), and cannot change a governance parameter: a node takes a parameter from its peers only when a majority of the servers report the same legal value.
• A server operator can misdirect funds in operations a single server decides, which the other nodes apply on its word, checking only conservation, balances and the supply cap: escrow release and refund on orders it hosts, enrolment grants and operator payouts from the pools, and vault claims. Jury verdicts are not in that list: every node re-checks a verdict from the plaintiff's signed filing and each juror's signed vote (section 8.2).
• Can see the delivery records and connection times of citizens who connect to it, and can run different code from the source it declares (section 6.4).

2.3 A network attacker

• Passive observer: sees which addresses connect to which nodes and how much they send. Phone to node traffic is TLS; node to node traffic is sealed per link; message content is end-to-end encrypted on top.
• Active attacker between a phone and a node: nodes use self-signed certificates, so the app does not rely on certificate authorities. Instead each server's first message carries a statement signed with its identity key naming the certificate it serves, and the app sends nothing — no greeting, no request, no enrolment data — until that statement verifies, names the certificate this connection actually received, and comes from one of the built-in server keys. An attacker in between must present his own certificate, so he is refused. He can still block or delay traffic. A citizen who pins their own node is exempt from the built-in list (section 6.2).
• Between nodes: a node proves its identity key in every greeting, so an attacker cannot pose as an existing node.

2.4 A compromised phone

• Whoever holds the unlocked device, or the signing key, can act as the citizen: spend, vote and message. Optional per-transaction and daily caps bind every spend at every node. An optional Spend-Lock encrypts the key under a PIN, and on Windows an optional Hardware-Lock seals it in the TPM.
• Guardians (section 3.4) can move the account to a new key. Spends already made are not reversed.

3. One human, one account

3.1 Enrolment

The phone's camera captures the palm, and a bundled detector runs a live face check with a random movement challenge. On the device each capture is reduced to a feature vector: 128 numbers for the palm, 192 for the face. Photos are not stored and are not sent; only the vectors travel, over TLS, to the node the app is connected to. Joining needs no phone number and no email address.

The node refuses an enrolment that lacks either vector. The face is mandatory because palm matching cannot link one person's left palm to their right palm. If any part of the duplicate check cannot run, the node refuses.

3.2 Protected templates and the duplicate check

Before storing, the node transforms each vector with a secret orthogonal matrix (stored = R · normalise(embedding)). An orthogonal transform preserves cosine similarity, so two scans of the same palm still match. The matrix is derived from a network secret that each node receives when it is admitted. Templates are stored and replicated only in this form, in a database that is AES-256 encrypted at rest.

Every new template is compared with every enrolled one. A palm at cosine ≥ 0.92 or a face at ≥ 0.70 is a duplicate, and the enrolment is refused. Templates travel with the enrolment broadcast; in the 3 October 2026 live test a second node checked a palm enrolled ten seconds earlier through another node. Nodes short of disk run as "light" nodes: they hold no templates and ask three full nodes to run the check, accepting the answer only with two agreeing signed replies and no dissent.

3.3 Keys

The app generates a 128-bit random master key, shown once as a standard 12-word recovery phrase. The Ed25519 signing key is derived from it, and so is the Sovereign ID (SOV- plus 16 hexadecimal characters of the SHA-256 of the master key). The 12 words alone restore the wallet. A session for an enrolled Sovereign ID must be signed with the enrolled key; a re-enrolment that presents a different key is refused.

3.4 Guardians

A citizen can appoint up to 5 guardians, each appointment signed by the citizen. To move the account to a new key, guardians sign approvals naming the old and new key; a node re-keys only after it has itself verified at least 2 distinct approvals within a 72-hour window.

4. The ledger

4.1 Not a blockchain

There is no mining, no block production and no global chain. Each node holds a full ledger. Agreement is reached per operation. Spends from an account are ordered by that account's own counter, so no global order of all transactions is needed. The closest published relatives are consensus-less payment protocols such as FastPay and the owned-object fast path in Sui.

4.2 Supply

The supply is fixed at 50,000,000 SOV (1 SOV = 1,000,000 seeds, the unit all arithmetic uses):

The old issuance mechanism was retired in node 1.4.89, and a credit that would push the total above the cap is refused.

4.3 Every balance change is an operation

An operation lists wallet, holding (escrow, vault, bond) and pool deltas. Before any node applies it, the deltas must sum to exactly zero; otherwise it is refused. Each operation has a unique id and is applied atomically and at most once, never partially. Operations are kept permanently; a node that missed some pulls them from peers through a digest exchanged every 60 seconds and on every new link. State synchronisation between nodes never writes a balance.

4.4 Owner operations: the (account, nonce) slot

A spend of a citizen's own funds — transfer, exchange listing, vault lock, bond, platform fee — must use the account's next nonce. The node that received it asks the voting nodes to grant the slot (account, nonce) to this exact operation:

• A node grants a slot to at most one operation; a different operation for the same slot is refused.
• The operation commits only with signed grants from a majority of the voting set (floor(N/2) + 1). A vote not received within 3 seconds counts as no.
• The grants travel with the operation as a certificate, and each receiving node re-checks it before applying. A reply counts only for the node on whose authenticated link it arrived.
• When two or more operators are known, the majority must also be a majority of operators, so one person's several nodes carry one weight.

4.5 Who counts as a voting node

There is no global membership list. Each node keeps its own record of voting validators: every voting peer on the server list that has passed its greeting checks (section 6), with the time it was first and last admitted. A node not on the list never counts, whatever role it declares. Its voting set for an operation is itself (if voting), every validator it admitted within the last 14 days, and every live voting peer. Serving nodes are never recorded, so they are never in N.

A receiving node rejects a certificate whose set leaves out any validator the receiver knew to be active at the commit time, or leaves out the receiver itself. So an origin cannot shrink the set to reach a cheaper majority. Identifiers the receiver does not know count for nothing, so padding the set does not help either. A node that once had peers and now sees none refuses to commit spends.

In a partition, a side that cannot reach a majority of the validators it has seen in 14 days cannot commit spends; payments there pause with QUORUM_UNAVAILABLE. Nodes can disagree about N when their views of recent validators differ, for example when a validator was admitted by some nodes and not yet by others. Safety then rests on those views overlapping, not on an agreed set. A formal per-epoch validator set is the planned replacement.

4.6 The citizen's signature, checked by every node

Every wallet request is signed with the citizen's Ed25519 key. For transfers, and since node 1.4.95 for every other owner operation, the signed request travels inside the operation. Each node, before granting and again before applying, checks that:

• the signature verifies under the enrolled key, and the signer is the account debited;
• the request is the right kind of operation, the debit is exactly what was signed (or the governance value for fees and bonds), and the reference is the one named;
• the request was signed within the last 5 minutes.

The operation id is derived from the signature, so one request can move money at most once. Optional automation caps (per transaction, daily, recipient allowlist) are enforced by every node before granting.

4.7 Invariant and live test

Every node recomputes, every five minutes, whether wallets plus holdings plus pools equal exactly 50,000,000 SOV, and publishes the result at /economy/snapshot. A stable discrepancy is recorded and flips the public ok flag; it is never absorbed into a pool. On 7 October 2026, on the production network, the same-nonce 600 SOV payment was sent through two nodes at once, totalling more than the balance: one committed and the other was refused (QUORUM_DENIED:SLOT_GRANTED_TO_OTHER_OP,SLOT_COMMITTED), with identical balances on every node. Throughput has not been benchmarked.

5. Messages

Messages are encrypted on the sending phone: X25519 key agreement, HKDF-SHA256, AES-256-GCM. Nodes accept only ciphertext. Since node 1.4.81 they refuse plain text for direct messages (PLAINTEXT_REFUSED), groups (GROUP_PLAINTEXT_REFUSED, each member's copy encrypted separately) and chat inside an exchange trade.

Nodes keep no message content. A node delivers to a recipient who is connected, directly or through another node, and otherwise answers RECIPIENT_OFFLINE; the message then waits on the sender's device and is retried when the recipient comes online. For receipts a node keeps a delivery record — message id, the two pseudonymous Sovereign IDs, type and time, with no content — deleted after 90 days by default. Citizens can vote that period anywhere from 7 to 365 days (message_retention_days).

6. Nodes

A node serves citizens' connections, holds the ledger, votes on slots, replicates operations and checks its peers. It ships as a Linux snap and inside the desktop apps. Its node id is the SHA-256 of its Ed25519 public key.

6.1 Voting and serving nodes

Since 1.4.96 every node declares a signed role. Voting nodes (servers, the default) grant slots and count toward N. Serving nodes (the desktop app) serve citizens and replicate everything but never vote, so a home computer going offline cannot stall payments. A greeting with no valid role is refused.

6.2 Admission

A joining node sends a signed signup and is interrogated by a random sample of 5 nodes. It enters other nodes' registries only with a certificate of signed approvals from distinct nodes spanning distinct operators, meeting the quorum (operator_signup_quorum = 3, capped by the operators a node can see). Approvers must already be known to the receiver. Operators must be enrolled citizens.

Admission lets a node serve and relay; it does not make it trusted. Since node 1.4.97 a node accepts replicated state, governance or ledger updates that no citizen signed, system money operations, and validator standing only from the servers on a fixed list built into the node (the three current servers; an operator can override it locally). This is interim: it goes away as each kind of replicated record gets its own proof. Since app 1.2.34 the app likewise connects only to a server that proves its identity (section 2.3), or to a node the citizen pinned themself.

6.3 Links

The greeting (PEER_HELLO) proves possession of the identity key, carries a timestamp accepted within 60 seconds, and a per-connection X25519 key signed by the identity key. Every later frame is sealed with NaCl secretbox, and plain frames are dropped.

6.4 The source_root declaration

A node computes source_root at start: the SHA-256 over sorted lines sha256(content)  path for each file of its src/ tree, so identical source gives an identical root on any system. Node 1.4.99 is 40eaf1516208d274… over 67 files. The node declares this value in every greeting and at /node-info. Peers refuse a declaration that is neither their own root nor one at least two distinct operators with 21 days of observed uptime already run (HELLO_SOFTWARE_NOT_AUTHENTIC, under release_enforce_mode = refuse, the live setting).

What this proves: an honest operator cannot accidentally join with modified or mismatched code, and anyone can check that the published source is what the network says it runs. What it does not prove: what code a dishonest operator actually executes. There is no hardware attestation, and a modified node can declare any root.

6.5 Distribution and discovery

The apps are not on Google Play or the App Store, by design. Releases are published on the website, on GitHub releases with a signed manifest and checksums, on IPFS, and over BitTorrent with GitHub as a web seed; the node snap is published on the same channels. Nodes find each other through the public BitTorrent DHT under an infohash every node derives (SHA-1("sov-network-mainnet-v1")). Reachable nodes re-announce every 15 minutes, discovered addresses are only dial targets, and DHT data-storage requests are refused. In the 7 October test the published Windows app found the network this way with no address configured.

7. Economy

There is nothing to buy. SOV enters circulation only from the two funded pools.

7.1 Enrolment grant

The curve spends the 30,000,000 SOV pool exactly, and a grant is paid only as far as the pool can back it. There is no referral reward.

7.2 Fees

• Transfers: 0.1%, rounded up to the next seed and capped at 1 SOV, to the operators' pool. Fees are not burned.
• Exchange: 1% of a completed trade, to the operators' pool.
• Sign in with SOV: 10 SOV per year, paid by the platform owner, to the operators' pool.
• Bonds (refundable): 10 SOV to open a dispute, 5 to publish an Academy article, 1 to upvote one.

7.3 The exchange

A seller lists up to 10,000 SOV per order at a price they choose, or on terms agreed in chat. Listings expire after 7 days by default, 30 at most. Listing is an owner operation that moves the SOV into escrow. The buyer pays the seller off-network by the agreed method. When the seller confirms, escrow releases to the buyer minus 1%, in one operation that can happen at most once. A buyer can ask for a refund or mark the trade disputed, which keeps the SOV in escrow, and either party can take a case to a jury.

7.4 Operator rewards

Every 30 days, an operator qualifies if one of its active nodes has an uptime streak of at least 21 days and reported within the last 90 minutes. A qualifying operator earns 20 SOV, plus 25% for a second and a third node; further nodes add nothing, so the maximum is 30 SOV.

The node count is the number of that operator's nodes the paying node has itself observed. A node counts as observed when its own hourly proof-of-service message arrives over its authenticated link. A proof relayed by a third node is recorded but does not count. A gap of more than 3 hours resets that node's streak, and a node unseen for 6 hours is not counted.

Payouts come from fee income first. The 20,000,000 SOV reserve tops up by at most 50,000 SOV per period, and payouts go pro rata if claims exceed the budget. Joining needs no stake.

7.5 The citizens' value vote

Each week every enrolled citizen may submit once what they think one SOV is worth in US dollars, between 0.0001 and 50. Nodes publish the median of the latest completed week with at least 25 submissions, derived from the replicated submissions. It is published for information only. Nobody guarantees it, and this paper makes no claim about what SOV is or will be worth.

8. Governance and justice

8.1 Parameters, polls and petitions

The node source declares 51 votable parameters, each with a range: fees, caps, poll rules, jury sizes, guardian thresholds, retention periods, operator rewards, admission quorums and the software-enforcement mode. Switches such as the Enclave forum and Sign in with SOV are binary parameters.

• Polls run 1 to 7 days. Each Sovereign ID votes once. A result binds only if at least 10% of enrolled citizens voted, and the same parameter cannot be proposed again for 7 days after a poll on it closes.
• Petitions flip switches. 33% of enrolled citizens' signatures open a binding poll; 67% flip the switch directly.

8.2 Justice

A citizen opens a dispute naming the amount at issue and posts a 10 SOV bond. Jurors are drawn from all enrolled citizens except the parties, by a cryptographically secure shuffle, starting at 3 and growing to at most 7. Each has 48 hours to accept, every accepted juror must vote, and conviction needs two-thirds. On conviction the bond is returned, the disputed amount moves from defendant to plaintiff as far as the defendant's balance covers it, any shortfall is recorded, and each voting juror is paid 0.5 SOV by the defendant. On dismissal the bond pays the jurors and the rest goes to the defendant. The verdict is one conserving ledger operation.

9. Sign in with SOV

A website can let visitors prove they are an enrolled SOV citizen without collecting their identity. A platform registers by a citizen-signed request and pays its annual fee. The site shows a 6-digit code (valid 5 minutes, one use), and the citizen types it into the app, which shows the registered domain. The citizen approves and chooses a password for that site. The app signs the approval and sends a bcrypt verifier of the password, never the password. The node verifies the signature against the enrolled key and sends the result, HMAC-authenticated, only to the platform's registered return URL; a different caller-supplied URL is refused.

The site receives the Sovereign ID, the network nickname, the citizen's public key and the password verifier, and checks later logins itself. It never receives a name, email, phone number, biometric data, balance, transactions or messages.

10. Limits and open work

Gathered in one place, as they stand in the current code:

• Small operator set. Tolerating a dishonest participant needs at least four independent operators; until then the voting fleet tolerates failures, not a dishonest majority.
• A fixed server list. State no citizen signed, system money operations and validator standing come only from the three current servers, and the app trusts only their keys (or the citizen's own pinned node). A new server needs a release. Records created only on a non-server node (for example an enrolment made through a citizen's desktop node) do not reach the servers. This is interim (section 6.2).
• Server-decided operations: escrow release and refund, vault claims, enrolment grants and operator payouts are applied on the deciding server's word (sections 2.2, 7). The jury is drawn by the hosting node (section 8.2).
• No agreed validator set: each node computes N from the validators it has seen in 14 days. There are no epochs and no total-order path (section 4.5). Payments pause in a partition without a majority.
• Liveness is checked in the app, not by nodes, so fabricated templates from a modified app are not detected (section 2.1).
• The biometric transform secret is held by every full node (section 2.2). Duplicate matching is a linear scan.
• Messaging keys are long-lived, with no forward secrecy (section 5).
• source_root is a declaration, not attestation (section 6.4).
• One Sovereign ID across all sites (section 9). One release key for app updates (section 6.5).
• Throughput has not been benchmarked.
• Platforms: Android, Windows, macOS, Linux. No iPhone app yet.

11. Verify it yourself

The source is open under the Apache-2.0 licence:

• Source: github.com/sov-network-dev/sov-build-source (node in wallet/windows/sov-node/, app in lib/).
• Releases, signed manifest and checksums: github.com/sov-network/relay-releases.

Compute the root of the node source you hold:

cd wallet/windows/sov-node
node -e "console.log(require('./src/release/source_root.js').sourceRoot('.',{include:['src']}))"

Then compare it with what nodes you chose yourself declare:

curl -s http://<node-address>/node-info

For node 1.4.99 the source_root is 40eaf1516208d274… over 67 files. The root hashes bytes, so check that git has not converted line endings under src/ (the repository pins LF). A match shows that the published source is what those nodes declare, not what they execute (section 6.4). To check a node snap before installing, src/network/sdk/verify-snap.py computes the snap's own root and accepts it only if at least two nodes you name declare exactly that root; do not take that list from the node that served you the file. /economy/snapshot on any node shows the supply total and the invariant.

Where the project stands. SOV Network is an open protocol in an early phase. It runs on a small set of operators, and several of its protections still rely on those operators being honest. What the current release enforces — citizen signatures on spends, majority-granted slots, conservation and a fixed supply, end-to-end encrypted messages that nodes do not store, and duplicate refusal at enrolment — is described above as it is in the code. So is each place where it still trusts its servers. Closing those, and recruiting independent operators, is the work ahead.